Jan AIのクラウドモデルはJanのモデルではありません。Janは推論サービスをホストしておらず、何も販売していません。そのため、Jan Desktopにおける「クラウドモデル」とは、第三者ベンダーへの11個の組み込み持ち込みキー方式ブリッジに加え、自分で追加するOpenAIまたはAnthropic形式のエンドポイントを意味します。いずれも接続先の事業者から課金されます。 アプリ自体は無料です。jan.ai/pricingは2026年9月19日に確認した時点でHTTP 404を返し、Jan DesktopもJan Agentも、プラン、シート、クレジット、クォータを記載していません。したがって、予算として考える必要があるのは、プロバイダーの単価で計算したトークン費用だけです。モデルを自分のマシンで実行するなら、リクエストごとの費用はありません。
まず混同しやすいため、区別しておきます。Janitor AI（janitorai.com）は消費者向けのキャラクターチャットサイトであり、まったく別の製品です。「jan ai api key」の検索のかなりの割合は、同サービスのプロキシキーを意味します。それを設定しようとしている場合は、代わりにJanitor AIのセットアップから始めてください。このページには、その製品の料金や上限は記載していません。
Janブランドを共有する3つの製品と、バイナリ名を共有する2つの製品
これを取り違えることが、購入検討者がJanを無料で実行できるかどうか分からないまま訪れる原因です。jan.aiには、2026年9月18日にホームページを確認した時点で、ちょうど3つの製品が掲載されています：
- Jan Desktop — ローカル優先の安定版アプリです。最新のタグ付きリリースはv0.8.4、2026年7月23日公開。リポジトリはアーカイブされておらず、2026年9月18日に最後のプッシュが行われ、スター数は44,551でした（GitHub API、2026年9月19日）。llama.cppとMLXのエンジンを同梱し、必要に応じてクラウドプロバイダーにも接続できます。リポジトリでは100%オフラインで動作すると説明されています。
- Jan Agent — 独立して配布される別個のターミナルエージェントです。クイックスタートにはプレビュー版であることの警告があり、
devのインストーラーはagent-nightlyチャンネルから取得します。リポジトリにはタグ付きリリースがなく、クイックスタートではjan --versionによってのみバージョンが表示されるため、フラグについて記録する内容は、インストールしたビルドに固有のものです。 - Tokamak — 独自のドキュメントドメインを持つ、組織レベルのセルフホスト型バックエンドです。そのページには、料金、プラン、シート数、クレジット、ウェイトリストが掲載されていないため、このページでも引用していません。公開条件がないことは、無料であることと同じではありません。これはJan Desktopに追加された有料プランではなく、別個のセルフホスト型バックエンドであり、
jan loginがそこへ接続するための文書化された方法です。
Janの公式ドキュメントはここで自己矛盾しているように見えますが、プロバイダーページが両者を整合させます。ドキュメントのランディングページの説明では、Jan Agentはローカルモデルに対してエージェントを起動するとされています。一方、クイックスタートには、Jan Agentにはローカル推論エンジンがなく、リモートプロバイダーを呼び出すと明記されています。どちらも異なる点について正しいのです。Agent自体はモデルを実行しないため、モデルは常に別の場所で実行されます。ただし、その場所は自分のマシンでも構いません。プロバイダーページには「自分のハードウェア」というセクションがあり、AgentをJan DesktopのローカルAPIサーバー（http://localhost:6767/v1）に接続する方法を示し、その構成ではマシンの外部に何も送信されないと説明しています。したがって、Agentには常にエンドポイントが必要ですが、常に有料である必要はありません。
名前の衝突が問題をさらに複雑にしています。Jan Desktop 独自の CLI（0.7.8 以降で利用可能）と Jan Agent バイナリは、どちらも jan として呼び出されますが、コマンドセットは異なります。そのため、「Jan エンドポイント」には3種類あります。Desktop GUI のローカル API サーバー用の 127.0.0.1:1337、Desktop CLI の jan serve が提供する localhost:6767/v1、そしてプロバイダーの接続先として設定されたリモートベース URL です。
Jan AI の料金：ソフトウェアの費用と、請求されるもの
| 項目 | 料金 | 根拠 |
|---|---|---|
| Jan Desktop アプリ | $0、Apache 2.0 | janhq/jan の LICENSE ファイル |
| ホスト型 Jan 推論サービス | 存在しない | 提供済みの プロバイダー定数にそのようなプロバイダーはない |
| Jan Agent（プレビュー CLI） | インストールは $0。モデル自体は実行しないため、常に設定済みのエンドポイント（リモートで課金されるもの、またはローカルサーバー）を呼び出します | Agent クイックスタートとプロバイダードキュメント |
Jan Desktop CLI、jan serve | $0、クラウドアカウント不要、利用料なし | CLI リファレンス |
| Jan のファーストパーティモデル | $0 — オープンウェイト | Hugging Face 上の Jan 独自組織 janhq と Menlo にある GGUF ダウンロード。費用はディスク容量と RAM です |
| Tokamak | 商用条件は公開されていない | Tokamak ページ — 価格、プラン、シートの記載はありません |
| リモートモデルのトークン | プロバイダーのトークン単価 | Jan ではなく、プロバイダー独自の請求 |
ライセンスについての注意。自動判定は誤っています。このリポジトリについて GitHub API が NOASSERTION と報告するのは、LICENSE ファイルがカスタムの Menlo Research 前文に続いて標準の Apache 2.0 通知と帰属表示の要求を含んでおり、スキャナーが照合する Apache 2.0 の逐語的な本文ではないためです。ファイル自体には「Licensed under the Apache License, Version 2.0」と記載されているため、ライセンスはそれであり、API フィールドではありません。
組み込みクラウドプロバイダー11種と、その実態
Jan Desktop は、web-app/src/constants/providers.ts にあるベース URL で各組み込みプロバイダーを初期化します。すべて第三者を指しています。jan や menlo のエントリはありません。
| 組み込みプロバイダー | Jan が提供するベース URL |
|---|---|
| OpenAI | https://api.openai.com/v1 |
| Azure OpenAI | https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1 |
| Anthropic | https://api.anthropic.com/v1 — api_type: 'anthropic' とフラグ付けされた唯一のエントリ |
| OpenRouter | https://openrouter.ai/api/v1 |
| Mistral | https://api.mistral.ai/v1 |
| Groq | https://api.groq.com/openai/v1 |
| xAI | https://api.x.ai/v1 |
| Google Gemini | https://generativelanguage.googleapis.com/v1beta/openai |
| MiniMax | https://api.minimax.io/v1 |
| Hugging Face | https://router.huggingface.co/v1 |
| NVIDIA | https://integrate.api.nvidia.com/v1 |
2026年9月18日にそのファイルから確認しました。すべてに共通するパターンに注目してください。バージョンパスはベース URL の一部です。この単一の慣例が Jan で最もよくある設定失敗であり、以下で説明します。
「Jan AI API キー」と呼ばれる3つの異なるもの
| どのキーか | 誰が作成するか | 配置先 |
|---|---|---|
| Jan のローカル API サーバーキー | 自分で作成します。API サーバーページには任意の文字列を設定するとあり、空欄にして認証を無効にすることもできます | 自分のクライアントが Authorization: Bearer として 127.0.0.1:1337 に送信。デフォルト API プレフィックスは /v1 |
| 上流プロバイダーまたはゲートウェイのキー | アカウントを持つベンダーまたはゲートウェイ | Jan 内のモデルプロバイダーに貼り付けて、アプリから外部を呼び出せるようにする |
| Janitor AI プロキシキー | janitorai.com の別製品 | Jan とは無関係 — Janitor AI の設定を参照 |
Jan 内では、この2つの意味が実際に衝突します。ローカルサーバーが両方の通信形式をミラーリングするためです。Jan のAPI 設定ドキュメントでは、ローカルサーバーが GET /v1/models、POST /v1/chat/completions、そして x-api-key で認証する Anthropic 互換の POST /v1/messages を公開すると説明されています。これはリモートゲートウェイが公開するものと同じ形です。そのため、同じ curl コマンドをノートパソコンにも有料エンドポイントにも向けられ、どちらかを判断できるのはホストだけです。
ローカルかクラウドか：メモリ、コンテキスト、オフライン要件で決める
この判断の最も客観的な根拠は、Jan 自身が公開しているMac インストールページです（macOS 13.6 以降、Apple Silicon のみ — Intel Mac はサポート対象外 — 空き容量 10GB 以上）。
| システム RAM | Jan が公開している指針 | 判断における意味 |
|---|---|---|
| 8GB | 通常は最大 3B モデルを快適に実行可能。一部の 7B モデルは、低ビット量子化を強く適用した場合のみ収まる可能性があります | ローカルは短く単純な作業向け。負荷の高い作業はすべてリモートへ |
| 16GB | 通常は最大 7B モデルを快適に実行可能。一部の 13B モデルは、より低い量子化で実行可能です | ローカルは日常的なチャットに対応。長いコンテキストや難しい推論にはリモート |
| 32GB | 通常は最大 13B モデルを快適に実行でき、より高い量子化、大きなコンテキストウィンドウ、マルチタスクのための余裕もあります | ローカルで大半を処理できます。リモートは容量ではなく品質の選択になります |
Windows の最小要件はWindows インストールページに別途記載されており、VRAM の下限も含まれます。Windows 10 以降、RAM 8GB 以上（推奨 16GB）、NVIDIA、AMD、Intel Arc GPU では VRAM 6GB 以上、空き容量 10GB、AVX2 サポートです。このページにはモデルサイズ別の RAM 表はありません。Linux の要件はこのページでは確認していません。アプリ内では、Hubが数値を判定結果に置き換えます。量子化レベルごとに「Fits」「May be slow」「Won't fit」と表示する色付きピルを示し、適合状況の判定にデータはダウンロードしないと記載しています。
モデル選択について。Jan は7つのファーストパーティモデル — Jan-v3-4B、Jan-Code-4B、Jan-v1、Jan-v2-VL-med、Jan-Nano-32、Jan-Nano-128、Lucy — を文書化しており、Jan 独自の組織 janhq と Menlo の Hugging Face でオープンウェイトを公開しています。すべて同じサイズではありません。モデルドキュメントでは、Jan-v3-4B と Jan-v1 は 4B パラメーター、Jan-v2-VL-med は 8B、Lucy は 1.7B と記載されています。Jan-v3-4B には 262,144 トークンのネイティブコンテキストもあり、そのページには上限が明確に記されています。4B パラメーターでは、より大きなモデルと比べて複雑な多段階推論が制限されます。この一文が、ローカルとクラウドの議論を一行で表しています。範囲が限定された作業やプライバシーにはローカルを使い、タスクがパラメーター数やメモリの限界を超える場合はリモートを使ってください。
Jan Desktop カスタム API：OpenAI 形式または Anthropic 形式のエンドポイントを追加する
文書化された手順は「Settings → Model Providers → Add Provider」です。Jan のカスタムエンドポイントページ（2026年9月19日に確認）では、通信形式をちょうど2つ提示しています。OpenAI 互換は vLLM、Ollama、LocalAI、TGI、llama.cpp server、OpenAI モードの LiteLLM 用、Anthropic 互換は Anthropic Messages API を公開するエンドポイント用です。その後、プロバイダー名、ベース URL、API キーを求められます。キーなしのローカルサーバーでもキー欄は必須で、任意のプレースホルダーで構いません。
最初の試行で動作するかどうかを決める詳細は2つあります。
バージョンパスはベース URL に含めます。 Jan のドキュメントでは、http://localhost:8000 ではなく http://localhost:8000/v1 を入力することがよくある間違いだと、この表現で説明しています。これによりすべてのリクエストが 404 になります。Kunavo を対象とする OpenAI 形式のプロバイダーでは、https://api.kunavo.com/v1 となります。
Anthropic 形式では、Jan のドキュメントは規則を示していません。ゲートウェイが文書化しているベースを使うよう記載し、例はローカルの LiteLLM インスタンスだけです。Jan のソースが答えを示します。Anthropic パスは Vercel AI SDK の Anthropic プロバイダー上に構築され、リクエスト URL は {baseURL}/messages として組み立てられ、x-api-key ヘッダーを付けます。また、そのデフォルトベースにはバージョンプレフィックスが含まれます。そのため、入力する値は同じ https://api.kunavo.com/v1 で、リクエストは /v1/messages に到達します。これはテストではなく2つのコードベースを読み取った結果なので、まず試す値として扱ってください。ページ末尾の未テスト注記も参照してください。
この違いで混乱する人がいます。Kunavo 独自のANTHROPIC_BASE_URL の説明は、別のクライアント群について反対のことを述べているためです。公式 Anthropic SDK と Claude Code は /v1/messages を自動的に追加するため、ベアなオリジンを受け取り、/v1 を追加すると /v1/v1/messages になって 404 になります。Jan の Anthropic 形式プロバイダーは、これらのクライアントには該当しません。404 が表示された場合、エラー内の二重化されたパスが、どの規約を使っているかを示します。Kunavo のMessages エンドポイントは、Anthropic の x-api-key ヘッダーと Authorization: Bearer の両方を受け付け、chat completions エンドポイントは OpenAI 形式のルートに対応します。
モデルの検出と機能。 保存時、Jan は {base_url}/models から利用可能なモデルの取得を試みます。失敗した場合は、サーバーが期待するモデル ID を正確に入力します。Kunavo は同じプレフィックスでモデル一覧を提供するため、OpenAI 形式のルートでは検出が機能するはずです。ただし、Jan が Anthropic 形式のプロバイダーに対してそれを照会するかどうかは文書化されておらず、テストもされていません。ID を手動で追加する準備をしてください。さらに重要なのは、カスタムプロバイダーでは機能が自動検出されないことです。Jan は、モデルがツール、ビジョン、音声のいずれをサポートするか推測できないと説明し、各モデルを手動で追加して機能をモデルごとに設定するよう求めています。MCP ドキュメントはその反対側を示しています。Anthropic のような組み込みプロバイダーでは、キーを追加すると Jan がプロバイダーのモデル機能を自動的に読み取り、ページの「有効にした MCP をモデルが使わない」というトラブルシューティング項目では、モデルでツールが有効になっていることを確認するよう案内しています。どちらのページにも、新しく追加したカスタムモデルのデフォルトは記載されていません。したがって、MCP が有効だと判断する前に Model Capabilities を確認してください。これは、組み込み Anthropic プロバイダーにキーを貼り付ける場合と、ゲートウェイをカスタムプロバイダーとして追加する場合の、実務上最大の違いです。
一部の組み込みプロバイダーでは、アプリに Base URL フィールドも表示されます。これにより、組み込みの Anthropic または OpenAI エントリをゲートウェイへ向け直せる可能性があります。これを扱う Jan のドキュメントページはなく、このページでも確認のためにアプリを実行していません。Add Provider フローをサポートされている方法として扱ってください。
Jan Agent は同じ2つの形式をフラグとして受け取る
Agent プロバイダードキュメントでは、--provider、--api-key、--base-url、--model（繰り返し可能）、--api-typeでエンドポイントを設定します。最後のものは通信プロトコルで、openaiまたはanthropicのいずれかです。デフォルトは OpenAI 互換です。
# Jan Agent is a preview build from a nightly channel.
# Re-check these flags against your own `jan config --help` before relying on them.
jan config set \
--provider kunavo \
--api-type anthropic \
--base-url https://api.kunavo.com/v1 \
--api-key sk-kn-... \
--model claude-sonnet-4-6設定は ~/.jan/config.toml に保存され、agent.toml 内の [provider] セクションでプロジェクトごとの上書きを設定でき、JAN_API_KEY で一時的な設定を行えます。優先順位はソース自体の providers.rs に記載されています。グローバル設定がベースで、Desktop の設定はそれを上書きしない継承専用ソースとして重ねられ、プロジェクトファイルが両方を上書きし、CLI フラグと環境変数がすべてに優先します。Jan のどちらのインターフェースもプロバイダーごとに複数のキーを受け付け、次のキーで再試行します。また、再試行の範囲も同じです。Jan Desktop のカスタムエンドポイントページでは、HTTP 401、403、429 の場合のみフォールバックし、それ以外のエラーでは再試行しないと説明しています。Agent 自身のソースも同じ3つのステータスを適用します。key rotation exhaustedというメッセージは Jan Desktop のもので、トラブルシューティングページでは、1つだけではなく設定済みのすべてのキーが 401 または 403 で失敗したことを意味すると説明しています。
リポジトリを自分で監査すると、ここで落とし穴に遭遇します。core/agent/upstream.rs の stream_openai_chat_completions にあるコメントは、api_type が「現在すべての呼び出し元で None」であり、エージェントはそれに関係なく常に OpenAI の /chat/completions を使用してきたと述べています。このコメントは1つのヘルパーについて説明したもので、残りについては古くなっています。core/agent/loop.rs は resolve_api_type_for_model を呼び出してそこからコンバーターを構築し、そのコンバーターはリクエストを /messages に書き換え、x-api-key と固定の anthropic-version ヘッダーを付けます（converters.rs）。したがって --api-type anthropic は尊重されます。また、同じコンバーター自身のコメントでは、登録された base_url にバージョンプレフィックスを含めるべきだと記載されています。そのため、上のスニペットは /v1 で終わっています。
失敗した場合
| 症状 | Jan が文書化している原因 | 変更する内容 |
|---|---|---|
| すべてのリクエストで404が返る | ベース URL に /v1 がない、またはパスが間違っている | サーバーが期待するバージョンパスを追加します。/v1/v1 が二重になっている場合は、反対の規約を意味します |
| 401 または 403 | キーがない、間違っている、失効している、またはキーにそのモデルへのアクセス権がない | キーを確認します。キー不要のローカルサーバーには、空でない任意のプレースホルダーを入力します |
| 429 | リクエストが多すぎる、またはクォータやクレジットを使い果たしている | キーに紐づくアカウントの残高を確認します |
| モデルが一覧に表示されない | エンドポイントが /models を公開していない | モデル ID を、サーバーが期待する形式で正確に手動追加します |
| ツールや MCP が何もしない | カスタムプロバイダーでは機能が自動検出されない | Model Capabilities でツール呼び出しを手動で有効にする |
最初の3行は Jan のトラブルシューティングページから、最後の2行はカスタムエンドポイントページからのものです。アプリログは macOS では ~/Library/Application Support/Jan/data/logs/app.log、Windows では %APPDATA%\Jan\data\logs\app.log、Linux では ~/.local/share/Jan/data/logs/app.log にあります。Kunavo のエラーリファレンスでは、ゲートウェイ側の同じステータスコードを扱っています。
Jan のクラウド予算例
これらの数値は測定したタスク費用ではなく、請求上限でもない、説明用のトークン計算です。チャット列は、増加するスレッドを毎回再送する Jan Desktop で、1日あたり約40ターン、つまり入力 240,000 トークン、出力 20,000 トークンを想定しています。Agent 列は、ツールを使う長めのセッションとして、入力 400,000 トークン、出力 30,000 トークンを想定しています。どちらのトークン数もこのページ独自のモデルであり、Jan が公開したものではありません。どちらもキャッシュ読み取りなしを前提としています。これは、いずれの Jan サーフェスでもカスタムプロバイダー経由でプロンプトキャッシュが維持されるか追跡していないためです。料金は100万トークンあたりのKunavo カタログの現在の価格です。
| モデル | 100万トークンあたりの入力／出力 | 見積もり、1日のチャット | 見積もり、エージェントの1セッション |
|---|---|---|---|
| Claude Haiku 4.5 | $0.70 / $3.50 | $0.238 | $0.385 |
| GPT-5.6 Terra | $0.70 / $4.20 | $0.252 | $0.406 |
| Claude Sonnet 4.6 | $2.10 / $10.50 | $0.714 | $1.155 |
| Claude Opus 5 | $3.50 / $17.50 | $1.190 | $1.925 |
2つの見方があります。まず、その表で最安モデルと最も高価なモデルの差は、同じ想定セッションで約 5.0x です。十分に大きな範囲なので、最初に動かすべきレバーはモデル選択であり、新しいアカウントを作らずにモデルを切り替えられるルートを選ぶ根拠になります。次に、これらの合計をローカルの選択肢と正直に比較してください。上の RAM 表に収まるモデルは、リクエストあたり $0で、Jan がそのエンジンを提供しています。Jan Desktop ユーザーにとって、リモート請求はアプリを使うための費用ではなく、機能に関する選択です。
予算として扱う前に、日数を自分の利用に合わせて拡大してください。Kunavo のカタログ金額は上限ではなく請求の下限です。上流が料金を報告すると、請求額はカタログ料金と、上流コストに適用されるマークアップを掛けた金額のうち大きい方になります。最低チャージ額は前払いクレジット 10ドルです。これは資金投入の最低額であり、タスク料金でもサブスクリプションでもありません。請求の詳細と、測定してから選ぶ方法を説明するAI コスト最適化を参照してください。
どのような場合にどのルートを選ぶか
| ルート | 有利な場面 | 失うもの |
|---|---|---|
| Jan Desktop のローカルモデル | RAM に収まるプライベートまたはオフライン作業。リクエストごとの料金なし | 機能の上限 — Jan 独自の 4B モデルが限界を文書化しています — に加えて、ディスクとメモリが必要です。Jan Agent は Desktop のローカルサーバー経由でのみ到達でき、単独では決して実行できません |
| 組み込みプロバイダー、ベンダーキー | 1つのベンダーのモデルを使い続け、機能検出をそのまま機能させたい | ベンダーごとに1アカウント。新しいベンダーごとに別のキーと残高が必要 |
| ゲートウェイへのカスタムエンドポイント | タスクごとにモデルを切り替え、両方の通信形式の背後で1つのキーと1つの残高を使いたい | 機能検出がないため、ツール、ビジョン、MCP は手動で切り替えます。モデル ID も手入力が必要になる場合があります |
| リモートプロバイダー上の Jan Agent | ターミナルエージェントが必要で、夜間品質のビルドを受け入れられる | Agent は単独では何も実行しないため、リモートルートではすべてのリクエストに料金が発生します。文書化された無償の代替策は、Desktop のローカルサーバーを指定することです。フラグはビルド間で変わる可能性があります |
| Tokamak、セルフホスト | 組織がルーティングと監査を備えた独自のバックエンドを必要としている | 自分で運用し、Jan は比較できる商用条件を公開していない |
ゲートウェイの行を検討している場合、クライアントディレクトリに各デスクトップクライアントとエージェントがベース URL と通信形式をどう扱うかが一覧されています。また、OpenAI 互換 APIでは Jan が従う最初の形式の規約を説明しています。
セットアップと最初の請求の確認
ここまでの内容は、Jan の公開ドキュメントとソース、および Kunavo 独自のドキュメントに基づいています。Kunavo は Jan Desktop または Jan Agent を実行時にテストしていません。このページのためにどちらのアプリ経由でもリクエストを送っていないため、ツール呼び出し、ストリーミング、モデル検出がエンドツーエンドで成功したとは述べられません。ベース URL は2組のドキュメントから導かれる値として扱い、範囲を限定したタスクで自分でも確認してください。試す間は動作するルートを確保し、小さなリクエストを1つ送信して、このページの見積もりではなく、アカウントに実際に記録された請求額を確認してください。キーへの入金準備ができたら、Kunavo アカウントを作成してください。
よくある質問
Jan AIの料金はいくらですか？
Jan Desktopアプリは無料です。janhq/janリポジトリのLICENSEファイルによるとApache 2.0でオープンソースとして公開されており、料金ページ自体がありません。jan.ai/pricingは2026年9月19日にHTTP 404を返しました。Jan Desktopにはアカウント、クレジット、クォータがないため、Janに支払うことでアプリ内の機能が解除されることはありません。実際に支払うのは、モデルをローカルで実行するときのハードウェアと電気代、またはJanをリモートプロバイダーに接続したときの第三者ベンダーやゲートウェイの請求です。別個のプレビューCLIであるJan Agentもインストールは無料ですが、自身ではモデルを実行しないため、常に設定したエンドポイントを呼び出します。リモートプロバイダーではリクエストごとに課金されますが、プロバイダーのドキュメントにはJan DesktopのローカルAPIサーバーを指定する方法も記載されており、その場合は課金されません。jan loginで到達するセルフホスト型バックエンドのTokamakは、商用条件を一切公開していないため、このページでは料金を示せません。
Jan AIのクラウドモデルとは何ですか？
Janのモデルではありません。Janは推論サービスをホストしていません。Jan Desktopには、OpenAI、Azure OpenAI、Anthropic、OpenRouter、Mistral、Groq、xAI、Google Gemini、MiniMax、Hugging Face、NVIDIAの11個の組み込みリモートプロバイダーがあり、いずれも第三者サービスへの持ち込みキー方式のブリッジで、その第三者から課金されます。提供されるプロバイダー定数には、Janホスト型またはMenloホスト型のプロバイダーエントリはありません。これらに加えて、OpenAIまたはAnthropicのワイヤ形式に対応する任意のカスタムエンドポイントを追加できます。Jan独自のファーストパーティモデルであるJan-v3-4BやJan-Code-4Bなどは、Jan独自の組織であるjanhqとMenloがHugging Faceで公開しているオープンウェイトです。これはローカルで実行するダウンロードであり、ホスト型APIではありません。
Jan AI APIキーとは何ですか？
この表現は、互いに無関係な3つのものを指します。1つ目は、Jan Desktop独自のローカルAPIサーバー用キーです。これは自分で作る文字列で、「任意の文字列を設定（例：a-secure-password）」と説明されており、認証を無効にするため空欄のままにすることもできます。クライアントはこれをAuthorization: Bearerとして127.0.0.1:1337に送信します。2つ目は上流の認証情報で、Janが外部に接続できるよう、モデルプロバイダーに貼り付けるベンダーまたはゲートウェイのキーです。3つ目はJanitor AIのプロキシキーで、janitorai.comにあるまったく別の製品に属します。Jan Desktop自体は何も発行しません。アカウントがないため、生成すべきキーも購入すべきものもありません。例外は、別個のセルフホスト型バックエンドであるTokamakです。jan loginを使うとキーが~/.jan/config.tomlに保存されますが、これは自分のデプロイメントへのサインインであり、Jan APIプランではありません。
Jan Desktopに最適なAPIは何ですか？
単一の勝者はありません。適切なルートはアプリの使い方によって異なります。1つのベンダーのフラッグシップモデルを1日中使い、その独自のキャッシュやバッチ条件を利用したい場合は、ベンダーの直接APIが適しています。タスクごとにモデルを切り替え、1つのキーと1つの残高を使いたい場合は、カスタムエンドポイントの背後にあるゲートウェイが適しています。ただし、Janでは具体的な手間が実際に伴います。Janのカスタムエンドポイントページによると、カスタムプロバイダーでは機能が自動検出されないため、モデルごとにツール、ビジョン、音声を手動で設定します。一方、JanのMCPページでは、Anthropicのような組み込みプロバイダーはキーを追加すると機能が自動的に読み取られると説明しています。Janに組み込まれたllama.cppまたはMLXエンジンでローカルモデルを使う方法は、リクエストごとの料金なしで、プライベートまたはオフラインの作業に適しています。Jan Agent自体はモデルを実行しないため、常にエンドポイントを指定します。接続先はリモートプロバイダー、または、そのプロバイダードキュメントに記載されているJan DesktopのローカルAPIサーバーです。
Jan Desktopに最も安いAPIは何ですか？
Jan Desktopに限れば、通常もっとも安い選択肢はAPIではありません。RAMに収まるローカルモデルならリクエストごとの費用はなく、Janにはそれを実行するエンジンが組み込まれているため、まずはそこから始めてください。ローカルモデルの性能が十分でない、または収まらない場合にのみリモートプロバイダーを検討します。リモートを使う場合、掲載単価が最安であることと、タスクを完了する総費用が最安であることは別の問題です。タスクに3回の試行が必要な安価なモデルは、1回で完了するモデルより高くつく可能性があります。100万トークンあたりの料金を比較して候補を絞り、その後、各候補で範囲を限定したタスクを1つ実行し、プロバイダーのアカウントに実際に記録された請求額を確認してください。
Jan Desktopに最適なモデルは何ですか？
ローカル利用では、好みよりもメモリが正直な制約になります。JanのMacインストールページは直接ガイダンスを公開していますが、条件付きです。適合性は量子化、コンテキスト長、macOSがすでに使用しているメモリに左右されるため、通常は8GBで最大3Bモデル、16GBで最大7B、32GBで最大13Bを、より大きなコンテキストウィンドウ用の余裕を残して快適に扱えます。Hubには、あなたのマシンについて各モデルが「Fits」「May be slow」「Won't fit」のいずれかを示すラベルがあります。Jan独自のファーストパーティモデルは1.7B（Lucy）から8B（Jan-v2-VL-med）まであり、4Bモデルのドキュメントには、4Bパラメーターではより大きなモデルと比べて複雑な多段階推論が制限されると明記されています。そのため、それ以上の能力が必要なタスクではリモートプロバイダーが選択肢になります。Windowsでは公開されている最低要件がさらに異なり、RAM 8GB以上、VRAM 6GB、AVX2対応です。
2026年9月21日に再確認しました。料金 URL（依然として 404）、GitHub リポジトリと最新リリース（v0.8.4）、ホームページ、Tokamak ページ、カスタムエンドポイント、API サーバー、API リファレンス、MCP、Mac インストール、Windows インストール、Hub、トラブルシューティングの各ドキュメント、Agent クイックスタートとプロバイダードキュメント、ファーストパーティモデルのドキュメント、Hugging Face 組織、プロバイダー定数、コンバーター、agent upstream、agent loop のソースファイルです。Star 数と最終プッシュの数値は、2026年9月19日時点の GitHub API に基づいており、毎日変動します。まったく確認していないものは、Linux のシステム要件、Tokamak の商用条件、カスタムプロバイダー経由のキャッシュ動作です。Kunavo のトークン料金は現在のカタログに基づき、ここに記載するドル額はすべて、測定したタスク費用ではなく説明用のトークン計算です。