Codex vs Claude Code：我每天使用兩者後學到的事

資源佔用——你的機器實際感受到的負擔

在動到任何一行程式碼之前，這兩個工具光是放在那裡就已經讓人感覺不一樣。Claude Code 的程序在 Activity Monitor 中明顯更重，通常會佔用數百 MB，而 Codex 則閒置在幾十 MB。於終端機輸入 claude 後，得等幾秒鐘提示字元才會準備好；輸入 codex 幾乎是即時反應。

為了用數字來呈現這一點，而不只是描述它，我在同一台機器上（MacBook Air、M3、24GB RAM、macOS 26.5.1）與相同的網路環境下測試了這兩個 CLI。首先是一個平凡的非互動式任務（單行回覆提示、沒有檔案編輯），使用 /usr/bin/time -l 依序在兩者上執行：

然後我逐一以互動方式啟動它們，並且只讓它停在提示字元那裡不動幾秒鐘，接著再用 ps 檢查它的常駐記憶體：

那個閒置數字更接近你實際感受到的情況：當這兩個工具只是開在終端機分頁的背景中時——而且它幾乎完全符合直覺上的「數百 MB vs 數十 MB」區分。

這不是一個嚴謹的基準測試，只是一台機器和一次執行階段——但無論是在任務還是在閒置數據上，記憶體差距都足夠一致，並不是雜訊。

價格：我實際上在為什麼付費

除非我直接透過 API，否則這兩個工具都不會按 token 向我收費——它們都依附於母公司的固定訂閱方案，而這才是決定我在被限流前可使用多少額度的因素。

（截至 Anthropic 的 定價頁面 以及 OpenAI 的 Codex 定價頁面 — 我會在訂閱前先查看兩者，因為方案會變動。）我實際感受到的差距是：OpenAI 沒有 $100 的中間方案，所以一旦我把 ChatGPT Plus 用到上限，下一步就直接跳到 $200；Anthropic 則在中間給我一個 $100 的階梯。當我不是使用 CLI 內附的訂閱方案，而是直接透過 API 呼叫任一模型——也就是我在自己打造 agent，而不是使用封裝好的工具——這部分會另外計價。對於這種使用情境，我會透過 AIReiter，而不是直接向 Anthropic 或 OpenAI 按標價付款；它會以折扣價轉售相同的模型。

為什麼我一直來回切換

我會選用的工具，與其說取決於工具本身，不如說更取決於底層模型。當 OpenAI 的 GPT-5.5 上線時，在一段時間內它明顯比 Claude 更強，而我也在那段期間把大部分日常工作轉到 Codex。那種優勢並沒有持續太久——幾週後 GPT 的品質又下滑了，我便把預設工具改回 Claude Code。Claude 也有自己的品質波動，但和我在同一時期從 GPT 觀察到的相比，幅度更小，也沒那麼具破壞性。

選擇「Codex vs Claude Code」在某種程度上，是在替目前那一週哪個前沿模型更犀利做出選擇。只評估 CLI shell —— UI、沙箱、生態系 —— 會忽略真正讓人們在兩者之間切換的變數。這也對應到兩個工具之間更常被提到的分歧：Codex 偏向放手式（把任務交給它，先去忙別的，之後再看 diff），而 Claude Code 偏向動手式（更快的來回互動，更多需要你介入時它會等待你的檢查點）。

功能成熟度落差 — 缺少的倒帶

工具成熟度是 Claude Code 仍然明顯領先於我從 Codex 得到的地方，而對我來說最明顯的例子，就是一個具體、並不花俏的功能：在 session 進行中回退到較早版本的程式碼。Claude Code 原生支援這點——當某次編輯出錯時，我可以倒回到先前的 checkpoint。Codex 仍然不支援，而且它已經推出夠久了，我再也不接受「剛上線，再等等看」這種藉口。快速迭代，並偶爾讓 agent 走得太遠，正是我的工作流程，所以這是我大多數週都會注意到缺席的功能，而不是什麼邊緣案例。

Claude Code 更廣泛的生態系對我來說也有同樣的模式：subagents、hooks，以及 Agent Skills 系統（Anthropic 先推出的標準，之後 Codex 才採用）讓它有更多可供在其上構建工作流程的延伸面。Codex 的對應工具雖然存在，但在我日常使用中感覺更薄弱，而且它的 CLI/IDE/cloud/app 介面命名也更零散，儘管 OpenAI 已經把它推廣到更多地方。

沙盒與信任問題

