5秒結論： 即使用同一個模型，只要每輪塞入的context、模型呼叫次數、工具輸出保留量、壓縮時機與retry策略不同，總消耗就可能差很多。模型像引擎，而harness像變速箱、噴油系統、導航與維修團隊的總和。
1. 「同一個5小時窗口卻做了兩倍工作」先視為實測經驗，不是官方benchmark
有開發者在社群平台分享：從Codex切到OpenCode後，仍以ChatGPT驗證使用同一個GPT-5.6 Sol，但感覺相同5小時與每週額度可以完成超過兩倍的工作。
回覆中有人推薦pi、有人懷疑context上限設定，也有人建議用routing與telemetry觀察實際消耗。
關鍵界線是：沒有官方資料證明OpenCode一定讓額度翻倍。
OpenAI官方說明的是，Codex使用量不是固定訊息數，而會受模型、任務執行位置、複雜度、context、推理、速度與工具等因素影響。部分方案同時有5小時與每週限制。
因此，「換harness之後油耗變了」在機制上很合理；但「一定兩倍」尚未被控制實驗證明。
2. Harness是什麼？就是大腦以外的整套機械
只看模型很簡單：
Sol = 大腦。
但coding agent還必須決定：
- system instruction怎麼組
- 讀哪些檔案
- 保留多少對話歷史
- 暴露多少tool schema
- shell/GitHub輸出保留多久
- 失敗後retry幾次
- plan、implement、review跑幾輪
- 何時compaction
- 是否交給subagent
- 如何判斷完成
這整層外圍機制，就是廣義harness。
OpenAI自己也使用「Codex harness」這個詞，並描述連接模型對話、client與tool的App Server。
所以：
同一個model，不等於同一個system。
同一顆引擎裝在不同重量與傳動系統的車上，油耗當然可以不同。
3. 真正燒油的常常是每輪都重新搬的行李
長任務很容易讓每次模型呼叫都帶著：
- 長對話歷史
- 巨大system prompt
- 專案規則
- MCP tool schema
- repository檔案
- terminal log
- test結果
- 舊失敗資訊
- retry state
大log讀一次未必最可怕。
更重的是讓龐大的active context連續進入10、20、30次模型呼叫。
而且不同harness會有不同迴圈。A可能15次call完成，B可能因為plan、重複探索、review、再review跑到30次。
概念上可以記成：
消耗 ≈ 行李 × 往返次數 × retry
這不是官方計費公式，但很適合作為工程直覺。
4. OpenCode有趣在哪裡：ChatGPT驗證、MCP與compaction放在一起
OpenCode官方文件指出，連接OpenAI時可以選擇ChatGPT Plus/Pro，並透過瀏覽器驗證；這與手動輸入API Key是不同入口。
OpenCode也能作為MCP client使用本地與遠端MCP server。
因此可以形成：
OpenCode → GitHub MCP → DB MCP → 自建API → 其他工具
OpenCode還提供自動compaction。現行文件範例中，自動compaction預設開啟，保留checkpoint與約最近15,000 token的內容。
也就是：
歷史留在倉庫，但每次出門不把整個倉庫背走。
不過OpenCode同時警告，MCP server本身會增加context，GitHub MCP等大型tool集合尤其可能吃掉很多token。
MCP接得越多，不一定越強。
有時只是把倉庫穿在身上。
5. 用ChatGPT加MCP控制所有服務，本質上也是同一種架構
若ChatGPT是中央控制器，透過MCP或connector操作GitHub、server、cloud與storage，本質仍然是：
model + harness + tools
ChatGPT → MCP / connector → GitHub、server、cloud、storage
ChatGPT負責判斷，MCP負責手腳，外部系統保存真實state。
OpenCode則是：
OpenCode → MCP / shell / API → repository、server、cloud
主要差別在於conversation state放哪裡、tool loop在哪裡跑、何時壓縮context以及如何驗證完成。
所以「這不就是我從ChatGPT透過MCP把全部東西動起來嗎？」——架構上非常接近。
只是控制室換了品牌。
6. ChatGPT能不能把工作丟給OpenCode？
OpenCode官方明確支援作為MCP client。另一方面，opencode serve可以開啟headless HTTP/OpenAPI server，也有SDK與ACP。
因此若要讓ChatGPT把長任務委託給OpenCode，一個乾淨的結構是：
ChatGPT → 薄MCP bridge → OpenCode Server → Sol → MCP / shell / API → GitHub與cloud
bridge不需要暴露幾十種底層工具，只要少數高層動作：
- 啟動OpenCode task
- 查詢狀態
- 取得最終結果
如此ChatGPT端就不必每輪攜帶龐大的GitHub tool schema與log。長時間tool loop留在OpenCode，最後只把結果送回來。
這不是單純多用一個app，而是把agent loop的邊界搬家。
7. 真正想省用量，先減少「回到AI」的次數
實務上最有效的分工往往是：
- 決定性的步驟交給script
- state與receipt放在外部
- 只開必要tool
- 長log先抽取再給model
- 不重讀沒變的檔案
- 保存failure reason與next action
- 只有模糊判斷才叫高性能model
- 最後只回傳production readback
分工可以濃縮成：
AI = 處理模糊
script/workflow = 執行確定流程
GitHub/DB/state = 記憶
如果每輪都要AI重新想「下一步是什麼」，那等於每次都花錢請它盤點整間倉庫。
8. 還沒有被證明的部分
OpenAI官方可確認：Work與Codex共享使用額度，消耗會隨context、tool等因素變化；適用方案有5小時與每週窗口。
OpenCode官方可確認：支援ChatGPT Plus/Pro驗證。
但引用的官方資料沒有說OpenCode透過ChatGPT OAuth時一定與Codex採完全相同的內部計量係數，也沒有保證OpenCode永遠高效幾倍。
因此：
「我測到兩倍」是有價值的觀察。
「所有人必定兩倍」不是已證事實。
真正benchmark應固定repo、model、task與completion criteria，再量model call、token、compaction、tool call、retry、wall-clock與最終test。
最好看的單位是：
每成功完成一個task的消耗。
9. 結論：Agent時代，配線幾乎與引擎一樣重要
模型仍然重要。
但長任務加入工具後，context管理、state、tool數量、retry、compaction與完成判定都會改變產能。
model是引擎。
harness是整台車。
而當你用MCP開始連接多個系統時，你做的已不只是「使用AI」。
你是在替AI設計工作現場。
最強的最佳化，有時不是再加一個tool，而是讓某個流程從此不必再問AI。
參考資料
[1] https://openai.com/index/unlocking-the-codex-harness/ [2] https://help.openai.com/ja-jp/articles/11369540 [3] https://help.openai.com/ja-jp/articles/20001516-managing-usage-with-gpt-6-astra-in-work-and-codex [4] https://opencode.ai/docs/providers [5] https://opencode.ai/v2/docs/mcp-servers [6] https://opencode.ai/v2/docs/compaction [7] https://dev.opencode.ai/docs/server/ https://dev.opencode.ai/docs/ja/sdk/ [8] https://opencode.ai/v2/docs/cli/acp/
資料來源
- OpenAI, Unlocking the Codex harness: how we built the App Server openai.com
- OpenAI Help Center, ChatGPTプランでCodexを使う help.openai.com
- OpenAI Help Center, WorkとCodexでのGPT-6 Astraの利用量管理 help.openai.com
- OpenCode Docs, Providers opencode.ai
- OpenCode Docs, MCP servers opencode.ai
- OpenCode Docs, Compaction opencode.ai
- https://dev.opencode.ai/docs/ja/sdk/ dev.opencode.ai
- OpenCode Docs, ACP opencode.ai
