Jan AI 云端模型并不是 Jan 的模型。Jan 不托管推理服务，也不销售任何产品，因此 Jan Desktop 中的“云端模型”指的是内置的 11 个自带密钥接入第三方供应商的桥接，以及你自行添加的任何 OpenAI 或 Anthropic 格式端点——每次请求的费用由另一端的服务商收取。应用本身免费：2026 年 9 月 19 日检查时，jan.ai/pricing 返回 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 个 star（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 端点”：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 记录了 7 个第一方模型——Jan-v3-4B、Jan-Code-4B、Jan-v1、Jan-v2-VL-med、Jan-Nano-32、Jan-Nano-128 和 Lucy——这些模型以开放权重发布在 Hugging Face 的 Jan 自有组织 janhq 和 Menlo 下。它们的大小并不相同：模型文档给出 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 key。即使是无需密钥的本地服务器，密钥字段也必须填写，此时使用任意占位符即可。
有两个细节决定了是否能第一次尝试就成功。
版本路径必须放在基础 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，因此它们接受不带路径的 origin，而添加 /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，并可在 agent.toml中的 [provider]下进行按项目覆盖，也可通过 JAN_API_KEY提供临时覆盖。源代码中的 providers.rs记录了优先级：全局配置是基础，Desktop 的设置作为仅继承来源叠加其上且不会覆盖全局配置，项目文件会覆盖前两者，而 CLI 标志和环境变量优先级最高。Jan 的两个界面都允许每个供应商配置多个密钥，并在失败时重试下一个密钥；两者对重试的范围也相同：Jan Desktop 的自定义端点页面说明仅在 HTTP 401、403 或 429 时进行回退，其他错误不会重试；Agent 自己的源代码也采用同样的三个状态码。消息 key rotation exhausted来自 Jan Desktop，其故障排查页面将其解释为所有已配置密钥都以 401 或 403 失败，而不仅仅是一个密钥。
如果你亲自审查仓库，会在这里遇到一个陷阱：core/agent/upstream.rs中的 stream_openai_chat_completions注释称，api_type“对于当前每个调用方都是 None”，并且 Agent 始终使用 OpenAI /chat/completions，无论该参数取何值。该注释描述的是一个辅助函数，而且关于其余部分已经过时：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 的云端预算示例
这些数字是用于说明的 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 质量的构建版本 | Agent 本身不运行任何内容，因此远程路由会为每个请求计费；文档化的免费替代方案是将它指向 Desktop 的本地服务器。不同构建版本之间的标志可能发生变化 |
| 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 内置了 11 个远程供应商——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，是以开放权重形式发布在 Hugging Face 上的，归属于 Jan 自己的组织 janhq 和 Menlo——这些模型由你下载并在本地运行，而不是托管 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。能够装入你内存的本地模型无需按请求付费，而 Jan 已经随附了运行本地模型的引擎，因此应从本地方案开始；只有当本地模型不够好或无法装下时，才考虑远程供应商。选择远程方案时，列表费率最低和完成任务的总成本最低是两个不同的问题：一个需要对任务尝试三次的便宜模型，成本可能高于一次完成任务的模型。比较每百万 token 的费率，先筛选候选模型，然后在每个候选模型上运行一个有边界的任务，并查看供应商账户实际记录的费用。
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 上游和 agent 循环源文件。Star 数和最后推送数据来自 2026年9月19日的 GitHub API，并且每天都会变化。完全未检查：Linux 系统要求、Tokamak 的商业条款，以及通过自定义提供商时的缓存行为。Kunavo 的令牌费率来自实时目录，本文所有美元金额都是示例性令牌算术，而不是实测任务成本。