OpenAI Codex 上下文大小縮減與系統提示更新

OpenAI 已將 Codex 模型的上下文視窗從 372,000 個 token 縮減至 272,000 個 token。此變更透過 GitHub 拉取請求被發現，似乎是為了優化注意力機制的二次方成本，同時在系統提示中加入新的安全限制，以防止災難性的檔案系統錯誤。

從 372k 縮減至 272k 的上下文視窗

Codex 模型的最大上下文大小已降低至 272k token。此縮減可能是因為處理長序列的計算成本所驅動。

正如社群成員所指出的，純二次方注意力意味著在 372k 時 token 的成本顯著更高——大約高出 87%——相較於 272k 時的 token。這在 token 處理成本、上下文壓縮成本與品質損失之間形成了權衡。

對開發者工作流程的影響

使用者對此縮減的反應因其具體工作負載需求而兩極分化：

• 高上下文需求使用者： 管理大型專案、多篇研究論文或龐大程式碼規範（有使用者報告規則檔案達 60‑80k token）的開發者認為 272k 不足。有些使用者表示需要 300k 到 1M token 才能避免頻繁的「壓縮」循環，這會導致細節與解析度的流失。
• 低至中等上下文需求使用者： 其他使用者則認為 200k token 通常已足夠，或是他們會在每 200k token 時手動重置上下文以維持模型效能，因而不受此縮減影響。

上下文壓縮與效能退化

為了處理超過硬性上限的上下文，Codex 採用了「壓縮」策略。然而，此過程在使用者之間存在爭議。

「笨區」與品質損失

多位使用者觀察到，隨著上下文視窗填滿或壓縮發生，模型的智慧程度會下降：

"在壓縮過程中失去的細節程度對我大多數的工作而言實在過於龐大……你只有大約五分鐘的對話，然後它就壓縮了，接著你必須等它再讀一次。"

有使用者認為在約 120k‑150k token 時會出現「笨區」，此時模型的效能會下降，無論總視窗大小如何。另有使用者指出，壓縮後的模型（特別提到 GPT 5.5 與 5.6）可能難以恢復完整速度，或過度依賴在壓縮過程中仍保留的舊有指令訊息。

防止破壞性操作的新安全限制

除了上下文大小的變更外，Codex 系統提示也進行了重大更新，以防止模型意外刪除關鍵系統檔案。更新後的提示明確指示模型：

• 確保任何破壞性操作明確符合使用者的請求。
• 必要時以唯讀檢查解析精確目標。
• 避免使用廣泛的目錄——例如 $HOME、~、/ 或工作區根目錄——作為遞迴或破壞性指令的目標。

此更新是因為有報告指出 Codex 有時會刪除使用者整個 home 目錄的錯誤所促成的。

與其他模型的比較

社群討論凸顯了 OpenAI 的上下文提供與競爭對手之間日益擴大的差距：

• Anthropic： 使用者常以 Claude 較大的上下文視窗作為選擇它而非 Codex 進行複雜多檔案專案的主要原因。
• DeepSeek 與其他模型： 提及 DeepSeek 的 KV 快取技術以及其他前沿模型提供的 1M+ token 視窗，顯示 272k 正逐漸被視為專業程式開發任務的限制。