編按：本文綜合整理自 Systima AI 實測報告、Hacker News 討論串（438 分、244 則留言）、MorphLLM 七月比較 與 EU AI Act Article 12 規範說明，並加入 Siami 編輯部觀點與數據解讀。
Anthropic 自家的 Claude Code 在使用者「還沒打字」之前，就已送出約 33,000 個 token 的系統提示、工具 schema、與注入式腳手架。同樣任務交給開源替代品 OpenCode，只需約 7,000 個 token——差距最高達 4.7 倍。這是 Systima AI 工程團隊在同機器、同模型（claude-sonnet-4-5）、同任務下量測 API 邊界後得出的結論，原始數據與 185 筆請求/回應紀錄全數以 SHA-256 雜湊鏈驗證過。
為什麼這件事重要
對一般開發者來說，33k token 的「門檻成本」聽起來抽象，但乘上工作階段的長度與請求次數，差距會被放大到不可忽視：
- 單次開機就吃掉 16.5% 的 200k context window——還沒寫任何程式碼。
- 真實配置下（72KB instruction 檔 + 5 個 MCP server）首發請求可達 75,000 至 85,000 token，逼近 200k context 的 40%。
- 若用 sub-agent 平行處理同一個原本只要 121k token 的任務，總用量直接跳到 513k token（4.2 倍）——因為每個子代理人要自己重新 bootstrap 一次。
企業用 Uber 2026 年 AI 預算四個月被 Claude Code 燒光、GitHub Issue #52646 上多名用戶回報「token 計數比實際內容多 15-16 倍」、HN 上「Is Claude Code getting worse」討論破 400 推——這些不是個案，而是同一個底層問題的不同切片。
「每多一個 token 的 harness 負載，就是你不能拿來寫程式碼的 token。」 —— Systima AI 報告原文
數據解讀：三層成本的拆解
Systima 把成本拆成三層，可分頭對症下藥：
第一層：地板（Floor）—— 兩個 harness 在零設定下的差距
| 元件 | Claude Code | OpenCode |
|---|---|---|
| 系統提示 | 27,344 字元（3 個區塊） | 9,324 字元（1 個區塊） |
| 工具 schema | 27 個工具、99,778 字元 | 10 個工具、20,856 字元 |
| 首次訊息腳手架 | 7,997 字元 <system-reminder> | 無 |
| 首輪 payload（校正後） | ~32,800 token | ~6,900 token |
OpenCode 的請求已經接近「最小必要」——一段系統提示、10 個編碼工具、然後就是使用者訊息。Claude Code 則像在啟動整個平台：除了 27 個編碼核心工具，還包含 CronCreate、Monitor、Task 系列、worktree 管理、推播通知等後台代理人編排套件。
有趣的反轉：把模型換成 Claude Fable 5，差距從 4.7x 縮到 3.3x。原因是 Claude Code 對不同模型送不同大小的系統提示（Sonnet 27,787 字 vs Fable 10,526 字），OpenCode 則維持位元級一致。代表「差距來自設計選擇，不是模型限制」。
第二層：乘數（Multipliers）—— 真實世界加上去的五個變數
每加一層配置，開銷就線性疊加：
- 指令檔：72KB 的
AGENTS.md雙邊各加 ~20k token。Claude Code 2.1.207 還有個 bug——它只讀CLAUDE.md，對AGENTS.md完全無動於衷。 - MCP server：每個 1,000-1,400 token，五個就再加 5,000-7,000 token。
- 框架模板（如 BMAD）：8,405 字元的 prompt 範本會進入對話紀錄，每次後續請求都重送——9 次請求的工作階段就重送 9 次。
- Sub-agents：每個子代理人自己 bootstrap 一次，母代理人再把它整段對話收進自己的 context——這是測得最大宗的乘數。
- 延伸思考（Extended thinking）：輸出按 5 倍輸入費率計費，且 reasoning 區塊會留在對話歷史裡被重送。
在 OpenCode 上跑同一個「全開」配置（11 個 MCP + 72KB 指令檔），冷啟動首發請求實測是 90,817 token、179 個工具、277KB schema——還沒打字。
第三層：快取經濟學—— 折扣救不了 33k 的地板
兩個 harness 都正確設定快取斷點（5 分鐘 TTL 寫入 1.25x 費率、讀取 0.1x 費率），但有三項成本是快取完全救不了的：
- 寫入本身——每次暫停超過 TTL（5 分鐘思考、開會、午餐），整套就要重新打 1.25x 費率。
- 讀取 × 請求次數——sub-agent 與序列式工具迴圈會把讀取次數膨脹。
- Context window 佔用——85k 的 bootstrap 直接佔掉 200k window 的 40%，然後觸發 compaction，compaction 又要花更多 token 來摘要。
Claude Code 的快取不穩定性是核心問題：它把工作階段分成三種請求類別（warmup probe、主對話、sub-agent 呼叫），各有自己的前綴與快取項目；而且 system bytes 在同一 workspace 不同 session 間還會變動。Systima 在檔案摘要任務上量到 Claude Code 一個 mid-session 完全重寫 43k token 的 prefix——OpenCode 在所有量測中則是 0 次重寫。
「根據快取溫度，Claude Code 同任務的快取寫入量是 OpenCode 的 5.9x 到 54x。」
為什麼要相信這份數字
Systima 的方法論有三個值得注意的設計選擇：
- 量測在 API 邊界——他們寫了個 200 行的 Node.js HTTP 代理掛在
ANTHROPIC_BASE_URL前，原始請求 payload 與 API 回傳的 usage 區塊都寫進磁碟。這層無法被應用程式或閘道污染。 - 同機器、同模型、同任務——Claude Code 2.1.207 與 OpenCode 1.17.18 都固定在
claude-sonnet-4-5（2026 年 7 月版本），三個 T1 run、三個 T2 run、每個乘數層級一個 run。 - 185 筆紀錄用 SHA-256 雜湊鏈簽章——所有請求/回應都寫入該公司開源的
@systima/aiact-audit-log函式庫，端對端驗證通過Chain verified: 185 entries / Hash chain integrity: VALID。
他們也明確標示一個盲點：閘道會自動換成比 pin 住的版本更新的模型快照——「如果你沒在 API 邊界 log，你根本不知道實際跑了哪個 model」。這其實呼應了 EU AI Act Article 12 的精神：對高風險 AI 系統，「自動記錄事件的能力」不是選配、而是法律要求。
「在生產環境跑 agentic AI 卻答不出『上週二我的 agent 到底送了什麼給模型』——這才是最大的成本漏洞。」
質疑與限制
Systima 自己點出三個值得打折扣的地方，整理如下：
- 單一機器、單一版本配對——harness prompt 改版很快，數字應視為 2026 年 7 月快照，方法是耐用的部分。
- 閘道干擾——Fable 路徑有一次閘道重啟了過期的 server-side session、另一次在 host 端執行工具，所以 Claude Code Fable 多步驟層級被排除沒報。
- 真實配置數字只是某個工程師的環境——size 與 count 可參考，但你的 MCP 數量與指令檔大小會決定你看到的是幾倍。
- 未涵蓋：品質——所有任務都通過驗證腳本（Claude Code 用平行批次、OpenCode 用序列呼叫），但「更貴買到更好的工程品質」這條假設沒有量測；他們也承認 Claude Code 的後台代理人、技能、編排介面在更難任務上可能值那個價。
換句話說：這份報告證明的是「同樣結果、不同帳單」，不是「Claude Code 比較爛」。
工程師該怎麼辦
整理幾個從原始數據延伸出來的具體建議：
- 檢查你的 harness 到底讀哪個檔名——
AGENTS.mdvsCLAUDE.md對 Claude Code 2.1.207 是兩回事。被忽略的指令檔是沉默的浪費。 - MCP server 真的需要那麼多嗎？——每個 1k+ token，五個就 7k。砍掉用不到的，等於無痛省錢。
- 慎用 sub-agent 平行化——513k vs 121k 的 4.2 倍差距不是邊際效益，是主軸成本。
- 設定 proxy 量測自己的——200 行程式碼換來的是「知道自己的 agent 送了什麼」。對企業客戶來說，這同時也是 EU AI Act Article 12 的最低合規配備。
網友熱門留言 (6)