Nanocoder 定价：免费 CLI、模型账单和成本页脚

Nanocoder 是免费的：CLI 采用 MIT 许可证，没有账户、层级或许可证密钥，因此“Nanocoder 定价”在实践中指的是其背后的模型账单——你配置的提供商收取的 token 费用，或本地模型所需的硬件和电费。终端中的数字不是那张账单。Nanocoder 从一个没有你的网关条目的第三方数据库为每个响应定价，而本页面准确重现了该数据库如何影响这个数字。

首先需要澄清一个名称，因为搜索结果混合了多个对象。本页面介绍的是 Nano-Collective/nanocoder，发布为 @nanocollective/nanocoder，文档位于 docs.nanocollective.org/nanocoder。请注意末尾的 r。另一个名为 nanocode 的项目——NanoGPT 的编码代理——以及其本身销售 token、并在 nano-gpt.com 和 nanogpt.net 发布真实价格表的 NanoGPT，还有一家以 Nanocoder 名义经营的波兰软件公司，都会在这些查询中排名。它们的价格都不属于本页面。

Nanocoder 收取什么费用，以及实际向你计费的是什么

每条已记录的安装路径都免费，且不要求账户：npm install -g @nanocollective/nanocoder、Homebrew 或 Nix。npm registry 将 1.30.0列为latest，发布于2026 年 8 月 26 日，包含 engines.node >= 22 和 "license": "MIT"（截至 2026 年 9 月 21 日读取 registry——在此之前没有发布更新版本）。

该项目由捐赠和赞助提供资金，而不是由用户付费；这里有一项披露值得说明，因为它会影响你在其他地方读到的建议：Atlas Cloud 是 Nanocoder 自己 README 中列出的赞助商，README 还链接到其“coding plan promotion”，宣传“更经济的 API 访问”。该建议位于一份由赞助商帮助资助的文档中，并不能证明该套餐最便宜。这些coding plans是按月订阅的套餐，附带每周积分额度；积分按输入 token 乘以输入乘数，再加上输出 token 乘以输出乘数的方式消耗，乘数按模型设置——因此每百万 token 的成本取决于你运行的模型，并不是可以与费率表并列的单一数字。

终端中的成本数字不是你的账单

版本 1.30.0 在每条助手消息下方添加了页脚，例如 Tokens: 4.2k | ~$0.01。这是屏幕上最像有用信息的数字，也是最容易误读的数字，因为 Nanocoder 从不询问你的提供商收取什么费用。

以下是从标签为 v1.30.0 的已发布源代码中读到的机制。定价来自 models.dev/api.json。查找逻辑使用你的模型 ID，并且按其自身注释所述，会“遍历所有提供商，选择上下文上限最高的匹配项”——因此，它从不查看你配置的提供商，只使用 ID 字符串。在 2026 年 9 月 21 日获取该文件时，其中列出了 223 家提供商，且没有 Kunavo 的条目。因此，由 Kunavo 提供服务的模型 ID 会被解析为某个无关条目，只要该条目恰好使用相同的字符串，并声明了最大的上下文窗口。

按照该文件重放完全相同的算法，对一次假设包含 200,000 个输入 token 和 15,000 个输出 token 的会话进行计算，结果得出下面的差异。目录估算值是 Kunavo 目录算术结果；最后一列是 Nanocoder 页脚对相同 token 的合计值。

两种不同的故障，均来自一次查询。当获胜条目发布了更高费率时，页脚会高估。当它发布零费率，或根本没有 cost 块时，页脚会什么都不显示——而缺失的成本会被理解为免费。已发布代码中最后一步是有意为之：缺失的成本块会被转换为零费率，而不是“未知”；已发布包中的格式化程序对成本为零或更低的情况不返回任何内容，因此“免费/本地模型应不显示成本片段，而不是显示 '$0.00'”。对于本地模型，这一逻辑是正确的；但对于其 ID 与零价格目录条目冲突的付费模型，则是错误的。

此外还有两项失真。models.dev 为部分条目发布长上下文价格层级；已发布客户端只从每个条目中复制平面 input 和 output 费率，从不读取这些层级，因此超过层级阈值的请求会被低估。版本 1.30.0 自己的 changelog 表明，该估算“按标准费率计算所有输入 token——未计入缓存读写折扣，因此对于支持提示缓存的提供商，成本可能被高估”。关于路由支持这些折扣时它们的具体表现，请参阅提示缓存。

该表中的费率是一个快照：models.dev 会持续编辑，因最高上下文的平局决胜而胜出的条目可能发生变化，而你机器上的任何内容都无需改变。重现过程很短——获取 api.json，查找所有携带你确切模型 ID 的提供商，保留 limit.context 最大的提供商，然后读取其 cost 块。你提供商自己的账本才是权威数字；请参阅计费详情。

已发布的内容，以及仅存在于开发分支的内容

这一差别决定了人们引用的若干修复是否真的存在于你的机器上。2026 年 9 月 21 日核查时，文档网站上的 /latest/ 和 /v1.30.0/ 都提供 v1.30.0 内容；代码仓库中 main 的 docs/ 文件夹则领先于两者。

