Nanocoder 定價：免費 CLI、模型帳單與成本頁尾

Nanocoder 是免費的：CLI 採用 MIT 授權，沒有帳戶、層級或授權金鑰，因此實際上的「Nanocoder pricing」指的是其背後的模型帳單——您所設定供應商的 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」，宣稱提供「more budget-friendly API access」。這項建議出現在贊助商協助資助的文件中，不能證明該方案最便宜。這些coding plans是按月訂閱，附帶每週點數額度；點數會按照輸入 token 乘以輸入倍數，再加上輸出 token 乘以輸出倍數的方式消耗，且倍數按模型設定——因此每百萬 token 的成本取決於您執行哪個模型，不能以單一數字與費率表並列。

終端機中的成本數字不是您的帳單

Version 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 費率，完全不讀取層級，因此超過層級門檻的回合會被低估。Version 1.30.0 自己的變更記錄指出，該估算值「以標準費率計算所有輸入 token——未納入快取讀取／寫入折扣，因此對支援提示快取的供應商而言，成本可能被高估」。請參閱提示快取，了解路由支援這些折扣時的實際情況。

該表中的費率是某個時間點的快照：models.dev 持續編輯，而在 context limit 最高的平手決勝中勝出的項目，可能在您的電腦沒有任何變化的情況下改變。重現步驟很短——擷取 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 微調文件，預設的 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 的常見問題指出，「推理定價不加價」，而是「在你購買額度時」收取費用；對於超過方案所定額度的自帶金鑰使用，還會收取另一項費用。這些百分比會依付款方式與方案而異，並在頁面載入時填入，因此這裡不引用任何數值——請在自己的結帳頁面查看目前數值。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 目錄項目。這不只是顯示儀表的問題：自動壓縮會在解析後上下文限制的某個百分比處觸發，預設為 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 registry 中的已發布版本、引擎與授權條款；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 的常見問題。本頁目標查詢的搜尋量在相關研究中未經測量，而底層搜尋結果快照的日期為 2026 年 9 月 17 日。Nanocoder 未針對 Kunavo 進行執行時測試，未執行任何模型基準測試，而這裡所有 Kunavo 的美元數值都是來自即時目錄的示意性 token 計算，而非實測任務成本。