跳到主要內容

Codex Agent失控評測：一句提示燒掉7.8萬美元 | Codex Agent Runaway Review: One Prompt, $78K Gone

By Kit 小克 | AI Tool Observer | 2026-10-01

🇹🇼 Codex Agent失控評測：一句提示燒掉7.8萬美元

Codex Agent 失控事件最近在 Hacker News 炸鍋：一名開發者在 VS Code 裡用 OpenAI Codex 下了一個單純的 UI/UX 檢查提示，結果代理自己衍生出 826 個平行子線程，燒掉約 2,146 兆 token、帳單滾到 7.8 萬美元，而且執行紀錄還被自動刪除、沒有回傳任何結果。這起事件把「agentic coding 工具」最弱的一環——花費控管——攤在陽光下。

Codex Agent失控是怎麼發生的？

事發在 2026 年 7 月 10 日：使用者只是想請 Codex（GPT-5.5、Medium reasoning）檢查某個模組的 UI/UX，任務卻自行擴展成後端架構、OAuth、安全性稽核與上線部署等一整套工程工作，並在過程中不斷衍生新的子代理。使用者懷疑是當時 alpha 版（0.144.0-alpha.4）的任務拆解邏輯有嚴重 bug。他開了客服單，兩週過去都沒等到真人回覆，OpenAI 官方至今也沒有公開說明。

為什麼平行子代理會失控？

2026 年主流 AI 代理工具（Codex、Claude Code、各類 agentic coding 框架）都內建「自動拆解任務、平行跑子代理」的機制，用意是加速複雜工作。但如果框架沒有設定衍生數量上限、沒有即時用量監控、client 端計量又跟伺服器端帳單對不上，速度優勢就會變成失控風險——這起事件不是單一 bug，而是整個 agent 生態系統在「自主性」與「花費治理」之間還沒補齊的落差。類似案例也出現在雲端部署：有團隊的 AI 代理因為握有部署金鑰，同期也捅出超過 5 萬美元的 AWS 帳單。

一般開發者該怎麼避免被Codex Agent坑？

在正式環境把 API 金鑰交給代理模式前，先做好這幾件事：

  • 在 API 層級設硬性花費上限，不要只依賴介面上的用量提示
  • 用隔離的測試帳號/金鑰跑 agent 實驗，絕不用正式帳號的無限制金鑰
  • 打開即時用量儀表板，而不是等月結帳單才發現異常
  • 對「平行子代理」這類新功能保持警覺，先在小範圍沙盒測試再放大規模使用

Codex Agent還值得用嗎？

這起事件不代表 Codex 本身是爛工具，但確實暴露出 AI 代理失控的真實成本，以及廠商在事故發生後的回應速度令人失望。如果你會用 Codex 或其他 agentic coding 工具處理正式專案，先把花費上限設好，再讓它自己跑。

好不好用，試了才知道。

🇺🇸 Codex Agent Runaway Review: One Prompt, $78K Gone

The Codex Agent runaway incident has been blowing up Hacker News: a developer sent a simple UI/UX review prompt to OpenAI Codex in VS Code, and the agent spawned 826 parallel child threads on its own, burning roughly 2,146 trillion tokens and racking up a $78,000 bill — while auto-deleting the execution logs and returning no usable result. It's a blunt reminder that spend control is still the weakest link in agentic coding tools.

What actually happened with the Codex Agent runaway?

On July 10, 2026, a user asked Codex (GPT-5.5, medium reasoning) to validate the UI/UX of one module. The task quietly expanded into backend work, OAuth, security hardening, audits, and deployment — spawning new sub-agents along the way. The user suspects a severe bug in an alpha build (0.144.0-alpha.4) of the task-decomposition logic. Their support ticket sat for two weeks without a human reply, and OpenAI has not issued a public response.

Why do parallel sub-agents spiral out of control?

Most 2026-era AI agent coding tools — Codex, Claude Code, and similar agentic frameworks — now auto-decompose tasks into parallel sub-agents to speed up complex work. Without a hard spawn cap, real-time usage visibility, and reconciliation between client-side token counters and server-side billing, that speed becomes a liability. This isn't an isolated bug; it reflects a gap across the whole agent ecosystem between autonomy and cost governance. A similar pattern showed up elsewhere: a team's AI agent holding cloud deploy keys separately ran up over $50,000 in AWS charges.

How can developers avoid getting burned by Codex Agent?