上面每个“否”都通过检索已发布页面进行核查，而不是推断得出；Anthropic 提供商页面用于交叉核查：其中对“Prompt caching”和“cache-aware”的命中次数为零，而相同 HTML 中包含 sdkProvider 六次。这些内容确实缺失，并非渲染问题。8 月 26 日发布后合入 main 的工作加入了所有这些内容——因此引用 main 上的文件描述的是你尚无法安装的软件，而更新的版本会改变其中若干行的情况。

Nanocoder 的最佳模型：这是能力问题，而非排名问题

Nanocoder 没有发布推荐模型、排行榜或硬件规格。完整阅读其截至 2026 年 9 月 21 日的文档后，没有发现最低 RAM、VRAM 数值或推荐 GPU；仓库的 benchmarks/ 目录是一份关于已构建 CLI 的质量报告——退出代码、模块数量、近似启动和首次渲染时间、包大小——而不是任何模型评分。这里也没有运行任何任务基准测试，因此本页面不提供排名——凭空拼出的排行榜还不如没有排行榜。

厂商发布的内容其实更适合预算页面，因为它改变的是模型能做什么，而不是模型得分多少。根据 v1.30.0 tune 文档，默认的 auto 工具配置“为云模型和没有大小提示的模型 ID 保留完整工具面，将最多 15B 参数的模型解析为 minimal，并将最多 4B 参数的模型解析为 nano”。

有两种实际解读。第一，文档明确指出“MCP 工具仅在解析后的 full 配置中公开”——因此，将 MCP 服务器连接到小型本地模型不会产生任何作用，除非你手动切换配置或改用更大的模型。第二，内置的“Nano（低端硬件）”预设将最大 token 数限制为 2048，这是真正的回复长度上限，而不是提示。Nanocoder 自己的 battlemap 认为，小型和较旧的模型仍然可用，因为它提供三种工具调用路径——原生函数调用、XML 回退和 JSON 回退，并且会修复两种回退结果——但这是维护者的说法，它没有发布成功率。要了解更广泛的模型权衡，请参阅编码模型对比。

本地与远程：两种不同的预算

优先使用本地模型的用户，并不是账单更低的付费 API 买家；将两者视为同一类用户，会在两个方向上都给出糟糕的建议。Nanocoder 自己的 battlemap 表示，“如果你让 Nanocoder 连接本地模型，整个循环可以在零出站网络流量的情况下运行”，并且将七个本地服务器——Ollama、llama.cpp、llama-swap、LM Studio、LocalAI、MLX Server 和 vLLM——列为一等提供商。这是项目的定位声明，而不是这里测得的结果。

关于本地成本，诚实的说法是没有人发布过相关数据。Nanocoder 没有量化任何硬件要求，因此资本成本和电费需要由你自行估算。有两种行为会让差距显现而不是被隐藏：本地模型和免费模型会省略成本部分；在无头运行中，当提供商未报告 token 遥测数据时，usage 块会“完全省略（本地模型通常如此），因此缺少该块意味着‘未知’，绝不意味着‘零’”。

一个容易踩到的坑。Ollama 的定价页面指出，“在自己的硬件上运行模型始终不受限制”，而 Nanocoder 的 Ollama 提供商文档只涉及本地端点，无需密钥。但同一页面也销售托管方案——Pro 每月 $20，包含 $60 的月度使用额度；Max 每月 $100，包含 $300；Team 每月 $500，包含 $1,000 的共享额度；以及定制 Enterprise 层级（截至 2026 年 9 月 21 日核查）。因此，“Ollama 是免费的”对本地路径而言是正确的，对托管路径而言则不正确。如果你要在两者之间迁移，Kunavo 的 Ollama 兼容端点文档介绍了该 API 的结构。

关于网关充值费用，还有一个容易被忽略的要点。OpenRouter 的 FAQ指出，“推理定价没有加价”，而是“在你购买额度时”收取费用；对于超出套餐相关额度的自带密钥用量，还会收取额外费用。这些百分比会因付款方式和套餐而异，并在页面渲染时填入，因此这里不引用任何数值——请在自己的结账页面查看当前数值。OpenRouter 替代方案和OpenAI 兼容 API更广泛地介绍了相关对比。

规划 token 方面的预算

上表中的目录列是预算估算依据，并且是说明性的 token 算术，而不是实测任务成本或账单上限。假设条件是：一次会话包含 200，000 个未缓存输入 token 和 15，000 个输出 token，按照实时目录费率计算，不包含缓存读取费用和工具费用。实际会话会因代码库大小、代理重新读取文件的频率，以及有多少工具输出重新进入上下文而不同——此外，上面的工具配置还会在此之前改变每轮的开销。

