Jan Agent

`jan config set --base-url https://api.kunavo.com/v1`の1行で~/.jan/config.tomlにKunavoを書き込みます。推論エンジンを搭載しないJan AgentプレビューCLIは、そのキーで動作します。

# Jan Agent is a preview on a nightly channel — check your build first.
jan --version

jan config set \
  --provider kunavo \
  --api-key sk-kn-... \
  --base-url https://api.kunavo.com/v1 \
  --model claude-sonnet-5 \
  --model claude-haiku-4-5 \
  --api-type openai

jan config list   # configured providers as JSON, keys redacted

手順

1. /app/keys でキーを作成してコピーします。キーは一度だけ表示されます。
2. 設定対象を確認します：jan --version。Jan Desktopにもjanとして呼び出すCLIが付属していますが、コマンドの構成が異なるため、残りのコマンドを入力する前にjan config set --helpに--base-urlが表示されることを確認してください。
3. 上記のjan config setの行を実行します。--providerは固定の一覧から選ぶ名前ではなく、自分で決めるIDです。ドキュメントにあるローカルハードウェアの例でも--provider localを使用しています。また、--modelは繰り返し指定できますが、既存の一覧に追加するのではなく、一覧を置き換えます。
4. jan config list（キーは伏せられます）、またはファイル自体を表示するjan config pathで設定が反映されたことを確認し、その後jan cli models listで各プロバイダーが提供しているモデルを確認します。手入力したモデルIDは、エンドポイントの一覧から消えても残ります。一方、jan cli models refresh --provider kunavoはエンドポイントの一覧を正とします。
5. プロジェクトのディレクトリに移動してjanを実行し、/modelでモデルを選びます。初回はjan --planを推奨します。読み取り専用なので、ディスクに何かを書き込む前にプロトコルの不一致を検出できます。
6. ファイルを編集するタスクを与えてください。Jan Agentはエージェントなので、初回実行ではツール呼び出しとストリーミングを試す必要があります。エンドポイントとの互換性が不十分な場合、最初に失敗するのはこれらの機能であり、あいさつだけではどちらも試せません。

Jan Agentのプロバイダーページで2026年9月21日に確認しました。サードパーティの設定は変更されます。ここに記載されたフィールド名が表示内容と一致しなくなった場合は、このページではなく、そのページを正しい情報源としてください。

クライアントをデバッグする前に確認すること

1回のリクエストで、失敗の原因がエンドポイント、キー、設定ファイルのどれかを特定できます。これがJSONを返すなら、同じベースURLとキーがJan Agentで機能します。

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

フィールドに入力するモデルID

すべてのテキストモデルにはモデルIDでアクセスできます。現在の一覧はGET /v1/models、価格付きのカタログはモデルページにあります。料金は100万トークンあたりのUSDで、入力 / 出力の順です。

Jan APIキーと呼ばれるものは2種類あります

同じファイルに保存されますが、意味は正反対です。そのため、もう一方を想定している人にはjan config listが間違っているように見えることがあります。

Jan Desktopはどちらも発行しません。アカウントがないため、そこで生成できるものもありません。ローカルAPIサーバーには自分で決めたキーを設定しますが、これはさらに別の3つ目の意味であり、別のホストに属します。

Jan Desktopから引き継がれるものと、その範囲

Jan Agentはプロバイダー設定を4つのソースから読み込み、下にあるものほど上にあるものより優先されます。多くの人が意外に感じるのは2つ目です。

1. ~/.jan/config.toml — 基本となる設定であり、jan config setが書き込む唯一のファイルです。
2. Jan Desktopのsettings.json — 継承のみ。Agentでまだ設定していないプロバイダーを追加し、すでに設定済みのプロバイダーを上書きすることはなく、書き戻されることもありません。
3. プロジェクトのagent.toml内にある[provider]ブロック — プロジェクトごとの明示的な選択なので、前の2つより優先されます。このファイルは通常コミットされるため、api_keyを含めないでください。
4. コマンドラインの--provider / --api-key、またはJAN_API_KEY / <PROVIDER>_API_KEY — 最も明示的で、最も一時的な設定です。

見当違いのデバッグを始める前に知っておくべき影響が2つあります。jan config listではプロバイダーがないと表示されても、jan cli models listでは多数返される場合があります。後者にはDesktopから継承したプロバイダーも含まれ、それらは~/.jan/config.tomlには保存されていません。また、継承したプロバイダーは更新されません。ここには書き換え対象のエントリがないためです。Kunavoのモデル一覧を最新に保ちたい場合は、独自のjan config setエントリが必要であり、上記のブロックがそれを作成します。

2つのプロバイダーが同じモデルIDを提供している場合

Kunavoはclaude-sonnet-5のようなIDを提供しており、ベンダーに直接接続するプロバイダーエントリも同じIDを提供します。Jan Agentはどちらかを選ぶ必要があります。文書化されている優先順位は、まずプロバイダーのmodels一覧での完全一致、次に設定済みプロバイダーを指定する<provider>/<model>プレフィックスです。複数のプロバイダーが同じIDを提供している場合は、認証情報のあるプロバイダーが、キーのない同等のプロバイダーより優先されます。そのため、どちらを指定したいのかはkunavo/claude-sonnet-5で明示します。この修飾子はJan専用であり、上流側はプロバイダーで修飾されたIDを拒否するため、リクエスト送信前に取り除かれます。

コンソール内から同じエントリを設定する

フラグを入力したくない場合は、/settings > providersで同じ~/.jan/config.tomlエントリを管理できます。aは追加フォームを開き、入力項目はname、base url、api key、スペース区切りのmodelsです。このフォームには、フラグにはない動作が2つあります。ベースURLはhttps://である必要があります（localhostのエンドポイントではhttp://も使用できます）。そのため、暗号化されていないリモート接続でキーが送信されることはありません。Kunavoはhttps://なので、これは問題になりません。また、編集時のAPIキー欄には(unchanged)が表示され、入力しない限り保存済みの値が保持されます。この欄を空にすると、キーはそのまま残るのではなく、削除されます。