Nanocoder 與 OpenCode：工作流程、模型與總成本

OpenCode 是預設選擇，而 Nanocoder 是有意選擇的少數派方案：2026 年 9 月 19 日，OpenCode 擁有 208,444 顆 GitHub 星，Nanocoder 則有 2,487 顆；在截至 9 月 16 日的 30 天內，其 npm 套件下載次數為 9,436,914，Nanocoder 則為 6,614。 兩者都是免費、採 MIT 授權的終端機程式碼代理，讓你可以指定自訂 API 端點。在兩者之間做選擇不是品質排名，而是在功能範圍最廣、同時有兩個第一方產品競爭你的 token 支出的方案，與功能範圍較窄、由不販售任何東西的集體維護的方案之間做選擇。

請將這些下載數視為數量級，而不是使用者人數。OpenCode 也能透過 curl 指令碼和 Homebrew 安裝，而 CI runner 會放大任何 npm 數字；Nanocoder 除了 npm 外，也透過 Homebrew 和 Nix 發行。比例在方向上可靠，但絕對數字並不可靠。

首先，請確認你比較的是正確的兩個專案

搜尋結果中直接出現三個名稱相撞的專案，而其中兩個會破壞設定，不只是造成混淆。

在你遵循較舊教學之前，還有一項值得了解的變更。許多指南仍稱為 sst/opencode 的儲存庫現在會 301 重新導向至 anomalyco/opencode，而 sst GitHub 組織已清空，描述顯示其已移至 anomalyco（GitHub API，2026 年 9 月 19 日）。OpenCode 自己的文件也在安裝指令中佐證此事——brew install anomalyco/tap/opencode、ghcr.io/anomalyco/opencode——且每個文件頁面的頁尾都標示 Anomaly 版權。產品名稱沒有變，只有組織變更。社群媒體上流傳一個重新命名日期，但此處無法驗證，因此本頁不予發布。

誰應該選哪一個

請從你的預設模型開始，而不是從功能清單開始。如果你日常已使用託管的前沿模型，而本機推論只是偶爾的實驗，OpenCode 的取向就符合你。如果你日常使用 Ollama、llama.cpp、LM Studio、vLLM 或 MLX，而託管 API 反而是例外，Nanocoder 的取向就符合你——不過這是預設值的差異，而非能力差異，因為 OpenCode 也記錄了 Ollama、LM Studio 和 llama.cpp 的 base URL。

在提供者層，遷移成本對稱且很小；在其上層則不對稱。自訂端點在任一用戶端中都只是一個 JSON 區塊，因此將閘道移植過去只需幾分鐘。無法移植的是你在其上建立的內容：Nanocoder 在 .nanocoder/skills/ 下的 Skills 套件及其生命週期 hook——其中 pre-tool-use hook 以非零狀態結束時會拒絕呼叫並告知模型原因——沒有可貼入的 OpenCode 對應項目，而 OpenCode 的每代理權限區塊、外掛程式和 LSP 設定也沒有 Nanocoder 對應項目。請先計算這些工作，再計算設定檔行數。

兩個用戶端實際有何不同

本表來源均於 2026 年 9 月 19 日查閱，除非另有註明：GitHub API、npm 套件登錄庫、Nanocoder 的設定與功能文件，以及 OpenCode 的設定、權限與CLI頁面。

將任一者指向你自己的 API 端點

兩者的文件都說明自訂端點，因此閘道在任一者中都是受支援的設定。差異在於你可以連接多少種線路格式。

OpenCode 會在提供者區塊中指定 npm 套件，而該選擇會決定協定：@ai-sdk/openai-compatible 使用 /v1/chat/completions，@ai-sdk/openai 使用 /v1/responses。Kunavo 同時提供兩者，因此這是實際選擇，而非形式上的差異。

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "kunavo": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Kunavo",
      "options": {
        "baseURL": "https://api.kunavo.com/v1",
        "apiKey": "{env:KUNAVO_API_KEY}"
      },
      "models": {
        "claude-sonnet-4-6": {
          "name": "Claude Sonnet 4.6",
          "limit": { "context": 200000, "output": 64000 }
        }
      }
    }
  }
}