在将其视为预算之前，先按你每天自己的会话数进行换算。根据这些假设，Claude Haiku 4.5 模型每 $10 额度约可支持 51 次会话，而 Claude Opus 5 约可支持 10 次会话；这可以帮助你确定充值金额，却不会告诉你哪一个模型能完成工作。目录中列出的最低费率与完成任务的最低成本是不同的说法：需要三次尝试的廉价模型，成本可能高于一次就能完成的模型。AI 成本优化详细介绍了这种方法。

Kunavo 的目录金额是计费下限，而不是上限：当上游报告其费用时，账单取目录成本与上游成本乘以适用加价之间的较大值。缓存费用和外部工具费用不在本例中。最低充值金额为$10 的预付额度——这是资金充值下限，不是任务费用，也不是订阅费。

将 Nanocoder 指向自定义端点

任何 OpenAI 兼容服务都可以作为自定义提供商添加，既可以通过 /settings providers 交互式添加，也可以写入 agents.config.json——先查找项目文件，然后查找各操作系统对应的用户配置目录；NANOCODER_CONFIG_DIR 会跳过这两项查找，而 NANOCODER_PROVIDERS 环境变量的优先级最高。

{
  "nanocoder": {
    "providers": [
      {
        "name": "Kunavo",
        "baseUrl": "https://api.kunavo.com/v1",
        "apiKey": "${KUNAVO_API_KEY}",
        "models": ["claude-sonnet-4-6"],
        "contextWindow": 1000000
      }
    ]
  }
}

关于该配置块，有三点说明，均来自 v1.30.0 提供商文档。sdkProvider 被省略是因为它默认为 openai-compatible；该版本 sdkProvider 选项表中的其他值为 google、anthropic 和 github-copilot，而 chatgpt-codex 在其单独的提供商页面中记录，不在该表中。密钥和其他配置值支持 $VAR、${VAR} 和 ${VAR:-default} 替换。此外，requestTimeout 默认为 120,000 ms，使用 -1 可禁用它——这对运行缓慢的本地模型而言，比对托管模型重要得多。

上下文窗口是最可能因遗漏而让你多花钱的部分。Nanocoder 按文档规定的六步顺序解析模型的上下文限制：先是 /context-max 或 --context-max 会话覆盖值，然后是 contextWindows[model]，接着是 contextWindow，再接着是 NANOCODER_CONTEXT_LIMIT，然后是 models.dev 元数据，最后是内置的 Ollama 回退映射。由于 Kunavo 不在 models.dev 中，最后两步无法提供帮助，因此前四项中必须手动设置一项——上面的数值来自该模型自己的 Kunavo 目录条目。这不仅影响显示仪表盘：auto-compact 会在解析后的上下文限制达到某个百分比时触发，默认值为 60；错误的限制会改变代理压缩并重新发送上下文的频率，而这会影响 token 消耗。

首次运行前还有一个坑。如果你将 sdkProvider: "anthropic" 设置为某个端点，而该端点提供的模型 ID 没有被底层 SDK 识别为 Claude 模型，它会回退到 4096 token 的输出上限，导致长回复在句子中间被截断且不报错。这在 main 的提供商文档中“输出 Token 上限”一节有所描述，而上限本身来自 @ai-sdk/anthropic；v1.30.0 已经依赖该版本，因此尽管文档尚未发布，这种行为已经存在于已发布版本中。该页面列出的修复方式 maxOutputTokens 也尚未发布；在 v1.30.0 中，规避方法是继续使用默认的 openai-compatible 路径。

Kunavo 发布了 Nanocoder 设置指南，它是配置参考，而不是兼容性测试：Nanocoder 尚未针对 Kunavo 的端点进行运行时测试，因此这里无法端到端确认流式传输、工具调用、身份验证和模型路由。尝试时请保留一条可用路线，运行一个有界任务，然后读取账户为该任务记录的实际费用，而不是查看页脚。准备为密钥充值时，请创建 Kunavo 账户。

你是在比较客户端，而不是比较路由吗？Nanocoder 与 OpenCode 对比将该代理与主流代理进行比较，OpenCode 定价介绍了一款其维护者确实销售 token 的客户端，而代理 API 目录记录了这一领域每个客户端如何处理自定义基础 URL。

常见问题

截至 2026 年 9 月 21 日核查：npm 注册表中的已发布版本、引擎和许可证；v1.30.0 关于提供商、命令、tune 和 battlemap 的文档页面，包括针对缺失功能的 grep 计数；v1.30.0 变更日志和已发布源代码中的成本公式与 models.dev 查询；已打包软件自身的成本格式化器；models.dev/api.json 中的提供商列表及上文重现的费率；v1.30.0 所依赖的 @ai-sdk/anthropic 版本，该依赖提供 4096 token 上限；Ollama 定价页面；Atlas Cloud 的编码方案页面；以及 OpenRouter 的 FAQ。本页面目标查询的搜索量在相关研究中未进行测量，底层搜索结果快照日期为 2026 年 9 月 17 日。Nanocoder 未针对 Kunavo 进行运行时测试，未运行模型基准测试，本页面所有 Kunavo 美元金额均为基于实时目录的说明性 token 算术，而不是实测任务成本。