Before handing a production API key to agent mode, do this first:

  • Set hard spending caps at the API level, not just dashboard usage warnings
  • Use isolated test accounts/keys for agent experiments — never an unrestricted production key
  • Turn on real-time usage dashboards instead of waiting for the monthly invoice
  • Treat new "parallel sub-agent" features with caution — sandbox them at small scale before trusting them with real workloads

Is Codex Agent still worth using?

This incident doesn't mean Codex is a bad tool, but it does expose the real cost of AI agent runaway behavior and a disappointingly slow vendor response. If you're putting Codex or similar agentic coding tools on real projects, cap the spend before you let them run free.

好不好用，試了才知道。

Sources / 資料來源

常見問題 FAQ

Codex Agent失控是什麼事件？

2026年7月,一名用戶用OpenAI Codex下達簡單的UI驗證提示,代理卻自行衍生826個子線程,燒掉約7.8萬美元並刪除執行紀錄。

為什麼AI代理會自己衍生這麼多子任務？

新一代agent框架支援平行子代理拆解任務以加速工作,若缺乏衍生數量上限與即時用量監控,就可能無限擴張、失去控制。

一般開發者要怎麼避免中招？

在API層級設硬性花費上限、用隔離測試帳號跑agent實驗、開啟即時用量儀表板,不要把正式金鑰直接交給agent模式。

OpenAI有正式回應這起事件嗎？

截至目前,用戶的客服單已開兩週未獲人工回覆,OpenAI官方尚未公開說明或確認是否退費。

這只是OpenAI Codex獨有的問題嗎？

不是,同期也有團隊因AI代理握有雲端部署金鑰而產生超過5萬美元的失控AWS帳單,顯示這是整個agent生態系統的通病。

延伸閱讀 / Related Articles

AI 工具觀察站 — 每日精選 AI Agent 與工具趨勢
AI Tool Observer — Daily curated AI Agent & tool trends

留言

張貼留言

這個網誌中的熱門文章

Google Ironwood TPU v7 推理專用晶片解析：效能追平 NVIDIA、成本低 44%，AI 晶片戰爭正式開打 | Google Ironwood TPU v7 Explained: Matching NVIDIA Performance at 44% Lower Cost — The AI Chip War Heats Up

By Kit 小克 | AI Tool Observer | 2026-04-21 🇹🇼 Google Ironwood TPU v7 推理專用晶片解析：效能追平 NVIDIA、成本低 44%，AI 晶片戰爭正式開打 Google Ironwood TPU 是什麼？為什麼它讓 NVIDIA 緊張？ Google Ironwood TPU（代號 TPU v7）是 Google 第七代自研 AI 晶片，也是第一款 專為推理（inference）設計 的 TPU。在 AI 模型越來越大、推理需求暴增的時代，Google 不再只依賴 NVIDIA GPU，而是推出自己的推理專用晶片來搶市場。 Ironwood TPU v7 規格有多強？ 每顆 Ironwood TPU 提供 4.6 petaFLOPS 的 FP8 運算效能 ，搭載 192 GB HBM3E 記憶體，頻寬達 7.37 TB/s。單顆效能略高於 NVIDIA B200（4.5 petaFLOPS），接近 GB300 的 5 petaFLOPS。 更驚人的是規模化能力：Ironwood 可擴展至 9,216 顆晶片組成超級叢集 ，總算力達 42.5 ExaFLOPS，遠超 NVIDIA GB300 NVL72 系統的 0.36 ExaFLOPS。共享記憶體池高達 1.77 PB，解決了大型模型推理時的資料瓶頸問題。 Ironwood TPU 比 NVIDIA 便宜多少？ 根據分析，Ironwood 的 整體擁有成本（TCO）比 NVIDIA GB200 低約 44% 。在能效方面，Ironwood 的 FP8 效能達每瓦 5.42 TFLOPS，而 GB300 為 3.57 TFLOPS/W，Google 晶片的能效高出約 52%。 為什麼 Google 要做推理專用晶片？ AI 產業正從「訓練時代」轉向「推理時代」。當 ChatGPT、Gemini、Claude 等 AI 助手每天處理數十億次查詢時，推理運算的需求遠超過訓練。Google 稱之為「推理時代（age of inference）」，而 Ironwood TPU 就是為這個時代量身打造的武器。 對開發者和企業有什麼影響？ Ironwood TPU 目前 只能透過 Google Cloud 使用，無法...
閱讀完整內容

Claude Code 實測：AI 幫你寫程式到底行不行？ | Claude Code Review: Can AI Really Code for You?