providers 頁面明確說明了兩項與任何尚未識別的端點相關、且值得注意的細節。第一，使用 /connect 註冊金鑰，捲動至 Other，並使用你在檔案中採用的相同 provider id；憑證會寫入 ~/.local/share/opencode/auth.json。第二，這裡值得設定 limit 區塊——文件指出標準提供者會自動從 models.dev 取得 context 和 output 限制，而 Kunavo 不在其中。上方區塊中的數值是文件自己的範例數字，不是此模型公布的限制；在依賴 context meter 前，請先根據模型自己的頁面設定。

Nanocoder 的對應設定位於 nanocoder.providers 下。請注意小寫的 baseUrl，它與 OpenCode 的 baseURL 不同；此外，${VAR} 會遞迴套用至字串欄位。

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

在貼上這段設定前，值得先了解三個 Nanocoder 特有的陷阱。sdkProvider union 在 source/types/config.ts 中僅限五個值——openai-compatible、google、anthropic、chatgpt-codex 和 github-copilot——而第四個值綁定的是透過瀏覽器登入 ChatGPT 自有 Codex 端點，而非任意 base URL，因此沒有可宣告的通用 Responses 選項。如果改為將 sdkProvider: "anthropic" 指向 Anthropic 相容端點，Nanocoder 自己的 provider 文件警告，@ai-sdk/anthropic 會根據模型 ID 推導輸出上限，對任何未辨識為 Claude 模型的模型回退至 4096 tokens，並在沒有錯誤的情況下於句中截斷長回覆；修正方式是在提供者項目中明確設定 maxOutputTokens。此外，由於設定會按區塊解析，定義 nanocoder.providers 的專案層級檔案會提供整個區塊——全域設定中的同層項目不會合併進來。nanocoder config diff 是查看實際解析結果的文件記載方式。

這兩段程式碼都尚未針對 Kunavo 的端點進行執行階段測試。Kunavo 提供了 OpenCode 設定指南，但這份指南是設定參考，而非相容性測試；Kunavo 也未提供 Nanocoder 的設定指南。請將這兩段程式碼視為起點，執行一項範圍明確的任務，並查看您的帳戶實際記錄了什麼。

一項共同缺口：兩個用戶端都不了解你閘道的模型中繼資料

兩個用戶端都依賴 models.dev 取得上下文限制、輸出上限和每 token 成本。該檔案在 2026 年 9 月 19 日檢查時列出 222 個提供者，Kunavo 不在其中——本頁無法確定缺少它的原因。其影響在兩個用戶端之間略有不同，但同樣適用於兩者，因此這不是偏好其中一者的理由。

在 OpenCode 中，請為每個模型宣告 limit.context 和 limit.output，否則剩餘 context 指示器會以不是你模型實際值的預設值計算。在 Nanocoder 中，請設定 contextWindow 或各模型的 contextWindows；其每次回應頁尾會顯示 token 計數，以及依 models.dev 定價估算的費用；文件謹慎說明，沒有定價資料時會省略費用部分，因此缺少數字代表未知，而不是零。無論如何，用戶端數字都是根據回報 token 進行的自身計算——請與你的提供者帳本核對，而不是與頁尾核對。

每個選項會讓你付出什麼

兩個用戶端都是免費的。不對稱之處在於它們背後的事物。

Nanocoder 沒有帳戶、方案、託管服務，也沒有可升級的項目——其 README 表示沒有付費方案限制實用功能，而專案自稱由贊助者而非使用者出資。這裡有一項披露：Atlas Cloud 是列出的贊助者，同時也出現在 Nanocoder 自己的支援提供者清單中，並販售 coding plan。在一個原本不受供應商影響的專案中，這構成非中立的誘因；你應該知道這件事，而不是不知道。

OpenCode 也免費，但同一供應商販售兩項產品，而它們恰好競爭閘道想要支出的同一筆費用。兩者都不是必要項目：文件將兩者描述為選用方案，而 Zen 的目標頁面承諾讓你在 OpenCode 中使用任何其他提供者。

