Jan AI 的雲端模型並不是 Jan 的模型。Jan 不託管推論服務，也不販售任何產品，因此 Jan Desktop 中的「雲端模型」是指內建的 11 個自行帶入金鑰、連接第三方供應商的橋接程式，此外也包括你自行加入的任何 OpenAI 或 Anthropic 格式端點——每次費用都由另一端的服務商收取。 應用程式本身免費：jan.ai/pricing 在 2026 年 9 月 19 日查詢時回傳 HTTP 404，Jan Desktop 與 Jan Agent 的文件也都未提及方案、席位、點數或配額。因此，唯一值得編列預算的數字，就是依供應商費率計算的 token；或者，如果模型在你自己的電腦上執行，每次請求完全不需付費。
先釐清一點，因為搜尋結果會把它們混在一起。Janitor AI（janitorai.com）是面向一般消費者的角色聊天網站，與此完全是不同的產品；大量「jan ai api key」搜尋其實指的是它的代理金鑰。如果你要設定的是那項服務，請改從 Janitor AI 設定開始——本頁沒有列出該產品的價格或限制。
共用 Jan 品牌的三項產品，以及共用 binary 名稱的其中兩項
買家之所以搞不清楚 Jan 是否可免費執行，正是因為誤解了這一點。jan.ai 恰好列出三項產品（2026 年 9 月 18 日查閱首頁）：
- 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顯示版本，因此你記錄的任何旗標都只適用於所安裝的那個 build。 - 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 binary 都以 jan 呼叫，但命令集不同。因此存在三種不同的「Jan endpoint」：127.0.0.1:1337 是 Desktop GUI 的本機 API 伺服器，localhost:6767/v1 是 Desktop CLI 的 jan serve，以及供應商所指向的任何遠端基礎 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 頁面 — 頁面上沒有價格、方案或席位資訊 |
| 遠端模型 token | 供應商的每 token 費率 | 由你的供應商自行計費，而不是 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 key」的項目
| 哪一把金鑰 | 由誰建立 | 傳送位置 |
|---|---|---|
| Jan 的本機 API 伺服器金鑰 | 由你自行發明。API 伺服器頁面表示可以設定任意字串，也可以留白以停用驗證 | 由你自己的用戶端以 Authorization: Bearer 傳送至 127.0.0.1:1337，預設 API 前綴為 /v1 |
| 上游供應商或閘道金鑰 | 你持有帳戶的供應商或閘道 | 貼到 Jan 內的模型供應商設定中，讓應用程式可以向外呼叫 |
| Janitor AI 代理金鑰 | janitorai.com 上的另一項產品 | 完全不是 Jan — 請參閱 Janitor AI 設定 |
這兩種含義確實會在 Jan 內部衝突，因為它的本機伺服器同時模仿兩種線路格式。Jan 的 API 偏好設定文件顯示，本機伺服器會公開 GET /v1/models、POST /v1/chat/completions 及與 Anthropic 相容的 POST /v1/messages，並使用 x-api-key 驗證。這與遠端閘道公開的形式相同——因此相同的 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 或更高版本，最低 8GB RAM、建議 16GB，NVIDIA、AMD 或 Intel Arc GPU 最低 6GB VRAM，10GB 可用空間，以及 AVX2 支援。該頁面沒有公布依模型大小區分的 RAM 表格。本頁未檢查 Linux 需求。在應用程式內，Hub 會以結論取代數字——依量化層級顯示「Fits」、「May be slow」或「Won't fit」的彩色標籤——並表示判定適配狀態時不會下載任何資料。
關於模型選擇：Jan 記錄了七個第一方模型——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 token 的原生上下文，而其頁面以直白的文字說明自身限制：與更大的模型相比，4B 參數會限制複雜的多步驟推理。這句話一行就概括了本機與雲端的全部差異。有限定範圍且重視隱私的工作使用本機；當任務超出參數數量或你的記憶體能力時，改用遠端。
Jan Desktop 自訂 API：加入 OpenAI 或 Anthropic 格式的端點
文件記載的路徑是 Settings → Model Providers → Add Provider。Jan 的自訂端點頁面（2026 年 9 月 19 日查閱）提供兩種線路格式——OpenAI 相容格式，適用於 vLLM、Ollama、LocalAI、TGI、llama.cpp server，以及 OpenAI 模式的 LiteLLM；以及 Anthropic 相容格式，適用於公開 Anthropic Messages API 的端點——接著要求輸入供應商名稱、基礎 URL 與 API 金鑰。即使是不需要金鑰的本機伺服器，金鑰欄位仍為必填，此時填入任何佔位值即可。
有兩項細節會決定能否第一次就成功。
版本路徑必須放在基礎 URL 中。 Jan 的文件以這些文字將其列為常見錯誤：輸入 http://localhost:8000 而不是 http://localhost:8000/v1，會導致每個請求都回傳 404。對於指向 Kunavo 的 OpenAI 格式供應商，這表示應填入 https://api.kunavo.com/v1。
對 Anthropic 格式而言，Jan 的文件沒有給出規則——它表示應使用閘道文件所記載的基礎 URL，唯一範例是本機 LiteLLM 執行個體。Jan 的原始碼解答了這個問題：Anthropic 路徑建立在 Vercel AI SDK 的 Anthropic 供應商上，其請求 URL 會組合成 {baseURL}/messages，並帶有 x-api-key 標頭，而其自身的預設基礎 URL 已包含版本前綴。因此要輸入的值同樣是 https://api.kunavo.com/v1，請求會落到 /v1/messages。這是對兩個程式碼庫的解讀，而非測試結果，因此請將其視為優先嘗試的值——請參閱本頁結尾未經測試的注意事項。
這項區別常讓人踩坑，因為 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，而聊天完成端點則涵蓋 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 透過旗標接受相同的兩種格式
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，並可在 [provider] 下的 agent.toml 中設定每個專案的覆寫值，也可透過 JAN_API_KEY 設定暫時值。優先順序記載於 providers.rs 原始碼中：全域設定是基礎，Desktop 設定會以僅繼承的來源疊加，且不會覆寫全域設定；專案檔案會覆寫前兩者；CLI 旗標與環境變數則優先於所有設定。兩個 Jan 介面也都接受每個供應商的多把金鑰，並在失敗時改用下一把；兩者的重試範圍也相同：Jan Desktop 的自訂端點頁面記載只有 HTTP 401、403 或 429 會觸發 fallback，其他錯誤不會重試；Agent 自己的原始碼也採用相同的三種狀態碼。訊息 key rotation exhausted 是 Jan Desktop 的訊息，而其疑難排解頁面將它解讀為所有已設定金鑰都以 401 或 403 失敗，而不只是其中一把。
如果你自行稽核儲存庫，會在這裡遇到陷阱：core/agent/upstream.rs 中 stream_openai_chat_completions 的註解表示 api_type「目前對每個呼叫者都是 None」，而且無論 api_type 為何，agent 一向都使用 OpenAI /chat/completions。這段註解描述的是某個 helper，且對其他部分已經過時：core/agent/loop.rs 會呼叫 resolve_api_type_for_model，並據此建立 converter；該 converter 會將請求改寫至 /messages，使用 x-api-key，以及固定的 anthropic-version 標頭（converters.rs）。因此 --api-type anthropic 會生效——而同一個 converter 自己的註解也表示，已註冊的 base_url 應包含版本前綴，這就是上方範例以 /v1 結尾的原因。
發生失敗時
| 症狀 | Jan 文件記載的原因 | 要變更的項目 |
|---|---|---|
| 每個請求都回傳 404 | 基礎 URL 缺少 /v1，或路徑不正確 | 加入伺服器要求的版本路徑；重複的 /v1/v1 表示採用了相反的慣例 |
| 401 或 403 | 金鑰遺失、錯誤或已撤銷；或者金鑰沒有存取該模型的權限 | 確認金鑰；對於不需要金鑰的本機伺服器，輸入任何非空白的佔位值 |
| 429 | 請求過多，或配額、點數已用盡 | 檢查金鑰所屬帳戶的餘額 |
| 沒有列出模型 | 端點沒有公開 /models | 手動加入模型 ID，並完全按照伺服器要求輸入 |
| 工具或 MCP 沒有作用 | 自訂供應商不會自動偵測能力 | 在 Model Capabilities 中手動啟用工具呼叫 |
前三列來自 Jan 的疑難排解頁面；後兩列來自自訂端點頁面。應用程式記錄在 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 的雲端預算範例
這些數字是示意性的 token 算術，不是實測的任務成本，也不是帳單上限。聊天欄假設在 Jan Desktop 中使用一天，約 40 輪對話，且每次都重新傳送不斷增長的對話串——240,000 個輸入 token 與 20,000 個輸出 token。Agent 欄假設較長的工具使用工作階段，包含400,000 個輸入 token 與 30,000 個輸出 token。兩組 token 數量都是本頁自行建模的結果，不是 Jan 公布的數據。兩者都假設不讀取快取，因為尚未追蹤 Jan 的任一介面是否能在自訂供應商中保留提示快取。費率採用目前 Kunavo 目錄中每百萬 token 的價格。
| 模型 | 每 1M 的輸入／輸出 | 估算值，一天的聊天 | 估算值，一次 Agent 工作階段 |
|---|---|---|---|
| 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 |
這裡有兩種解讀。第一，表中最便宜與最昂貴模型之間的差距，在相同假設工作階段下約為 5.0 倍——範圍大到足以讓模型選擇成為最值得優先調整的槓桿，也說明應選擇能讓你切換模型而不必開設新帳戶的路徑。第二，誠實地將這些總額與本機選項相比：只要模型符合上方的 RAM 表格，每次請求成本為 $0，而 Jan 會提供所需引擎。對 Jan Desktop 使用者而言，遠端帳單是能力上的選擇，而不是使用應用程式的成本。
在把任何數字當成預算前，請先按照你自己的使用天數換算。Kunavo 目錄中的金額是計費下限，而不是上限：上游回報費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者之較高者。最低儲值額為預付點數 $10——這是資金最低要求，不是任務費用或訂閱費。請參閱計費詳細資訊，以及AI 成本最佳化所述的先衡量再選擇方法。
哪條路由勝出，取決於
| 方式 | 適用時機 | 你放棄的功能 |
|---|---|---|
| Jan Desktop 中的本機模型 | 適合你 RAM 的私人或離線工作；每次請求不收費 | 能力上限——Jan 自己的 4B 模型文件說明了這項限制——另加磁碟與記憶體成本；Jan Agent 只能透過 Desktop 的本機伺服器存取它，無法獨立存取 |
| 內建供應商、供應商金鑰 | 你只使用某一家供應商的模型，並希望能力偵測直接正常運作 | 每家供應商各一個帳戶；每新增一家供應商，就多一把金鑰與一筆餘額 |
| 連接閘道的自訂端點 | 你會依任務切換模型，並希望兩種線路格式共用一把金鑰與一筆餘額 | 沒有能力偵測，因此工具、視覺與 MCP 都必須手動切換；模型 ID 可能也需要手動輸入 |
| 使用遠端供應商的 Jan Agent | 你想要終端機代理，並接受 nightly 品質的 build | Agent 本身不執行任何東西，因此遠端路徑會對每次請求計費；文件記載的不付費替代方案，是將它指向 Desktop 的本機伺服器。旗標可能隨 build 改變 |
| Tokamak，自託管 | 組織希望擁有自己的後端，並具備路由與稽核功能 | 你自行執行它，而 Jan 未公布任何可供比較的商業條款 |
如果你正在考慮閘道這一列，用戶端目錄會列出每個桌面用戶端與代理如何處理基礎 URL 及線路格式，而OpenAI 相容 API則涵蓋 Jan 第一種格式所遵循的慣例。
設定完成並檢查第一筆帳單
以上內容來自 Jan 已發布的文件與原始碼，以及 Kunavo 自己的文件。Kunavo 尚未對 Jan Desktop 或 Jan Agent 進行執行時測試：本頁沒有透過任一應用程式送出請求，因此這裡沒有任何內容表示工具呼叫、串流或模型探索已通過端到端測試。請將這些基礎 URL 視為兩組文件所推導出的結果，並在範圍受控的任務上自行確認。嘗試時請保留一條可運作的路徑，傳送一個小型請求，接著讀取帳戶實際記錄的費用，而不是本頁的任何估算。準備好為金鑰儲值時，請建立 Kunavo 帳戶。
常見問題
Jan AI 的費用是多少？
Jan Desktop 應用程式完全免費。根據 janhq/jan 儲存庫中的 LICENSE 檔案，它以 Apache 2.0 授權開放原始碼，而且根本沒有定價頁面——jan.ai/pricing 於 2026 年 9 月 19 日回傳 HTTP 404。Jan Desktop 沒有帳戶、額度或配額，因此應用程式中沒有任何功能是透過付費 Jan 解鎖的。您實際支付的是模型在本機執行時的硬體與電力費用，以及將 Jan 指向遠端供應商時產生的第三方供應商或閘道帳單。Jan Agent 這個獨立的預覽版 CLI 也可免費安裝，但本身不執行模型，因此一律會呼叫您設定的端點：遠端供應商會為每個請求計費，而其供應商文件也說明可以將它指向 Jan Desktop 的本機 API 伺服器，後者不會產生費用。Tokamak 是透過 jan login 連線的自託管後端，完全沒有公布商業條款，因此本頁無法說明其費用。
什麼是 Jan AI 雲端模型？
它們不是 Jan 的模型。Jan 不託管推理服務。Jan Desktop 內建十一個遠端供應商——OpenAI、Azure OpenAI、Anthropic、OpenRouter、Mistral、Groq、xAI、Google Gemini、MiniMax、Hugging Face 與 NVIDIA——每一個都是使用您自有金鑰連接至該第三方的橋接器，並由該第三方計費。出貨的供應商常數中沒有 Jan 託管或 Menlo 託管的供應商項目。此外，您可以加入任何使用 OpenAI 或 Anthropic 線路格式的自訂端點。Jan 自己的第一方模型，例如 Jan-v3-4B 與 Jan-Code-4B，是以 Jan 自有組織 janhq 與 Menlo 名義發布於 Hugging Face 的開放權重模型——由您在本機下載並執行，而不是託管 API。
什麼是 Jan AI API 金鑰？
這個詞涵蓋三件互不相關的事。第一，是 Jan Desktop 自己的本機 API 伺服器金鑰：由您自行編造的字串，文件記載為「設定任何字串（例如 a-secure-password）」，甚至可以留空以停用驗證，用戶端則將其作為 Authorization: Bearer 傳送至 127.0.0.1:1337。第二，是上游憑證——您貼入模型供應商的供應商或閘道金鑰，讓 Jan 可以向外呼叫。第三，是 Janitor AI 代理伺服器金鑰，完全屬於另一項產品 janitorai.com。Jan Desktop 本身不會簽發任何金鑰：它沒有帳戶，因此沒有可產生的金鑰，也沒有要購買的東西。唯一例外是 Tokamak 這個獨立的自託管後端；在那裡，jan login 會將金鑰儲存至 ~/.jan/config.toml——這是登入您自己的部署，而不是 Jan API 方案。
Jan Desktop 的最佳 API 是什麼？
沒有單一勝者，因為正確的路徑取決於您如何使用應用程式。當您整天使用某一家供應商的旗艦模型，並希望使用其自有的快取與批次條款時，直接供應商 API 勝出。當您依工作切換模型，並希望使用一把金鑰與一個餘額時，位於自訂端點後方的閘道勝出；但在 Jan 中，這項成本是具體存在的——Jan 的自訂端點頁面表示，自訂供應商不會進行能力偵測，因此您必須逐模型手動設定工具、視覺與音訊；而 Jan 的 MCP 頁面表示，像 Anthropic 這類內建供應商在加入金鑰後會自動讀取其能力。當您進行私人或離線工作，且不希望按請求付費時，透過 Jan 內建的 llama.cpp 或 MLX 引擎使用本機模型勝出。Jan Agent 本身不執行模型，因此一律會指向某個端點——遠端供應商，或依其供應商文件所述，Jan Desktop 的本機 API 伺服器。
Jan Desktop 最便宜的 API 是什麼？
就 Jan Desktop 而言，最便宜的選項通常不是 API。適合您 RAM 的本機模型每次請求都不產生費用，而 Jan 已附帶執行引擎，因此應先從這裡開始；只有在本機模型品質不足或無法容納時，才使用遠端供應商。當您確實轉向遠端時，列出的最低費率與完成工作的最低成本是兩個不同問題：需要嘗試三次才能完成工作的較便宜模型，可能比一次完成的模型更昂貴。比較每百萬權杖費率以建立候選清單，然後在每個候選模型上執行一項有界限的工作，並查看您的供應商帳戶實際記錄的費用。
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 上，公布的最低要求又不同：至少 8GB RAM、6GB VRAM，並支援 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 token 費率來自即時目錄，本文所有美元數字都是示意性的 token 算術，而非實測任務成本。