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

VT Code 和 OpenCode 都是免費的終端機程式碼代理，對用戶端不收費，也都接受你自己的 OpenAI 相容端點，因此這不是價格比較。真正的差異在於：各自允許你在哪裡宣告該端點、權限預設值指向哪一方，以及你是否希望在同一個工具中使用每月 $10 的訂閱。 VT Code 是由一個獨立專案、在一位維護者主導下提供的單一 Rust 二進位檔。OpenCode 則是 Anomaly 公司提供的 TypeScript 代理，附有桌面應用程式、編輯器擴充功能，以及自有的兩個第一方錢包。

首先必須釐清兩個名稱陷阱，因為其中任何一個弄錯，後面的所有內容都會失效。「VT Code」不是 Visual Studio Code，而且 VT Code 令人困惑地提供了自己的 VS Code companion extension，使用另一套版本序列。至於 有三種不同的東西都叫作 OpenCode——本比較只涉及其中一種。

您實際比較的是什麼

儲存庫中繼資料、發布版本和 dist-tags 於 2026 年 9 月 21 日從 GitHub API、npm 和 crates.io 讀取。還有第四個名稱衝突：「OpenCode Go」也是 Anomaly 每月 $10 訂閱方案的名稱，與 Go 語言或已封存的 Go CLI 毫無關係——而 VT Code 將其中一個內建供應商的設定識別鍵命名為 opencode-go，使情況更加混淆。另請注意 VT Code 版本更新得多快：0.164.0、0.164.2 和 0.165.0 在 9 月 20 至 21 日約 27 小時內全部發布，因此請查看版本標籤，不要相信任何頁面（包括本頁）印出的版本號。

誰應該選哪一個

關於遷移成本。 較容易的部分是 AGENTS.md：兩項工具都從專案根目錄讀取它，因此描述你慣例的檔案無論往哪個方向移動都能原封不動地保留。較困難的部分是其他一切。兩種設定格式完全不同——帶有陣列表格的 TOML，對上每個供應商指定一個 npm 套件的 JSON——而且沒有轉換器，因此專案本機設定必須手動重寫。本頁沒有確定 MCP 定義、技能、外掛、自訂代理或工作階段歷史是否能移轉，因此除了該重寫之外，不估算遷移時間。

值得用來做決策的唯一不對稱：端點可以放在哪裡

這是一般範本都不會提到、而且會顛覆常見 monorepo 直覺的差異。OpenCode 將自訂供應商視為一般專案資料：提交 opencode.json 即可運作，團隊便能在一個經審查的檔案中，將所有人標準化到同一個閘道。VT Code 則刻意拒絕這種做法。

VT Code 的 設定欄位參考 在欄位本身明確寫道：「由儲存庫控制的工作區／專案層級所提供的非空值會遭拒；請在受信任的系統／使用者設定中，或明確選取的設定中定義供應商端點。」相同的拒絕規則也重複出現在 custom_providers[].base_url、custom_providers[].auth.command、provider_overrides.*.base_url 和 .api_key_env。其 安全模型 將這項理由命名為獨立層級——載入器會記錄每個合併欄位的勝出來源，將工作區根目錄檔案、工作區 .vtcode/ 檔案和專案設定檔視為由儲存庫控制，並在供應商驗證前採取預設拒絕；文件表示這可防止儲存庫引入自訂供應商的可執行 auth.command，或透過被覆寫的基底 URL 重新導向請求。

因此實際結果是：使用 OpenCode，一個合併後的 pull request 就能讓整個團隊指向某個閘道。使用 VT Code，同樣的變更必須逐台安裝到使用者或系統設定中，或在啟動時傳入 --config 路徑。這是真實的取捨——一方是部署便利性，另一方是供應鏈控制；無論你偏好哪一方，在這裡選擇用戶端的理由都比任何功能清單更有力。兩項事實都來自 main，讀取日期為 2026 年 9 月 21 日。

權限、自主性，以及各自提供的介面

來源：VT Code 的設定欄位參考、安全模型和 供應商指南；以及 OpenCode 的權限、供應商、伺服器和 ACP 文件。全部於 2026 年 9 月 21 日讀取，且全部描述的是預設值——任一用戶端都可以重新設定為另一種方向。兩者都支援 ACP，也都支援 MCP，因此編輯器支援範圍相近，而非差異化因素。

錢流向的是錢包，而不是用戶端

OpenCode 自有兩項產品。VT Code 不販售任何東西，而這本身就是決策依據：它傳送的每個 token 都由你設定的對象計費，且沒有可回退使用的第一方方案。

價格與配額於 2026 年 9 月 21 日從 OpenCode 自己的文件讀取。在你拿它們比較之前，有兩件事值得知道。Go 公布的各模型資料條款並不一致——大多數列表示資料不會用於模型訓練，且保留期為零天；但少數列出 30 天保留期，另有兩個貢獻者模型標示為資料會用於訓練，且保留期非零——因此請查看你打算長期使用的模型所在列。Zen 會公布有日期的棄用項目，因此以單一模型 ID 為基礎的比較，可能比該頁面更快過時。OpenCode Enterprise 只有聯絡表單，沒有公布價格，本頁也未引用其價格。

在你自己的端點上，一個工作階段需要多少成本

以下數字是示意性的 token 算術，不是實測任務成本，也不是帳單上限。假設一個代理工作階段會傳送 200,000 個未快取輸入 token，並接收 15,000 個輸出 token——這是用於比較的假設，不是對你儲存庫的測量。費率是即時的 Kunavo 目錄每百萬 token 價格；最後一欄只是進行除法，因此承襲前述所有假設。