查閱日期為 2026 年 9 月 19 日。此表特別謹慎處理兩件事。Zen 的目標頁面表示，計畫以成本價銷售並將降價轉嫁給使用者，僅加收足以支付處理費的加成。它公布的三個 Claude 費率確實與Anthropic 自己公布的費率一致——Opus 5 為 $5 / $25、Sonnet 5 為 $2 / $10、Haiku 4.5 為 $1 / $5——因此，就這三個模型而言，與 Zen 的比較就是與模型供應商費率表的比較。該核對僅針對這三個模型，於 2026 年 9 月 19 日進行，不能說明 Zen 貨架上其他模型的情況。此外，Zen 的免費模型在同一頁面列出資料使用說明，範圍從免費期間使用資料改善模型，到僅供試用且告知不要提交機密資料的端點。附帶訓練權利的免費方案，與不附帶訓練權利的免費方案，是不同的產品。

任一用戶端底層 token 帳單的計算範例

這是說明性的 token 計算，不是實測任務成本，也不是帳單上限。假設一個工作階段傳送 200,000 個未快取輸入 token，並接收 15,000 個輸出 token。費率取自即時的 Kunavo catalog，按每百萬 token 計算；你的實際工作階段會因儲存庫大小、工具輸出，以及代理重新讀取檔案的頻率而有所不同。

這裡人們真正想比較的是 OpenCode Go 每月 $10 的方案，但兩者並非同類比較。Go 提供固定的模型陣容，每個模型的月度上限為 $15 至 $60：其使用限制表沒有 Claude 模型，也沒有 Gemini 模型；唯一的 GPT 項目是 GPT 5.6 Luna，Grok 4.6 也在其中——因此文件中的「open coding models」並不代表僅限開放權重模型（查閱日期為 2026 年 9 月 19 日）。上面的模型屬於完全不同的陣容。按這些假設，$10 的預付 Kunavo 額度，估算約可支應使用 Claude Haiku 4.5 的 51 個此類工作階段，每個工作階段的成本為 $0.192；使用 Claude Opus 5 時則約可支應 10 個工作階段。這只能協助估算預算；它無法告訴你哪個模型在你的儲存庫上產出更好的工作，而列出的最低費率也不等同於完成任務的最低成本——需要嘗試三次的較便宜模型，可能比只需一次的模型更昂貴。

真正可直接比較的是 Zen 的隨用隨付貨架，因為同一模型會出現在兩邊。Zen 將 Claude Opus 5 定價為每百萬輸入 token $5.00、每百萬輸出 token $25.00；Kunavo 的 catalog 目前顯示同一模型的價格為 $3.50 和 $17.50。這才是值得進行的比較，而且值得仔細閱讀：Zen 的 $5.00 / $25.00 是 Anthropic 為此模型公布的自有費率，因此這是兩個 catalog 對同一模型採用不同定價，而不是加價轉售商被低價擊敗。移動預算前，請在結帳時確認兩邊的價格，因為任一 catalog 都可能重新定價。

Kunavo 的目錄金額是計費下限，而非上限：上游回報其費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者中較高者。快取費用與外部工具不在此範例中。最低加值金額為預付額度中的 $10 ，這是資金最低門檻，而非任務費用或訂閱費。

設定您選擇的方案

如果您選擇了 OpenCode，上方的設定區塊就是完整的整合方式，而 OpenCode 整合指南會詳細說明兩種線路格式；準備為金鑰儲值時，請建立 Kunavo 帳戶。如果您選擇了 Nanocoder，請透過其 openai-compatible provider 使用相同的基礎 URL，並在嘗試期間保留可運作的路由——此處未進行 Nanocoder 與 Kunavo 的執行階段測試。

還在考慮嗎？OpenCode 替代方案將選擇範圍擴展到這兩者之外，適用於 OpenCode 的最佳 API會專門比較該用戶端的 provider 路由，OpenCode 定價則深入介紹 Zen 與 Go，而代理程式 API 目錄記錄此領域中每個用戶端如何處理自訂基礎 URL。如果 provider 區塊已經失敗，找不到 OpenCode provider涵蓋常見原因，而OpenAI 相容 API說明這個詞組能保證與不能保證的事項。

常見問題

儲存庫、版本發布與下載數據於 2026 年 9 月 19 日從 GitHub API 及 npm 套件登錄庫查閱取得；行為與價格聲明於同日從兩個專案各自的官方文件查閱取得，models.dev 的提供者清單也於當日查核。兩個用戶端都未針對 Kunavo 的端點進行執行階段測試，未進行效能或相容性測試；本頁 Kunavo 的所有美元金額，都是根據即時目錄所做的示意性 token 算術，而非實測任務成本。