這兩個工具以不同方式防止我犯下自己的錯誤。Codex 在 OS 層級強制隔離——macOS 上的 Seatbelt、Linux 上的 Landlock、Windows 的 sandbox——因此失控的 shell command 會被 kernel 限制住，而不是依賴 agent 自己的判斷。Claude Code 的安全模型則存在於 application layer，透過我可以設定的一套 hooks，在動作執行前進行 gate 或 block。從紙面上看，這兩種方法都沒有絕對更安全；它們只是不同的 failure modes，而且 Codex 是 open source，這代表我真的可以讀到它的 sandbox 是如何實作的，而不是只能憑信任接受。

不過，這種 kernel-level 隔離在實務上是有實際代價的：Codex 的 sandbox 會暫停並等待我明確授權才能進行操作，而 Claude Code 的基於 hook 的模型在我完成設定後就會直接放行。執行多步驟的 scripted workflow——那種工具會在過程中寫入檔案，或呼叫 shell 來執行腳本的流程——使用 Codex 時，比起 Claude Code 需要更多次中斷來請求核准。

信任也是今年 Claude Code 真的受到重創的地方，而這也是讓我對是否要繼續忠於封閉原始碼有些猶豫的唯一原因。2026 年 7 月，中國的國家漏洞資料庫公開警告開發者停用近期的 Claude Code 版本，原因是 2.1.91 到 2.1.196 版本中存在一個隱藏機制，會檢查裝置的時區以及流量是否經由非官方 API 端點路由，然後相應地標記該請求。Anthropic 證實了這個機制確實存在，並將其描述為反蒸餾實驗而非後門，並在 2.1.198 版本中將其移除。我不會在這裡重新爭論整個事件，但對我來說，這確實讓這類封閉原始碼工具多了一個明顯的污點：我無法驗證我無法讀到的內容，而 Codex 是開放原始碼，這意味著這種特定的失效模式並不會以相同方式影響它。

那麼你實際上應該使用哪一個呢

如果你的日常使用情境和我一樣——在中小型任務上快速迭代，想要一套完整的工具鏈圍繞在你身邊（subagents、hooks、skills、可即時檢視並在過程中回滾的快速編輯）——那麼 Claude Code 會是更安全的日常預設選擇。如果你要交付的是一個大型、定義清楚且可以放心交出去的任務，或者你想要一個可審計、可在受限制沙箱中執行的開源 agent，那麼 Codex 也是合理的首選，而且我注意到它在執行時對我的電腦負擔比較輕。

我不會完全只投入一個，而且我認識的大多數重度使用者也不會。我會預設使用目前底層模型表現較好的那個工具，並保留另一個已安裝，以便在那些它的特定優勢——Codex 的沙箱隔離與資源占用，Claude Code 的生態系與回溯支援——對該任務 वास्तव有意義時使用。

常見問題

Codex 比 Claude Code 更好嗎？

兩者都沒有絕對勝出。Codex 更省資源，也更適合長時間、無需人為介入的任務；Claude Code 擁有更成熟的生態系、可在中途回溯，且有較低成本的中階訂閱方案。某一週哪個表現更好，往往更取決於底層模型當前的狀態，而不是工具本身。

Claude Code 或 Codex 是免費的嗎？

不——若要進行嚴肅的日常使用，兩者都需要付費方案。Claude Code 需要 Claude Pro（$20/月）或更高方案；Codex 需要 ChatGPT Plus（$20/月）或更高方案。輕度、偶爾使用可能符合免費方案試用限制，但兩者都無法在免費情況下持續支援每日的 agentic coding。

我可以在同一個專案中同時使用兩者嗎？

是的，而且這在重度使用者之間是一種常見模式：先用一個工具處理大部分工作，再讓另一個工具進行第二輪檢查——全新的視角能捕捉到第一個工具自身模型在其輸出中不會標記出的盲點。請保留一份簡短的共享記錄，記下變更內容及原因，這樣第二個工具就不必猜測上下文。

結論

兩者都是可用於日常工作的工具，但各有弱點：Codex 更輕量、啟動更快，但仍無法在同一個工作階段中途回溯歷史；Claude Code 在你的機器上較為吃資源，但工具鏈更完整，而且它的 $100 中階方案為重度使用者提供了 OpenAI 沒有的選項。自從兩者推出以來，我自己的使用時間分配仍有超過 75% 給了 Claude Code，而這與其說是對 Codex 的評價，不如說是反映了生態系差距對我實際工作流程有多重要。今天你應該打開哪一個，與其說取決於任一工具的路線圖，不如說取決於其背後的模型目前是否正在發揮最佳表現。