Nanobot API 成本与配置：提供商、模型和限制

来自 HKUDS 的 nanobot 成本为 $0：它是采用 MIT 许可证的软件，由你自行安装和运行，其 GitHub 仓库和 nanobot.wiki 均未发布计划、层级、席位或托管服务。你需要预算的是模型令牌、维持 nanobot gateway 运行的机器，以及你接入的任何付费频道或工具账户。随后有两件事决定令牌成本：你在 config.json 中写入哪个提供商密钥，因为该密钥单独决定线路协议；以及 nanobot 在未被要求的情况下启用的后台任务。

于 2026 年 9 月 21 日根据 GitHub 和 PyPI API 核查：发布版本 v0.3.5 于 2026 年 9 月 15 日发布；软件包 nanobot-ai 0.3.5，MIT 许可证，要求 Python 3.11 或更高版本，于同日上传；仓库采用 MIT 许可证，未归档，最后一次推送发生在核查当天。本页面始终遵循一项范围说明：以下引用的文档读取自 main 分支，该分支的开发进度比 v0.3.5 标签领先五天，因此文档中的说明与已发布源代码的默认值会分别标注，绝不混为一谈。

首先确认你正在为哪个 nanobot 估价

nanobot.ai 不是 nanobot 价格页面。2026 年 9 月 21 日，它重定向至 obot.ai，标题为“Obot | Enterprise AI Control Plane & MCP Gateway”——这是另一家公司的企业产品，该产品自身也没有发布价格，因为其 /pricing URL 当天返回了 404。还有两个名称冲突：直接名为 nanobot 的 PyPI 软件包版本为 0.4.1，是一个机器人导航框架，因此 pip install nanobot 安装的是错误的软件；而 obot-platform/nanobot 是一个采用 Apache-2.0 许可证的 Go 项目，其 README 开头就声明处于维护模式，因此其配置键不适用于此处。

nanobot 的成本逐项说明

这里有两个需要如实说明的缺口。nanobot 的 CLI 参考描述了与独立“Desktop”运行时共存的情况，但没有找到其公开下载页面、仓库或价格——因此能够支持的说法范围很窄：两个官方页面上都没有发布付费层级，而不是任何地方都不存在付费组件。语音这一行则是硬性停止条件，而不是价格问题。限制比“没有自定义端点”更窄：v0.3.5 的转录适配器确实都接受 apiBase，因此可以替换为 OpenAI 形状的转录端点，但 transcription.provider 本身必须是该注册表中的名称——这里不像聊天那样可以自行发明提供商密钥。无论如何，在此处这并不重要，因为 Kunavo 不提供语音转文本模型。

nanobot 自定义提供商：两条路径，且只有一条可由你命名

这正是通用“设置基础 URL”示例出错的地方。在 nanobot 中，协议由你填写的提供商键决定，而不是由你设置的某个字段决定；两条路径不可互换。

路径 A — OpenAI 兼容。 在 providers 下创建一个键，或使用内置的 custom 键，然后将预设指向它。根据提供商参考，自定义键会被视为直接的 OpenAI 兼容提供商；由于 nanobot 无法知道端点 URL，因此必须设置 apiBase；本地服务器或私有代理可以选择设置 apiKey。在 apiBase 中包含版本路径。

{
  "providers": {
    "kunavo": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com/v1"
    }
  },
  "modelPresets": {
    "primary": {
      "provider": "kunavo",
      "model": "claude-sonnet-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    },
    "cheap": {
      "provider": "kunavo",
      "model": "claude-haiku-4-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "primary",
      "dream": {
        "modelOverride": "cheap"
      }
    }
  }
}

同一份参考资料还规定了这部分配置必须遵循的三条规则。不要与内置名称或别名冲突，例如 openai、openai-codex、github-copilot 或 lm-studio。不要在自定义键上设置 apiType——它只适用于 providers.openai，v0.3.5 的架构同样强制执行这一点。只有当你的端点文档说明存在非标准的思考开关时，才设置 thinkingStyle；可接受的值为 thinking_type、enable_thinking 和 reasoning_split。模型 ID 需要精确表述，不能只引用文档中的那句话：文档称，在显式命名的自定义提供商下，模型会按原样发送；而随附的 0.3.5 注册表会将动态规范的 strip_model_prefixes 设置为提供商键本身的名称及其 snake_case 形式。如果文档所说的是外部前缀，则两者都成立——等于你的提供商键的前缀会被剥离，其他前缀则会继续传递；并且基于前缀的提供商推断仅在提供商为 "auto" 时运行。

路径 B — Anthropic Messages。 此协议完全没有通过自定义名称使用的路径：参考资料指出，任意自定义提供商名称仅兼容 OpenAI，不使用 Anthropic Messages 请求格式；命名的自定义路径也不适用于 Anthropic 兼容端点。你需要改写内置配置块：