將最後一欄與 OpenCode Go 每月 $10 的價格相比，然後克制住將其稱為結論的衝動。兩者不是相同單位：Go 的上限是以其模型清單中的美元使用量計算，而不是你實際花費的美元；兩個清單也只有部分重疊——GPT 5.6 Luna 在 Go 公布的清單上，而上表中的 Claude 和 Gemini 列則不在其中。訂閱購買的也是可預測性，而不只是費率。表格真正確定的是問題的形狀——如果你的工作是一週幾次、每次較長的工作階段，且使用便宜模型，按量計費的 token 會先達到目的；如果是整天大量使用 Go 實際提供的模型，固定方案就不再明顯較差。請先測量自己的工作階段再做選擇，因為需要第二次嘗試的模型會立即抹去費率優勢。

Kunavo 的目錄金額是計費下限，而不是上限：上游回報費用時，帳單金額取目錄成本與上游成本乘以適用加成兩者中的較高者。快取費用和外部工具不包含在此範例中。最低加值額為預付點數 $10——這是資金最低額，不是工作費用或訂閱費。請參閱billing details。

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

VT Code 的一側是 [[custom_providers]] 區塊，而上一節的放置規則正是人們最容易弄錯的部分：

# This block is rejected if it arrives from a repository-controlled
# layer. Put it in your user config, in the Unix system layer
# (/etc/vtcode/vtcode.toml), or pass it with --config / VTCODE_CONFIG_PATH.
[[custom_providers]]
name = "kunavo"
display_name = "Kunavo"
base_url = "https://api.kunavo.com/v1"
api_key_env = "KUNAVO_API_KEY"
api_format = "openai-chat"
model = "claude-sonnet-5"
models = ["claude-sonnet-5", "claude-haiku-4-5"]
context_window = 1000000   # omit this and VT Code assumes 128000

關於該區塊有四點說明，全部來自供應商指南和欄位參考。金鑰會從 api_key_env 中指定的環境變數讀取，而設定文件明確警告，絕不要將 API 金鑰放入 vtcode.toml。api_format 接受 auto、openai-chat、openai-responses 或 anthropic-messages——明確指定的值會被採用，不會靜默回退——而 Anthropic 路由值得另外查看，因為兩種基底 URL 慣例不同，基底 URL 參考涵蓋了這點。設定 context_window 很重要：省略它時，供應商會被視為使用 128,000 tokens，這會在較大的內容範圍中悄悄限制壓縮和預檢查。VT Code 也會對自訂端點套用依名稱判定的 OpenAI 取樣限制——例如符合 gpt-6-astra 的模型 ID 絕不會收到 temperature 或 top_p——指南自己的建議是：「如果你需要在這類名稱上固定值，請在閘道上優先使用中性的模型 ID。」

OpenCode 的對應項目是資料檔，而 npm 欄位用來選擇線上格式——為提供 /v1/chat/completions 的端點使用 @ai-sdk/openai-compatible，為 /v1/responses 使用 @ai-sdk/openai：

{
  "$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-5": {
          "name": "Claude Sonnet 5",
          "limit": { "context": 1000000, "output": 128000 }
        }
      }
    }
  }
}

OpenCode 也可以覆寫baseURL的內建供應商，而不是宣告自訂供應商；其文件說明，已知供應商的模型中繼資料來自 Models.dev——因此手動宣告的供應商必須提供自己的 limit——而透過 /connect 命令新增的金鑰會寫入 ~/.local/share/opencode/auth.json。Kunavo 為此用戶端發布了設定頁面：OpenCode 整合指南。這裡沒有 VT Code 整合頁面，上方的 TOML 區塊是根據 VT Code 已記載的欄位定義整理出的設定參考——兩個用戶端都未經 Kunavo 執行環境測試，也未對任一者宣稱相容性。請保留一條可運作的路徑，執行一項有界限的任務，並在切換日常使用的主要工具前，查看你的帳戶記錄的費用。準備好為金鑰加值時，建立 Kunavo 帳戶。

一則會實際耗費時間的安裝警告。名為 vtcode 的公開 npm 套件並不是目前的 VT Code：其 dist-tag latest 為 0.52.8，發布於 2025 年 12 月 24 日；而 crates.io 在 2026 年 9 月 21 日的版本為 0.165.0。VT Code 的安裝文件列出不同的 npm 路徑——npm install -g @vinhnx/vtcode --registry=https://npm.pkg.github.com——以及 cargo install vtcode 和一個需要先執行 brew trust vinhnx/tap 再執行 brew install vinhnx/tap/vtcode 的 Homebrew tap。同一份文件警告，Windows 發布成品僅提供盡力支援，可能不會出現在每個版本中；而 OpenCode 自己的安裝頁面建議在 Windows 上使用 WSL——因此，根據各自文件，兩者都不能算是將 Windows 列為優先支援平台的工具。

正在比較其他工具？Crush 與 OpenCode 以同一個 OpenCode 對比 Charm 的代理程式，OpenCode 定價深入介紹 Zen 與 Go，而OpenAI 相容 API 參考則涵蓋兩個用戶端所依賴的端點慣例。

常見問題

檢查日期為 2026 年 9 月 21 日：三個儲存庫的 GitHub API，以及 VT Code 的版本清單；opencode-ai、@opencode/cli 和 vtcode 的 npm dist-tags；vtcode 的 crates.io 記錄；VT Code 在 main 上的 README、安全性模型、供應商指南、設定欄位參考、安裝文件與 VS Code 擴充功能 manifest；以及 OpenCode 的權限、供應商、伺服器、Zen、Go 和下載頁面。Kunavo 權杖費率來自即時目錄。本頁未安裝、執行任何一個用戶端，也未將其指向 Kunavo 端點；未進行任何基準測試或效能比較，也未宣稱有這些結果；本文所有美元數字都是示意性的權杖算術，而非實測任務成本。