Claude Code 的隱形 Token 成本
Systima 把 logging proxy 放在 AI coding agent 與模型 API 之間，直接記錄 Claude Code、OpenCode 送出的完整 payload 與計費資料。兩邊使用同一模型、機器和任務時，Claude Code 在讀到 22 字元的使用者提示前，就先送出約 3.3 萬 tokens；OpenCode 約 6,900，差距約 4.7 倍。主要成本不是回答，而是 system prompt、tool schemas 與自動注入的 scaffolding。這些內容會吃掉 context window，也影響延遲與 prompt cache 費用。
現實應用
這份測試最適合正在大量導入 coding agent 的開發團隊、AI SaaS 與平台維運者參考。若每天只有幾次互動，差異未必有感；但長時間 session、大型 CLAUDE.md／AGENTS.md、多個 MCP servers 或 subagents 並行時，固定負擔會被反覆放大。文中測得 72KB 指令檔會讓兩邊每次請求多約 2 萬 tokens，五個小型 MCP servers 再增加約 5,000～7,000；Claude Code 使用兩個 subagents 的小任務，更從 12.1 萬升到 51.3 萬 tokens。
期望評估
我認為低標期望不是「換 OpenCode 就省 80%」，而是先把 agent 實際送出的 payload、cache write/read 與 request 次數量化，至少能找出過長指令檔、閒置 MCP 工具和不必要的 delegation。
高標來看，我猜團隊若能依任務切換 harness、縮減 tool schemas，並把短任務留給低起始成本的配置，確實可能明顯降低費用與 context 壓力。不過多步驟任務中，Claude Code 因能平行批次呼叫工具，只用了 3 次模型請求，總輸入反而低於 OpenCode 的 9 次；所以真正該比的是整個任務成本，不是第一輪數字。
商業策略分析
這會直接影響按 token 付費的企業、代管 agent 平台，以及靠高頻自動化維持毛利的產品。我認為值得跟進的不是單押某個工具，而是建立 API boundary 的成本稽核與任務級指標。供應商若能提供更穩定的 cache prefix、精簡工具載入及可觀測的 subagent 成本，會更容易拿到企業採用。這份結果仍是 Systima 在特定版本、模型與自家 gateway 下的測試，且 gateway 固定負擔經校正扣除，不宜直接當成所有環境的通則。
實作細節
研究使用 Claude Code 2.1.207、OpenCode 1.17.18，先在空白設定、無 MCP、無記憶與無專案指令檔的環境測基線，再逐項加入指令檔、MCP、workflow template 與 subagents。想自行驗證，可在模型 endpoint 前加 logging proxy，保存 request JSON 與 API usage block；Systima 也公開了相關 audit log 專案。另要注意該版本 Claude Code 未讀取 AGENTS.md，需改名 CLAUDE.md；print mode 的 .mcp.json 也可能要明確傳入 --mcp-config。