{
  "providers": {
    "anthropic": {
      "apiKey": "${KUNAVO_API_KEY}",
      "apiBase": "https://api.kunavo.com"
    }
  },
  "modelPresets": {
    "primary": {
      "provider": "anthropic",
      "model": "claude-sonnet-5",
      "maxTokens": 8192,
      "contextWindowTokens": 200000
    }
  },
  "agents": {
    "defaults": {
      "modelPreset": "primary"
    }
  }
}

由于这会直接编辑 providers.anthropic 本身，网关会为指向该提供商的每个预设替换直接 Anthropic，而不是与其并列；原生后端也不接受 proxy，因此这里无法使用它。Kunavo 的两种基础 URL 约定恰好对应这两条路径：基础 URL 参考为 Messages 路径提供源站地址，为 OpenAI 兼容路径提供 /v1 形式。nanobot 在这一点上格外宽容——其随附的 0.3.5 anthropic 提供商会在将 URL 交给 SDK 之前去除末尾的 /v1；其注释说明了原因：Anthropic SDK 会在内部将 /v1 追加到请求路径。因此，在 nanobot 中两种写法都有效。不要将这一习惯带到会原样把基础 URL 传给 Anthropic SDK 的客户端中，否则追加的 /v1 会重复。关于上面配置块的最后两点：contextWindowTokens 是 nanobot 在 v0.3.5 中自带的预设默认值，而不是任何模型的属性，因此实际数值应以模型页面为准；fallbackModels 中的条目是预设名称，而不是原始 ID，且上下文大小取链路中最小的窗口。

nanobot 中的提示缓存遵循你选择的协议

这就是路径 A 与路径 B 在成本上的差异，并且可以从随附源码中直接看到。在 v0.3.5 中，提供商规范包含 supports_prompt_caching，默认值为 false；只有两个规范将其设为 true：anthropic 和 openrouter。只有在该标志已设置并且模型 ID 以 anthropic/ 或 claude 开头时，OpenAI 兼容客户端才会注入缓存控制标记。内置的 custom 规范以及所有动态创建的自定义提供商都会将该标志保留为 false，因此 OpenAI 兼容的自定义路径完全不会发送缓存标记，而原生 anthropic 后端则默认应用这些标记。

这是关于客户端发送内容的说明，而不是关于端点自身如何处理的说明——端点可能仍会在服务器端进行缓存。nanobot 提供了检查手段：一条路径会规范化 prompt_tokens_details.cached_tokens，另一条路径会读取 cache_creation_input_tokens 和 cache_read_input_tokens。这里尚未测试 Kunavo 是否会将这些字段返回给 nanobot，因此在将周期性任务按已缓存处理并编入预算之前，请先通过一次真实调用核对返回的用量；提示缓存和缓存文档展示了正常缓存的表现。

nanobot 的最佳模型：供应商未发布排名

诚实的答案正是 nanobot 自己给出的答案：其提供商参考资料说明，文档展示具体提供商名称是为了让 JSON 可以直接复制，而不是因为 nanobot 会对提供商进行排名。没有可引用的供应商基准测试。它提供的是一个默认值——v0.3.5 的代理默认值将 anthropic/claude-opus-4-5 作为名称，提供商设为 auto，最大令牌数为 8192，并假定上下文为 200,000 个令牌。该 ID 不在 Kunavo 目录中，因此面向此处的预设必须使用目录实际列出的 ID；ID 会发生变化：请从目录读取当前 ID，而不要从任何页面（包括本页）读取。

费率是实时的 Kunavo 目录价格，任务列则取决于 nanobot 的结构，而不是任何人测得的质量排名。 如需按能力而非配置进行系列比较，请参阅 Opus 与 Sonnet 与 Haiku 的对比。

一个完整估算：手动输入的轮次，加上 nanobot 为你运行的周期性任务

这些是用于说明的令牌算术，不是测得的任务成本，也不是账单上限。假设一个助手每天处理20 个手动输入轮次，持续 30 天；每轮假定有 10,000 个未缓存输入令牌和 600 个输出令牌——每月输入 6.0M 个令牌，输出 0.36M 个令牌。

日程安排是有来源依据的部分；令牌大小和实际会产生费用的运行次数都不是。nanobot 的配置参考默认在 intervalS 1800 启用网关心跳，v0.3.5 的 Dream 配置默认在 intervalH 2 启用；换算下来，30 天内分别有 1,440 次心跳和 360 次 Dream 运行。一次运行不等于一次模型调用。在随附的 v0.3.5 网关中，心跳任务会读取 HEARTBEAT.md；如果文件不存在或其中没有 ## Active Tasks 标题下的内容，则会在发出任何模型请求前返回；如果自游标以来没有积累新的历史记录，Dream 任务会记录“无内容可处理”并返回。因此，空闲安装不会为任一任务付费，而 1,800 是日程允许的上限，并不是你一定会达到的下限。nanobot 没有发布任一任务每次运行的令牌数，因此上面的三个数值只是占位符，应替换为你自己的测量结果；这些运行的输出令牌也未计入。不要把其他代理的心跳数据套用到这里，它们属于不同的程序。

