Nanobot API 成本與設定：供應商、模型與限制

HKUDS 的 nanobot 費用為 $0：它是採 MIT 授權、由你自行安裝與執行的軟體，而其 GitHub 儲存庫與 nanobot.wiki 都沒有發布方案、層級、席次或代管服務。你需要編列預算的是模型 token、維持 nanobot gateway執行的機器，以及你連接的任何付費頻道或工具帳戶。接著有兩件事決定 token 的成本：你在 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。還有兩個名稱衝突：PyPI 上直接命名為 nanobot 的套件版本是 0.4.1，屬於機器人導航框架，因此 pip install nanobot 會安裝錯誤的軟體；而 obot-platform/nanobot 是採 Apache-2.0 授權的 Go 專案，其 README 開頭便聲明處於維護模式，因此其設定鍵不適用於此處。

nanobot 的成本，逐項說明

這裡有兩項需要如實說明的缺口。nanobot 的 CLI 參考描述了與獨立「Desktop」執行環境共存的方式，但未找到其公開下載頁面、儲存庫或價格——因此能支持的說法很有限：兩個官方介面都沒有發布付費層級，而不是任何地方都不存在付費元件。語音列則是硬性限制，而非價格問題。這項限制比「沒有自訂 endpoint」更狹窄：v0.3.5 的轉錄 adapter 都接受 apiBase，因此可以替換為 OpenAI 形式的轉錄 endpoint，但 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 為供應商，並假設最大 token 數為 8192、上下文為 200,000 token。該 ID 不在 Kunavo 的目錄中，因此針對此處的預設設定必須指定目錄實際列出的 ID，而且 ID 會變動：請從目錄讀取目前的 ID，不要依賴任何頁面，包括本頁。

費率是即時的Kunavo 目錄價格，而工作欄位是根據 nanobot 的結構推導而來，不代表任何人測量過的品質排名。 若要比較能力而非設定，請參閱 Opus 與 Sonnet 與 Haiku 的比較。

一份完整估算：輸入的回合，加上 nanobot 代你執行的週期

這些是示意性的 token 算術，不是經測量的工作成本，也不是帳單上限。假設一個代理程式每天處理20 個輸入回合、持續 30 天，每回合假設有 10,000 個未快取輸入 token 和 600 個輸出 token——每月輸入 6.0M token、輸出 0.36M token。

已取得來源依據的是排程；token 大小以及實際會產生費用的執行次數都不是。nanobot 的設定參考文件預設會在 intervalS 1800 啟用閘道心跳，而 v0.3.5 的 Dream 設定預設會在 intervalH 2 啟用；換算後，30 天內分別會有 1,440 次心跳 tick 和 360 次 Dream tick。一次 tick 不等於一次模型呼叫。 在已發布的 v0.3.5 閘道中，心跳工作會讀取 HEARTBEAT.md；如果檔案不存在，或 ## Active Tasks 標題下沒有內容，就會在任何模型請求前返回。Dream 工作則會記錄「沒有可處理的內容」，並在游標之後沒有累積新歷史時返回。因此，閒置安裝不會為任一工作支付費用，而 1,800 是排程允許的上限，不是你一定會達到的下限。nanobot 未發布任一工作的每次執行 token 數，因此上述三個數值都是佔位值，應以你自己的測量結果替換；這些執行的輸出 token 不計入。請勿將其他代理程式的心跳數據套用在此處；它們屬於不同的程式。

兩個調節方式並不對稱。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 指向錯誤的連接埠；找不到供應商表示目前預設設定中的供應商拼寫錯誤。

接著以金額而非 token 進行核對。在 v0.3.5 中，nanobot 會以 source 記錄每次供應商呼叫，並根據 user、api、cron、dream 和 system 進行驗證——這種區分可將背景支出與輸入支出分開；但該模組中任何位置都沒有成本欄位。其 WebUI 圖表會顯示每回合的輸入 token，並在有回報時顯示快取命中率，同時明確表示這些數字不是計費明細；在 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；token 費率來自即時目錄，所有美元數字都是基於所述假設的範例計算結果。