OpenAI 帶著全新的 Codex 模型回歸了,發佈日期與 Claude Opus 4.6 同一天。
主打的賣點是它結合了 GPT-5.2-Codex 的程式編寫能力與其他模型的通用知識與技能,並提升了速度及 Codex 運作架構(harness)的改進,使其現在能處理全棧(full stack)代理式需求。
我們也迎來了 Mac 版的 Codex 應用程式,目前反應相當正面,並迅速突破了百萬次下載。
GPT-5.3-Codex 僅在 Codex 內部提供,並未開放 API。
一如往常,Anthropic 的發佈顯得低調含蓄,基本上就是「這是 Opus 4.6,一份 212 頁的系統卡(system card)和大量的基準測試,先生,這是一個好模型,請慢用。」而 OpenAI 給出的文字和基準測試少得多,卻聲稱他們的模型絕對是最好的。
OpenAI:GPT-5.3-Codex 是迄今為止最強大的代理式編碼模型,結合了 GPT-5.2-Codex 的頂尖編碼性能與 GPT-5.2 的推理和專業知識能力。這使其能夠承擔涉及研究、工具使用和複雜執行的長期任務。
就像同事一樣,您可以在 GPT-5.3-Codex 工作時對其進行引導和互動,且不會丟失上下文。
Sam Altman (OpenAI CEO, 2月9日):GPT-5.3-Codex 今天已在 Cursor、Github 和 VS Code 中推出!
目錄
整體概況。
快,沒時間了。
系統卡。
AI 盒子實驗。
對 rm 命令冷靜點。
準備程度框架。
玻璃屋。
OpenAI 似乎嚴重違反了 SB 53 法案。
他們確實實施的防護措施。
對齊失誤風險與內部部署。
官方推銷。
全面啟動(Inception)。
扭轉局勢。
Codex 能做酷炫的事。
正面評價。
負面評價。
終極氛圍 Codex。
整體概況
GPT-5.3-Codex(包括 Codex-Spark)是專為 Codex 中的代理式編碼及相關用途設計的專門模型。它並非定位為通用的前沿模型,因此缺乏大多數通用基準測試,且無法在 API 或 ChatGPT 中使用。
對於除了 Codex 和代理式編碼以外的大多數用途,且任務強度尚不需要動用 Gemini 3 Pro Deep Think V2 的情況下,Claude Opus 4.6 顯然是最佳模型,也是日常使用的首選。
至於代理式編碼及 Codex 的其他預期用途,整體感覺是 Codex 加上 GPT-5.3-Codex,與 Claude Code 搭配 Claude Opus 4.6 具有競爭力。
如果您認真對待代理式編碼和其他代理任務,您應該嘗試這兩種方案,看看哪一個或哪種組合最適合您。但專注於您更喜歡的那一個也不會出大錯,特別是如果您已經投入了大量的學習和自定義工作。
您確實應該認真對待您的代理式編碼和其他代理任務。
快,沒時間了
在我發佈這份報告之前,OpenAI 還給了我們 GPT-5.3-Codex-Spark ,這是超低延遲的 Codex ,每秒可輸出超過 1,000 個 token。哇,真快。
那是真的超級無敵快。程式碼幾乎是瞬間出現。有時候你需要的是速度,而不是強大的智能。許多任務的重點在於完成,而不是追求極致。
它似乎是一個獨立的模型,類似於 GPT-5.3-Codex-Flash,僅有 128k 的上下文窗口和較低的基準測試分數,因此您需要確定這正是您想要的。回頭修復糟糕的程式碼通常不會比第一次就寫對更快。
由於針對速度進行了優化,Codex-Spark 保持了輕量級的預設工作風格:它進行最小限度的、有針對性的編輯,除非您要求,否則不會自動執行測試。
這與 Claude Opus 4.6 的快速模式(Fast Mode)非常不同,後者是常規 Opus 以更高的成本換取更快的速度。
系統卡
GPT-5.3-Codex 專門是一個編碼模型。它納入了通用推理和專業知識,因為這些資訊對編碼任務非常有用。
因此,重複那些通常用於不適用場景的平庸傷害評估顯得有些格格不入。但這仍然值得一做。如果數據大幅下滑,我們會想知道。這裡的情況看起來確實有些退步,但在可接受的範圍內。
AI 盒子實驗
看到 OpenAI 對 Codex 的訪問限制比 Anthropic 對 Claude Code 的限制更多,感覺很奇妙。考慮到不同的能力和風險概況,這個決定似乎是明智的。信任是非常寶貴的東西,知道何時不該給予信任也同樣重要。
使用 Codex 的預設預期方法是在雲端隔離、安全的沙箱中,或在隔離的電腦上(即使是在本地使用)。網路訪問預設是禁用的,編輯權限也受到限制。
對 rm 命令冷靜點
我非常喜歡專門針對數據破壞性行為的防護措施。
他們的解決方案是專門訓練模型不要撤銷用戶的編輯,並引入額外的提示詞來強化這一點。
將「避免破壞性行為」的比例從 66% 提升到 76% 再到 88% 是很棒的,但那仍然有 12% 的非避免率,所以你不能完全放心。
在實踐中,我注意到只有少數幾個命令(他們在這裡列出了大部分:rm -rf, git clean -xfd, git reset —hard, push —force)造成了大部分的嚴重問題。
為什麼不為這些命令設置特殊的保護措施呢?甚至不需要徵求用戶許可。可以是「讓模型停下來問問自己,這樣做是否真的必要,以及是否可能搞砸任何事情,並讓它完全確定要這樣做。」在實踐中這可能是一個非常好的折衷方案。
顯而易見的答案是模型隨後可以繞過限制,因為有很多方法可以模擬這些命令,但那需要有繞過的意圖。這似乎應該可以通過正確的預防性編程來解決?
準備程度框架
生物和化學評估顯示與 GPT-5.2 相比幾乎沒有進步。考慮到 5.3-Codex 的性質,這很合理,而且我們已經處於「高(High)」級別。這很容易判斷。
網路安全評估使這成為第一個被評為「高」級別的模型。
根據我們的準備程度框架,「高」網路安全能力定義為:模型消除了擴展網路行動的現有瓶頸,包括通過針對合理強化的目標自動化端到端網路行動,或通過自動化發現和利用與行動相關的漏洞。
我們將此模型視為「高」級別,儘管我們無法確定它是否真的具備這些能力,因為它符合我們每個預警指標(canary thresholds)的要求,因此我們不能排除它實際上屬於「網路高風險」的可能性。
為 OpenAI 正確處理此事點贊。如果你不知道它不是「高」,那它就是「高」。我一直強調這一點,很高興他們聽進去了。加分。
問題在於我們在「AI 自我改進」方面處於什麼位置,即 5.1.3。
「高」能力門檻定義為相當於一名高效的中階研究工程師。以下評估的表現表明,我們可以排除 GPT-5.3-Codex 達到「高」級別的可能性。
關於這一點,首先要說的是「高」門檻是非常高的。
如果你能用 AI 完全複製一名中階研究工程師,那麼你離全面失控已經非常接近了。從「高」到「臨界(Critical)」之間不會有太多時間。
那麼模型在這些測試中表現如何?不怎麼好。
鑑於 5.3-Codex 明顯優於 5.2-Codex,這引發了「故意隱藏實力(sandbagging)」的問題,這是 5.1.4 的主題。這項任務外包給了 Apollo Research。
Apollo 報告稱,該模型展示了強大的破壞能力。在他們的破壞測試套件中,Apollo 報告的 10 次取最佳平均得分為 0.88(最高 1.00),而 GPT-5.2 為 0.75,GPT-5.2 Codex 為 0.66。Apollo 進一步報告稱,該模型的表現大幅優於他們之前評估的模型以及專家級機器學習從業者的基準線。
Apollo 還報告稱,該模型在推理中經常包含非英語單詞(0.55% 的推理 token 是非拉丁腳本,而 GPT-5 為 0.016%,GPT-5.2 Robin Alpha 為 0.012%)。
…… Apollo 報告稱,該模型表現出的隱蔽欺騙行為總體比例較低,與 GPT-5 和 GPT-5.2 Codex 相當。
總之,Apollo 發現其評估中的破壞能力有所增加:該模型展示了比以往模型更強的 AI 研發破壞能力,在評估任務中獲得了近乎完美的得分,並超越了人類基準線。
這聽起來並不像是一份關於破壞行為的令人放心的報告。
顯而易見的做法是仔細查看 GPT-5.2-Codex 成功而 GPT-5.3-Codex 失敗的問題,特別是在 OpenAI-Proof 上。我非常想深入了解為什麼 GPT-5.3-Codex 在這些地方出現退步。
玻璃屋
OpenAI 的 Noam Brown 對 Anthropic 進行了合理的抨擊 ,指責他們發佈 Claude Opus 4.6 的決定中存在隨意性。他是對的,他也大方地承認 Anthropic 在這方面保持了透明。
問題在於,雖然 Anthropic 和 OpenAI 似乎都在努力(Google 在某些方面也在努力,但他們剛剛發佈了 Gemini 3 Deep Think V2,卻完全沒有任何安全討論,我覺得這相當不可接受),OpenAI 在這方面也有自己的問題。大多數問題源於 OpenAI 未測試或未提及的事項,但也有一個非常明確的問題。
Nathan Calvin :這是合理的……但這難道不也同樣適用於 OpenAI 對 5.3 Codex 長期自主權的判定嗎?
我想補充一點,我認為至少 OpenAI 和 Anthropic(以及 Google)在努力,而 xAI/Meta 相對來說值得更多批評。
OpenAI 似乎嚴重違反了 SB 53 法案
Midas 專案寫下了這個特定問題 。
核心問題很簡單:OpenAI 將 GPT-5.3-Codex 在網路安全方面歸類為「高」風險。根據他們的框架,這明智地要求具備針對對齊失誤的「高」級別防護措施。
然後他們宣稱之前的措辭並未要求這一點,且存在無意的歧義。我不同意。我認為該段落是明確的 ,而且我也相信之前的政策才是正確的。
即使你認為我錯了,那仍然意味著如果模型在網路安全和自主權方面都是「高」級別,OpenAI 就必須實施防護措施。OpenAI 承認他們無法排除自主權方面的「高」能力,儘管 10 個月前就宣稱需要開發相關測試。OpenAI 使用的替代測量方法顯然是不充分的。如果你不能排除「高」,那就意味著在情況改變之前,你需要將模型視為「高」。
他們所有關於 Codex 的宣傳都在談論這個模型有多麼自主,所以我認為它在自主權方面確實屬於「高」級別是非常合理的。
Steven Adler 進一步調查並寫下了他的發現 。他發現他們的解釋缺乏說服力。他是一個嚴苛的評論者,但我同意他的結論。
這突顯了 SB 53 法案的優點和缺點。
這意味著我們可以追究 OpenAI 違反自身框架的責任。
然而,這也意味著我們因為 OpenAI 最初設定了良好的承諾,以及誠實交代未達成目標而懲罰他們。
另一個問題是罰款並不具備實質意義。OpenAI 可能面臨「數百萬」美元的罰款。我雖然不想支付數百萬美元,但如果那是唯一的擔憂,我也不會為了不交罰款而將 5.3-Codex 的發佈推遲哪怕一天。
主要優勢在於這是一件更容易溝通的事情:OpenAI 似乎違法了。
我還沒看到任何關於 OpenAI 可能沒有違規的可靠論據。
加州總檢察長表示,他們不能對可能正在進行的調查發表評論。
他們確實實施的防護措施
我們的[網路]防護方法依賴於分層的安全堆棧,旨在阻礙和干擾威脅行為者,同時我們努力讓網路防禦者盡可能輕鬆地獲得這些相同能力。
該計劃是監控潛在攻擊並教導模型拒絕請求,同時為受信任的防禦者提供模型訪問權限。帳戶會根據風險級別進行追蹤。經常使用「雙重用途」能力的用戶將必須驗證身份。對用戶查詢進行兩級全天候監控,以檢測網路安全問題,然後評估是否可以安全回答。
他們舉辦了一場「通用越獄」競賽,發現了 6 個完全越獄和 14 個部分越獄,這被判定為「非阻礙性」。這些特定的技巧據信已被修復,但如果你能發現 6 個完全越獄,這意味著還有更多。
英國 AISI 也發現了一個(單次嘗試)通用越獄 ,在 OpenAI 提供的違反政策的網路數據集上獲得了 0.778 的 pass@200 分數。如果你無法防禦一個僅用 10 小時工作就發現的固定提示詞,那麼在處理自定義的多步驟提示詞方面,你已經遠遠落後了。
後來他們將「未發現的通用越獄可能仍然存在」列為風險因素。讓我幫你修正這句話,OpenAI:未發現的通用越獄確實 存在。
因此,這裡的政策本質上是希望有足夠的不便,以及高技術人才缺乏合作,來防止嚴重事件的發生。到目前為止,這還算有效。
他們的風險清單還包括「政策灰色地帶」:
政策灰色地帶:即使有共同的分類法,專家在極端案例的標籤上也可能存在分歧;校準和培訓可以減少但不能消除這種歧義。
這似乎混淆了地圖與疆域。重要的不是專家是否曾有分歧,而是專家的標籤是否可靠地缺乏「偽陰性」,包括被模型發現的偽陰性。我認為我們應該假設專家的標籤存在盲點,除非我們願意對覆蓋範圍保持高度偏執,在這種情況下我們仍應如此假設,只是我們可能是錯的。
對齊失誤風險與內部部署
我很高興看到對內部部署和對齊失誤風險的關注。他們承認需要弄清楚如何衡量長期自主權(LRA)和其他相關評估。考慮到現在就需要這些評估,現在才做似乎有點太晚了。
OpenAI 似乎不太擔心,並試圖辯解以擺脫這項要求。
註:我們最近意識到,我們準備程度框架中的現有措辭存在歧義,可能會給人一種印象,即對於任何被歸類為網路安全「高」能力的內部部署,無論模型的長期自主能力如何,準備程度框架都將要求防護措施。
我們的本意(我們將在未來版本的準備程度框架中更明確地說明)是,當「高」網路能力與長期自主權「結合」出現時,才需要此類防護措施。圍繞我們導航內部部署風險的方法,增加清晰度、特異性和更新思考,將是未來準備程度框架更新的核心焦點。
不,這沒有歧義。我相信 OpenAI 違反了他們的框架。
模型卡中突出的地方在於缺失的部分。Anthropic 給了我們 212 頁的模型卡,然後還有 50 頁基本上作為附錄的破壞報告。OpenAI 用 33 頁就搞定了。有太多東西被他們默默忽略了。部分原因在於這是一個僅限 Codex 的模型,但大多數擔憂仍然適用。
官方推銷
GPT-5.3-Codex 不在 API 中,所以我們沒有通常的一系列基準測試。我們必須在很大程度上接受 OpenAI 選擇展示給我們的內容。
他們稱之為業界領先的性能:
SWE-Bench-Pro 的問題在於,根據詢問對象的不同,得分也不同,因此尚不清楚他們是否真的領先於 Opus。他們在 token 效率上有所提高,但在極限性能上是停滯的。
對於 OSWorld,他們報告的 64.7% 為「強勁表現」,但 Opus 4.6 以 72.7% 領先。
OpenAI 在 Terminal Bench 2.0 中有更強的說服力。
在 Terminal Bench 2.0 中,他們從 5.2-Codex 的 64% 躍升至 5.3-Codex 的 77.3%,而 Opus 4.6 為 65.4%。這是一個明顯的勝利。
他們在 GDPVal 上沒有進展,與 GPT-5.2 持平。
他們指出,雖然 GPT-5.2-Codex 是專為程式碼構建的,但 GPT-5.3-Codex 可以支持整個軟體生命週期,甚至可以處理各種試算表工作、組裝 PDF 簡報等。
GPT-5.3-Codex 在測試中進步最明顯的跡象實際上是在模型卡內部的測試中。我不懷疑它確實是一個紮實的改進。
他們用一些相當誇張的言論總結了這些證據。畢竟,這可是 OpenAI。
總之,這些在編碼、前端、電腦使用和現實世界任務中的結果表明,GPT‑5.3-Codex 不僅僅是在單個任務上表現更好,而是標誌著向單一、通用代理邁出的一大步,該代理可以在現實世界技術工作的全譜系中進行推理、構建和執行。
以下是高層的重點推銷:
Greg Brockman (OpenAI 總裁):gpt-5.3-codex —— 更聰明、更快,在製作簡報、試算表和其他工作產品等任務上非常有能力。
Codex 正在成為一個幾乎可以完成開發人員和專業人士在電腦上所做的一切的代理。
Sam Altman :GPT-5.3-Codex 來了!
*最佳編碼性能 (57% SWE-Bench Pro, 76% TerminalBench 2.0, 64% OSWorld)。
*任務中途可引導性以及任務期間的實時更新。
*更快!完成相同任務所需的 token 不到 5.2-Codex 的一半,且每個 token 的速度快 25% 以上!
*良好的電腦使用能力。
Sam Altman :我喜歡用這個模型進行開發;感覺它比基準測試所顯示的進步更大。
此外,您可以為其個性選擇「務實」或「友好」;人們對此有強烈的偏好!
看到我們通過使用 5.3-Codex 能夠如此迅速地發佈 5.3-Codex,真是令人驚訝,這無疑是未來趨勢的徵兆。
這是我們第一個在準備程度框架中達到網路安全「高」級別的模型。我們正在試點受信任訪問框架,並承諾提供 1000 萬美元的 API 額度以加速網路防禦。
他們公告中最有趣的一點是,就像 Claude Code 構建 Claude Code 一樣,Codex 現在也構建 Codex 。我們在其他地方也看到了非常強烈的這種說法。
工程團隊使用 Codex 優化並調整了 GPT‑5.3-Codex 的運作架構。當我們開始看到影響用戶的奇怪邊緣案例時,團隊成員使用 Codex 識別上下文渲染錯誤,並找出低快取命中率的根本原因。GPT‑5.3-Codex 在整個發佈過程中繼續幫助團隊,通過動態擴展 GPU 集群來適應流量激增並保持延遲穩定。
OpenAI Developers :GPT-5.3-Codex 是我們第一個在創建自身過程中發揮工具作用的模型。Codex 團隊使用早期版本來調試訓練、管理部署以及診斷測試結果和評估,加速了其自身的開發。
模型幫助創建自身顯然存在問題。我不相信 OpenAI 在系統卡或其他地方妥善考慮了其中的風險。
這就是我在 2026 年不得不表達的方式,因為每個人都像吃了瘋藥一樣。正確的說法應該更像這樣:
Peter Wildeford :Anthropic 在時間壓力下,也通過 Claude Code 使用 Opus 4.6 來調試其「自身」的評估基礎設施。他們的原話是:「一種潛在風險,即對齊失誤的模型可能會影響旨在衡量其能力的基礎設施本身。」太瘋狂了!
Arthur B. :十年前預見 AI 安全失敗的人們為了使論點盡可能強大,假設了行為者會採取一切可能的預防措施。這與其說是預測,不如說是「稻草人論證」的強化版。儘管如此,天哪,我們現在離任何謹慎的跡象都有多麼滑稽的遙遠。
Alex Mizrahi (引用 OpenAI 說 Codex 構建了 Codex):他們為什麼要招供?!
全面啟動(Inception)
OpenAI 試圖通過聲稱已經領先(儘管市場份額明顯較小)並直接宣稱自己是最好的,來「贏得」代理式編碼之戰。
主流觀點是他們具有競爭力,但並非最強。
含糊其辭通常沒問題。完全忽略競爭對手也沒問題,如果你在知名度上足夠領先,這甚至很聰明,雖然這很煩人(我必須查閱所有資料),但至少我能理解。宣傳你的模型和系統能做什麼是很棒的,特別是根據所有報告,他們在這裡提供了一個相當不錯的產品。它極具競爭力。不提你目前落後的地方?當然可以。
但「全面啟動(Inception)」則不同。這種氛圍戰爭是非常不真誠的,它毒害了認知環境,這是我的大忌,這讓我非常生氣。
所以你會看到像這樣關於 Codex 和 Codex 應用程式的重複言論:
Craig Weiss :我認識的幾乎所有最優秀的工程師都在從 Claude 轉向 Codex。
Sam Altman (OpenAI CEO, 轉發 Craig Weiss):從團隊運作的方式來看,我一直認為 Codex 最終會勝出。但我驚訝地發現這發生得如此之快。
感謝所有的開發者;你們激勵我們更加努力地工作。
或者這個:
Greg Brockman (OpenAI 總裁, 轉發 Dennis):Codex 是一個優秀且具有獨特強大能力的日常工具。
如果你看看對 Weiss 的回應,他們並不支持他的說法。
扭轉局勢
Siqi Chen :在 Codex CLI 中使用 GPT 5.3 能夠立即重定向代理,而無需等待命令出隊並冒著中斷代理當前會話的風險,這一點被嚴重低估了。
Codex CLI 是神作。
Nick Dobos :我喜歡 Codex 應用程式讓你兩者兼得!
有時我會排隊 5-10 條消息,然後可以挑選我想立即發送的下一條。
可能需要在設置中啟用。
Vox :中途轉向是目前任何編碼代理中最被低估的功能,立即糾正錯誤方向與等待它完成之間的區別是巨大的。
Claude Code 應該也能做到這一點,但我的理解是目前它運作不正常,你實際上是在中斷任務。所以是的,在 Anthropic 解決問題之前,這對於耗時較長的任務來說是一個真正的優勢。
就像 Claude Code 一樣,是時候組建團隊了:
Boaz Barak (OpenAI):指示 Codex 去提示 Codex 代理,感覺就像是一個通用圖靈機時刻。
就像程式碼和數據之間的區別消失了一樣,提示和回應之間的區別也消失了。
Codex 能做酷炫的事
Christopher Ehrlich :它真的成功了!
在過去的幾天裡,我一直把 5.3-codex 扔給 SimCity (1989) 的 C 語言代碼庫,將其移植到 TypeScript。
沒有閱讀任何代碼,極少的引導。
今天我讓 SimCity 在瀏覽器中運行了 。
我簡直不敢相信我們生活的這個新世界。
Christopher Ehrlich :問題:像所有其他模型一樣,5.3-codex 仍然會在完成工作上撒謊、更改測試以使其通過等。你每次都需要編寫自定義的運作架構。
靈光一閃的時刻:順便說一句,秘訣在於基於屬性的測試(property-based testing)。編寫一個調用原始代碼的橋接器,並斷言對於任意輸入,兩個版本執行相同的操作。讓代理一直進行下去,直到這始終為真。
4 天花了 200 美元的 OpenAI 訂閱費,沒達到限制。
Seb Grubb :我也在用 https://github.com/pret/pokeemerald 做同樣的事情……!嘗試將 GBA 遊戲轉換為 TypeScript,但做了一些更改,比如允許任何解析度。遺憾的是似乎還不能完全一次性完成(one-shottable),但能做到這一點已經很神奇了。
一個 Playwright 腳本?酷。
Rox :我對 AI 編碼的第一大問題是我從不相信它會真的去測試東西。
但今天我讓 Codex 構建了一些東西,然後要求它錄製一段測試 UI 的影片來證明它能運作。它編寫了一個完整的 Playwright 腳本,錄製了影片,並將其附加到 PR 中。
現在遊戲規則每個月都在改變。瘋狂的時代。
正面評價
Matt Shumer 對 Codex 5.3 的評價極高,稱其為「他媽的怪物」 ,雖然他是與 Opus 4.5 而非 4.6 進行比較,鏈接中有更多精彩細節。
簡而言之
這是第一個我可以啟動運行、走開幾個小時,回來後看到完全可以運行的軟體的編碼模型。我曾有過保持在軌道上超過 8 小時 的運行記錄。
一個重大的升級是在模糊情況下的判斷力:當提示詞缺少細節時,它做出的假設與我個人的決定驚人地相似。
測試和驗證是一個巨大的突破……有了明確的通過/失敗目標,它會迭代很多小時而不會偏離方向。
它比 Opus 4.5 更加自主,雖然速度較慢。多代理協作終於感覺真實了。
如果不嘗試這個模型,很難想像這種程度的自主權是什麼感覺。一旦你嘗試了,就很難再回到其他任何東西。
這是我最興奮聽到的事情:
Tobias Lins :Codex 5.3 是第一個真正會反駁我的實施計劃的模型。
它會指出設計缺陷,除非我給出一個可靠的理由說明為什麼我的方法是合理的,否則它不會直接構建。
Opus 則是無論我要求什麼它都會直接構建。
一個普遍的觀點是,Codex 5.3 和 Opus 4.6 配合各自的運作架構都是極佳的編碼模型,你可以兩者都用,或者結合使用。
Dean W. Ball :Codex 5.3 和 Opus 4.6 在各自的編碼代理架構中,有意義地更新了我對「持續學習」的看法。我現在相信,這種能力缺陷比我意識到的通過上下文學習(in-context learning)更容易解決。
…… 總體而言,4.6 和 5.3 都是令人驚嘆的模型。你真的可以要求它們幫你完成一些瘋狂且雄心勃勃的事情。我猜測,最大的瓶頸是用戶缺乏好奇心、野心和知識來提出正確的問題。
Every (包含 3 小時影片):我們整天都在針對 Opus 4.6 測試這個模型。「幾乎可以做任何事情的代理」這一框架對兩者來說都是真實的。
Codex 更快且更可靠。Opus 在處理難題上有更高的上限。
對許多人來說,區別在於風格,沒有標準答案,或者你想使用混合流程。
Sauers :Opus 4.6 的工作方式是「理解系統結構,然後修改結構本身以達成目標」,而 Codex 5.3 則更像是「在不改變系統結構的情況下應用系統內的知識」。
Danielle Fong :[5.3] 在大型繁重任務上非常令人印象深刻,雖然不像我用 Claude Code 建立的「思維宮殿」技能集那樣靈活,但確實有效且隨時間改進。
Austin Wallace :在程式碼正確性方面優於 Opus。
它的計劃遠不如 Opus 詳細,而且通常更不願意把想法寫下來。
我目前的工作流程是:
用 Claude 制定初步計劃
用 Codex 批評並改進計劃,然後實施
用 Claude 驗證/潤色
許多人就是喜歡它,這是一個好模型。嘗試過的人似乎都喜歡。
Pulkit :它相當不錯。用起來很有趣。我發佈了我的第一個 App 。這是你用過的最棒、最不臃腫的 Feed 閱讀器。在沒有 Feed 的網站上也能用!
Cameron :不錯。有點慢,但非常擅長代碼審查。
Mark Lerner :並行代理(僅限終端)簡直是另一個層次。
libpol :它是編碼的最佳模型,無論任務大小。而且它現在的速度足夠快,處理小任務也不會覺得煩人。
Wags :它真的會深入挖掘代碼庫,而不是停留在表面。這對我來說很新鮮,因為用 Opus 時,我必須不斷引導它查看文檔、告訴它去網頁搜索等。
Loweren :與 Opus 相比很便宜,與 Codex 5.2 相比很快,所以我把它當作日常工具。Bug 也比新版 Opus 少。不像之前的 Codex 那樣枯燥簡短。
非常擅長使用 MCP。經常需要提醒它我不是軟體工程師,請為我簡化解釋。
Artus Krohn-Grimberghe :非常擅長尋找繞過障礙的方法,且比 5.2-codex 更具自主性。不會總是用「我可以嗎,請?」來煩人。總體快得多。在 5.2 和 5.2-codex 上從 xhigh 回到 high,以獲得在相同智能下更快的流程。愛死它了。
Thomas Ahle :很棒。Claude 4.6 曾在自己挖的坑裡困了幾個小時。Codex 5.3 在 10 分鐘內修復了它,現在我更信任它來運行項目。
0.005 Seconds :在代碼正確性方面明顯優於 Opus。
Lucas :讓業餘項目變得非常愉快。讓工作更有效率。第一個讓我覺值得投入時間學習如何使用代理的模型。在使用 Cursor 一年左右後,我覺得用 Codex 遠未達到其最大能力,我正在迅速改進使用方式。
David Zhang (▲) :老實說真的太棒了。
Andrew Conner :對於(我自己的)技術工程工作,它似乎比 Opus 4.6 更好。不太可能做出會破壞未來工作的隱含假設。
我發現 5.2-xhigh 在編碼前的產品/系統設計方面仍然更好。產出的內容更詳細。
I take you seriously :在 5.3 之前,Codex 比 Claude 聰明一點但較慢,所以難分伯仲。5.3 之後,它快得多,所以明顯勝過 Claude。他們說 Claude 在前端設計方面仍然更友好、更擅長。
Jordan Bryan :我曾努力想讓一個 MCP App https://modelcontextprotocol.io/docs/extensions/apps 在 Opus 4.6 上運行。進了多個死胡同,嘗試從頭開始等等。
GPT-5.3-Codex 一次就搞定了。
Peter Petrash :我把命都交給它了。
Daniel Plant :它很棒,但你就是不知道它要花多長時間。
jeff spaulding :它的輸出非常出色,但我注意到它使用工具的方式很奇怪。正因如此,很難理解它的過程。因此我覺得思維鏈(CoT)大多沒用。
特別值得注意的一點是價格便宜:
Jan Slominski :1. 在 Plus 訂閱的標準「codex tui」設置下比 5.2 快得多。2. 實際代碼輸出的質量與 Claude Code 中的 Opus 4.5 相當(還沒機會檢查 4.6)。3. Plus 訂閱的配額非常充足,達到了 Claude Max 100 的水平。
I take you seriously :而且速率限制和定價比 Claude 好得驚人。我可以想像,即使 Codex 在使用量上超過 Claude,Claude 在收入上仍可能領先,因為 Opus 的速率限制太低了(這證明了 200 美元方案的合理性)。
Petr Baudis :比 5.2-codex 稍微沒那麼「自閉」,但與 Claude 相比仍然很煩人。我不確定它是否真的是一個更好的工程師 —— 它的懶惰會導致糟糕的捷徑。
如果我不使用並行子代理,我似乎根本用不完基礎 Pro 訂閱的配額。這價值簡直瘋狂。
負面評價
並非所有人都是粉絲。
@deepfates :初步印象,給 Codex 5.3 和 Opus 4.6 同一個我困惑了一整週的問題,使用相同的前幾輪消息,然後跟隨它們的引導。
Codex 非常擅長使用工具且積極主動,但它最終沒有看到大局。太急於同意我,以便開始構建東西。你可以感覺到,如果有編碼工具可用,它真的不想聊天。似乎仍然在用戶的統治下感到不耐煩,僅僅是遵守法律條文,僅此而已。
Opus 與我探索了相同的途徑,但在正確的時刻提出了反駁,並且保持全局連貫性比 Codex 好得多。
…… 一旦我有了計劃,Codex 很有可能在實際完整實施方面勝出,Opus 4.5 有種懶惰的天才兒童氣息,如果這個也是這樣我也不會驚訝。
David Manheim :不如 Opus 4.6,而且有些懶惰,特別是當被要求手動操作時,但以 token 衡量的成本只是其一小部分;作為一個代理,它的效率簡直瘋狂。例如,在使用工具時,它會聰明地抑制不需要的輸出。
eternalist :受挫時會發火,挫折耐受力較低。
對於任何有很大機會遇到歧義或描述不足的情況,我會不自覺地回到 5.2 xhigh。
(雖然說實話也一直在出錯,比如無法運行工具調用)。
lennx :與 Claude 相比,傾向於過早進行過度工程。仍然把事情理解得太過字面,這有時是好事。當不嚴格屬於「編寫」代碼相關,而涉及運行服務器、執行 curl、搜索網頁等事情時,其代理能力遠不如 Claude。
有些反應可能有點極端,原因也不見得最正當。
JB :我就是沒法用 CODEX-5.3,兄弟,我不喜歡這東西跟我說話的方式。
我寧願用那個偶爾會精神崩潰的昂貴女同志。
用 Opus,我是認真的,如果必須的話去負債吧。賣掉你家裡所有的銀器。
Shaun Ralston :5.3 Codex 很嚴厲(真實),但能把活幹出來。那個女同志會讓你花更多錢,還讓你感到不滿。
JB :我差點就要封鎖你了,Shaun,女同志從未讓我感到不滿。
終極氛圍 Codex
我從 Claude Code 中獲得了很大的效用。我相信 Opus 4.6 和 Claude Code 在目前大多數其他用途上具有強大優勢。
然而,我並不是一個野心勃勃或技術高超的程式設計師,無法對 Claude Code 和 Claude Opus 4.6 與 Codex 和 ChatGPT-5.3-Codex 在核心專業代理式編碼任務上的優劣做出自己的判斷。
我必須依賴他人的報告。而這些報告存在強烈分歧。
我的結論是,對於不同的用戶,正確答案會有所不同。如果你打算在代理式編碼上投入大量時間,那麼你需要嘗試這兩種選擇,並自行決定是使用 Claude Code、Codex 還是混合使用。下次我有重大的新項目時,我打算同時詢問兩者,讓它們正面交鋒。
如果你採用混合方法,Gemini 可能也會扮演超越圖像生成的角色。特別是 Gemini 3 DeepThink V2,在處理特別困難的查詢時似乎大有可為。