數了 Codex 和 Claude 壓縮幾次
我最近做了個小實驗：把同一個 side project 整個複製成兩份，一份交給 Claude Code、一份交給 Codex，餵幾乎一樣的 prompt，讓它們各做各的。用久了本來有個模糊印象：Codex 好像比較容易「講到一半自己清場」，Claude 撐得比較久。這次我沒有再憑印象猜，直接把兩邊的 session 紀錄檔翻出來，一行一行數。
先講清楚「清場」是什麼：對話一長，工具會自動把前面的內容摘要掉、騰出空間繼續講，官方叫 compaction（壓縮）。壓縮一次，前面那段原始對話就換成一份濃縮版。（context：模型一次能塞進去的對話量，有上限，滿了就得壓縮取捨。）這篇分享：同一天、同一個專案，兩邊各壓縮了幾次、為什麼差這麼多，還有壓縮這件事本身到底有沒有代價。
先看結論：同一個專案，Codex 壓縮四次、Claude 一次
同一個 side project、同一天（2026-07-21）、工作內容差不多。我把兩邊的紀錄檔攤開，數裡面的壓縮事件：
| Claude Code | Codex | |
|---|---|---|
| 模型 | claude-sonnet-4-6 | gpt-5.6-luna |
| context 上限（工作視窗） | 200,000（沒開 1M） | 258,400（紀錄檔） |
| 壓縮次數 | 1 | 4 |
| 第一次壓縮：前 → 後 | 144,095 → 10,722 | 206,155 → 25,264 |
| 那次少掉的 token | 133,373 | 約 180,891 |
先把視窗講清楚，免得誤會：Claude 這場沒開 1M，跑的是預設的 200,000；Codex 是 258,400，其實還大一點。而且兩邊都是「快滿了才壓」——Claude 壓在 200,000 的 72%，Codex 第一次壓在 258,400 的 80%。所以四比一不是「誰視窗比較小」的故事。（Codex 少掉的 180,891 不是它自己記的，是我拿壓縮前後相減算的；Claude 的 133,373 是紀錄檔現成的欄位。）
答案在別的地方——這才是翻 log 有意思的地方。
為什麼 Codex 長得快：想過的東西會揹著走
先講一件我原本猜錯的事：不是「Codex 想得比較多」。兩邊的 reasoning（模型回答前自己先想的那一段）都開到 max，都在拼命想。
差別在——想完之後，那段思考有沒有留下來。Codex 把每一步「想」出來的 token 留著、變成下一步的輸入，一路往上疊。我看到一個很直接的例子：某一步生了 7,447 個 reasoning token，五秒後 context 就跳了 8,458；數到第 30 次 API 呼叫，光累積的 reasoning 就 18,112 token。
Claude 這邊，紀錄裡連一個獨立的 reasoning 欄位都沒有，它的 context 從 5 萬多爬到壓縮前的 14 萬、慢得多——而且它也開 max，一樣很多輪輸出好幾千 token。同樣用力想、差這麼多，最合理的解釋是：Codex 把每一步的思考一路揹在 context 上帶著走，Claude 想完、答完就把那段思考放掉、不揹著。（log 只讓我看到結果——Codex 的思考在累積、Claude 的沒有；確切為什麼，是兩家怎麼處理「想過的東西」的差異，我只能推到這。）
再加一個因素：這場 Codex 多跑了一個多小時，context 一路填滿、就一直反覆壓；Claude 快結束前才填滿，壓一次就收工。揹著思考長得快、又跑得久，四比一大致就是這樣來的。
會不會只是 Codex 做比較多事？
我也懷疑過，是不是 Codex 這場單純做了比較多事。數了一下：Codex 記到 98 次檔案寫入，Claude 記到 88 次工具呼叫（讀、寫、搜尋全加起來）。兩個數字算的東西不完全一樣，但量級差不多——不是一邊做了四倍的事。所以四比一，不是工作量撐出來的。
壓一次 vs 壓四次：壓縮本身就有代價
那壓比較多次，到底有沒有差？先看「壓完剩多少」，把壓縮前後相除、算個壓縮率：
- Claude：144,095 → 10,722，只留 7%、砍掉 93%。
- Codex（第一次）：206,155 → 25,264，留 12%、砍掉 88%。
反直覺的是：每壓一次，其實是 Claude 砍得更狠、留得更少。所以你不能說「Claude 壓得比較斯文才不會忘」——單看一次，它砍得更凶。
真正的差別是「壓幾次」。壓縮是拿原文換摘要、本來就有損；而每壓一次，最早那一段——你一開始交代的目標、定好的規則——就又被摘一次。Codex 壓了四次，等於把最初的目標摘成「摘要的摘要的摘要」；Claude 只壓一次，一開始交代的東西大致原封不動撐到最後。
這裡才是重點：就算每次壓縮都很優秀、每次都留 80%，壓四次也剩不到一半（0.8 的四次方大約 41%）；而且被反覆摘的，剛好是最該記住的開頭。所以「壓縮次數多」本身就是缺點——不用等記憶測驗來證，把同一段目標摘來摘去、越摘越糊，這是壓縮的本質，不是哪個模型比較笨。
（老實說，我沒有在這場做正式的「壓縮前後考記憶」，也沒比誰寫的 code 好，所以不會斷言 Codex「就是比較笨」。但壓縮會複利式掉資訊，是機制本身決定的，也跟我平常的體感一致：越常壓，越容易忘記原本要幹嘛。）
那我會怎麼用
既然「一直壓縮」本身就是代價，我實戰上的重點就是繞開它。不是靠挑牌子，是兩個做法：
- 要撐很久的任務，直接開 Claude 的 1M context。 這是暴力解：視窗大到根本壓不太到，最初的目標就不會被反覆摘掉。（這次測試我沒開 1M、跑的是預設 200K；1M 是我平常會給的建議。）
- 把工作拆給 subagent 去跑。 每個 subagent 有自己獨立的 context，中間那一堆探索、試錯、reasoning 都留在它身上，回主線的只有結論——主線乾淨、壓縮次數少，原本的目標就守得住。
尤其 Codex 開 max reasoning 的時候，思考發散、又全揹在 context 上，特別容易一直壓；這時候把 context 拆出去，比硬挑哪個模型有用得多。
一句話：與其問「Codex 還是 Claude 比較聰明」，不如問「怎麼讓它少壓縮」。壓縮次數壓下來，忘東西的機會就跟著少。
補一個前提：這場我是故意讓 Claude 用弱的打
最後老實交代：這場我是故意挑「差不多大」的視窗來比——Claude 用 200K 的 Sonnet、沒開 1M。這樣比才乾淨，看得出四比一是「揹不揹思考」的差別，不是視窗大小。
但實際上沒人這樣用，大家都各拿最強的來打。這裡補一個很多人不知道的點：GPT-5.6 其實也吃得下 1M context，只是得走 API 才有，而且超過標準視窗那段是額外加價、不是線性收費——不像 Codex CLI 預設就是二十幾萬。Claude 這邊 Opus 開 1M 相對直接。所以「值不值得花這筆錢換大視窗」，就看個人需求了。
但方向很清楚：只要你做的是會跑很久、context 很快就滿的活——大型重構、長時間的 agent 任務那種——連最強的模型都會被視窗卡住、一層一層把最初的目標摘掉。這種活我自己會偏向 Claude，不是因為它 code 寫得比較好（這我沒測），是因為它比較不會一路把你交代的目標壓縮掉。至於我這場，還是刻意讓它用小視窗上場的。
最近開始做免費的一對一諮詢，幫你把 AI 接進自己的工作流——有需要的話可以約：https://www.dawsonwang.com/
資料來源：本機的 session 紀錄檔——Claude Code 的 .jsonl 跟 Codex 的 rollout log，是同一個 side project 複製成兩份、餵幾乎一樣的 prompt 後跑出來的兩場 session（2026-07-21）。258,400、144,095、133,373、206,155、10,722、25,264 都是從紀錄檔直接讀出來的；Codex 那次壓縮少掉的約 180,891 是拿壓縮前後相減算的。Claude 這場的視窗 200,000 是我這邊的設定（沒開 1M，跑預設值），不在紀錄檔裡。