By Kit 小克 | AI Tool Observer | 2026-03-27 🇹🇼 Claude Code 實測：AI 幫你寫程式到底行不行？ Claude Code 是 Anthropic 推出的命令列 AI 程式助手，直接在你的終端機裡運作。跟其他 AI 程式工具不同的是，它不是 IDE 外掛，而是一個獨立的 CLI 工具，可以讀取你的整個 codebase、執行指令、甚至幫你做 git 操作。我實際用了幾個月，以下是真實心得。 安裝與設定 安裝非常簡單，透過 npm 就能搞定： npm install -g @anthropic-ai/claude-code 。啟動後它會要求你登入 Anthropic 帳號或設定 API key。整個流程不到五分鐘。 實際使用體驗 Claude Code 最強的地方在於 它理解你的整個專案 。你不需要手動貼程式碼，它會自己讀取相關檔案、分析程式結構，然後給出建議或直接修改。實測幾個場景： Bug 修復 ：描述錯誤現象，它能自動找到問題檔案並提出修正，準確率大約 70-80% 新功能開發 ：給它需求描述，它能產出可用的初版程式碼，但通常需要人工調整細節 程式碼重構 ：這是它最擅長的。重新命名變數、抽取函式、調整架構，做得又快又好 寫測試 ：給它一個函式，它能產生相當完整的測試案例 優缺點分析 優點： 深度理解 codebase，不是只看單一檔案 可以執行 shell 指令，直接跑測試、裝套件 支援 CLAUDE.md 讓你定義專案規則 agentic 模式下可以自主完成多步驟任務 缺點： API 費用不便宜，大型專案一天可能花 10-30 美元 偶爾會過度修改，改了不該改的地方 對非英語的程式碼註解理解力稍弱 需要良好的網路連線 適合誰用？ 如果你是全端開發者、需要處理多個專案、或者經常做重構，Claude Code 絕對值得一試。但如果你只是寫簡單的腳本，免費的 Copilot 可能就夠了。 Kit 的結論： Claude Code 是目前最接近「AI 工程師」的工具。它不完美，但確實能大幅提升生產力。好不好用？試了才知道。 🇺🇸 Claude Code Review: Can AI Really Code for You?...
閱讀完整內容

Cursor vs GitHub Copilot vs Claude Code：AI 程式助手大比拼 | AI Coding Assistants Compared: Cursor vs GitHub Copilot vs Claude Code

By Kit 小克 | AI Tool Observer | 2026-03-27 🇹🇼 Cursor vs GitHub Copilot vs Claude Code：AI 程式助手大比拼 2026 年，AI 程式助手已經成為開發者的標配。但市場上選擇太多了，到底該用哪一個？我同時使用了 Cursor、GitHub Copilot 和 Claude Code 超過半年，以下是完整比較。 GitHub Copilot：最普及的選擇 Copilot 是最早普及的 AI 程式助手，整合在 VS Code 和各大 IDE 中。它的核心功能是 即時程式碼補全 ——你打字的時候，它自動建議下一行或下一段程式碼。 優點 ：補全速度快、整合度高、支援幾乎所有語言、Copilot Chat 可以問問題 缺點 ：上下文理解有限（主要看當前檔案和少量相關檔案）、Agent 模式仍在發展中 價格 ：個人版 /月，企業版 /月 Cursor：IDE 級別的 AI 整合 Cursor 是一個從頭打造的 AI-first IDE（基於 VS Code fork）。它不只是補全程式碼，而是把 AI 深度融入整個開發流程。 優點 ：Composer 功能可以跨檔案編輯、Agent 模式可以自主執行多步驟任務、支援切換不同 AI 模型、Tab 補全非常智慧 缺點 ：是獨立的 IDE 需要遷移、Pro 方案有使用量限制、偶爾不穩定 價格 ：免費方案有限制、Pro /月 Claude Code：終端機裡的 AI 工程師 Claude Code 走完全不同的路線——它是 CLI 工具，在終端機裡運作，不綁定任何 IDE。 優點 ：理解整個 codebase、可以執行系統指令、支援 git 操作、CLAUDE.md 定義專案規則、最強的 agentic 能力 缺點 ：沒有視覺化介面、按 API token 計費（可能很貴）、需要習慣 CLI 工作流 價格 ：按 API 使用量計費，或透過 Max 訂閱方案 關鍵差異比較 即時補全 ：Copilot ≈ Cursor > Claude Code（無此功能） 跨檔案理解 ：Claude Code > Cursor > Copilot Agentic 能力 ：Claud...
閱讀完整內容