两个调节手段并不对称。Dream 接受 modelOverride，用于指定更便宜的预设——仅接受预设名称，拒绝原始 ID——上面路径 A 配置块中已经给出了这一行改动。心跳没有文档化的模型覆盖选项：其选项为 enabled、intervalS 和 keepRecentMessages，因此只能降低频率或关闭；由于它是系统管理的 cron 任务，无法使用 cron 工具删除；应在配置中禁用它，然后重启网关。只要有任务需要运行，心跳评估就是配置参考列出的会打开模型流的内部任务之一，因此成本取决于你放入 HEARTBEAT.md 的内容，而空文件是成本最低的情况。针对 Kunavo 的nanobot 与 OpenClaw 对比页面中“Dream 默认按 cron 计划运行”的说法，需要补充一点：这与记忆参考资料一致，而 v0.3.5 的表述更精确——它按每 2 小时一次的间隔计划运行，其中 cron 是旧版覆盖设置。

Kunavo 目录金额是计费下限而非上限：上游报告费用后，账单取目录成本与上游成本乘以适用加价之间的较大值。缓存费用、工具和托管成本不包含在这些示例中。最低充值金额为预付余额中的$10 ——这是资金充值最低额，不是任务费用或订阅费用。请参阅账单详情和成本优化了解测量方法。

先设定循环边界，再通过一次运行进行验证

nanobot 的三个每轮边界中，有两个根本不在其配置参考资料中。根据随附的 v0.3.5 源码，代理默认值包含 max_tool_iterations 200 和 max_tool_result_chars 16,000；只有 maxConcurrentSubagents（默认值为 4）出现在 main 的文档参考中。200 次迭代上限正是昂贵失控轮次的形态，因此应有意设置，而不是直接继承。

然后按文档规定的顺序进行验证。nanobot status有意不发送模型请求，因此可以在不产生任何费用的情况下确认配置；CLI 参考资料要求随后运行 nanobot agent -m "Hello!"。其症状表对应自定义端点产生的四种故障：401 表示键缺失、已过期、带有空白填充或存储错误；找不到模型表示该提供商不存在此 ID；连接被拒绝表示本地提供商服务器未运行，或 apiBase 指向了错误端口；找不到提供商表示活动预设中的提供商拼写错误。

然后根据金额而不是令牌进行核对。在 v0.3.5 中，nanobot 会记录每次提供商调用，并使用 source 对照 user、api、cron、dream 和 system 进行验证——这一区分将后台支出与手动输入支出分开；但该模块中任何位置都没有成本字段。其 WebUI 会按轮次显示输入令牌，并在报告缓存命中率时一并显示，同时明确声明这些数字不是账单；截至 2026 年 9 月 21 日，在查阅的 CLI 参考资料中也没有出现汇总支出命令（这是该文档中的缺失，并不能证明不存在此命令）。请从你的提供商账本中读取费用。

哪条路径更合适，以及它会带来什么成本

两个边界说明。图像生成接受 custom 作为提供商值，并且默认关闭；但这里尚未测试 Kunavo 的图像端点是否匹配 nanobot 发送的请求形状——这是未验证，而不是一项功能。还有一项你不会产生的成本：nanobot 的持久记忆是工作区下的普通文件，而不是向量索引；这很方便，因为 Kunavo 不提供嵌入模型。

Kunavo 没有发布 nanobot 集成页面，也没有在运行时针对其端点测试 nanobot——上面的每个配置块都来自 nanobot 自己的文档及其随附的 v0.3.5 源码，因此应将它们视为可尝试的配置参考，而不是兼容性结论。保留一条可用路径，运行一个有界任务，然后读取账户为其记录的内容。快速入门和基础 URL 参考涵盖两种端点约定，而创建 Kunavo 账户是为密钥充值之前的步骤。仍在选择程序？nanobot 与 OpenClaw 对比会比较两者的运行时，代理 API 目录则按线路协议和 BYOK 边界为客户端编目。

常见问题

截至 2026 年 9 月 21 日核查的来源：HKUDS/nanobot 和 nanobot-ai 的 GitHub 与 PyPI API，main 分支上的 nanobot 提供商、配置、记忆和 CLI 文档，以及从 PyPI 下载的随附 v0.3.5 源码（所有数值默认值均来自该源码）。文档陈述和源码默认值相隔五天，全文分别标注。Kunavo 未在运行时测试 nanobot；令牌费率来自实时目录，所有美元数值均是在所述假设下的说明性算术结果。