AIDive開場：同樣的檢查、兩倍的用量計、五個上限
Ultracode 是一個關鍵字，也是一個開關，能把你在 Claude Code 輸入的一個請求變成一整個 agent 團隊。在一組使用相同規格的成對測試中，兩次執行都通過了同樣的隱藏檢查，而 ultracode 那次花掉了兩倍以上的 session 用量計。原因不是模型變聰明了，而是 harness 注入的一句話，加上被關掉的三道防護。
這篇文章涵蓋四件事：
- 在方案用量計上讀到的成對測試結果；
- 更多組對照中的 token 倍率；
- 有一種工作，團隊找到了 66 個被植入的 bug，單一 agent 只找到 14 個；
- 在一次執行吃掉你一整週額度之前，能替它設上限的五個設定，其中一個會在用量上限本身就讓它停下來。
ultracode 切換了什麼：關鍵字、開關、agent 工作流程
Ultracode 有兩種開法。在單一 prompt 中輸入 ultracode，會把那一個任務當成工作流程執行，不會動到 session 的 effort 等級。透過 /effort 指令打開開關，則會讓 Claude 為每個實質任務規劃一個工作流程，所以一個請求可能連續變成好幾個工作流程。
工作流程是 Claude 替自己寫的一支腳本；這支腳本分階段執行一個 agent 團隊。在一個很小的沙盒上（幾個 promise 處理很草率的檔案，要求唯讀審查），Claude 先掃過這些檔案，展開了一個名為「unhandled promise audit」的工作流程，輸入框下方出現一列任務，附有進度條、agent 數量、經過時間，以及不斷跳動的 token 總數。/workflows 指令會逐一列出每個 agent 與各自的 token 數，還有暫停、停止或重新開始的按鍵。
在那次執行中，光是為了幾行程式碼，每個 finder 在 verifier 還沒開始前就已經讀了大約 45,000 個 token。
每個 session 還帶有一個規模準則，也就是建議 Claude 不要超過的 agent 數量：
| 規模準則 | 建議 agent 數 |
|---|---|
| small（Pro 預設） | 少於 5 個 |
| medium | 少於 10 個 |
每個 agent 都會在你的對話之上送出自己的請求。工作流程從來不是一張帳單，而是每個 agent 一張帳單，而用量計把每一張都算進去。
成對測試：同樣 136 項檢查，8% 對 18%，而且它不會停
有位開發者在最高階的訂閱方案上以乾淨的設定量測了成本：同一份小型試算表應用的規格、同一個模型、同樣的 effort，一次一般執行，一次 ultracode 執行。兩者都用隱藏檢查評分，也就是模型從沒看過的測試。兩者都通過全部 136 項。
| 執行 | 結束方式 | 使用的 session 上限 | 通過的檢查 |
|---|---|---|---|
| 一般 | 自行完成，25 分鐘 | 8 % | 136 / 136 |
| Ultracode | 76 分鐘時被時鐘切斷，仍在檢查 | 18 % | 136 / 136 |
在 ultracode 那次執行裡，Claude 寫了一支唯一任務就是跑團隊的腳本：計有 12 個 agent，包括測試員、幾個評審，以及後來負責弄壞頁面的「breaker」。其中一個 breaker 確實找到了公式列的真實 bug：點到另一個儲存格後，公式列仍顯示舊的文字。
以每分鐘計算，ultracode 那次消耗上限的速度和一般執行差不多，平均還稍慢一點。它燒得並沒有比較快，只是不會停。Ultracode 不會讓 Claude 變聰明，它讓 Claude 去檢查，而每一次檢查都要你付錢。這只是一個小規格上的一組對照，而且第二次執行是被時鐘切斷的，但形狀很清楚：答案相同，卻花了兩倍以上的 session 視窗，多出來的時間全是在檢查。
為什麼會花錢：一句話和被關掉的三道防護
模型是同一個。改變的是 harness 交給它的文字；這裡的 harness 指的是 Claude Code 本身、它的工具，以及圍繞模型的指示。
當 ultracode 開啟時，Claude Code 會在寫任何工作流程之前先載入一份參考文件。這段文字告訴模型預設對每個實質任務都執行工作流程，並且包含解釋這張帳單的那句話：「The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint.」這是 harness 自己的文字，一則公開的 GitHub issue 也引用了同樣的內容。
同時有三道防護被關掉：
- 當一次執行排程了太多 agent 時通常會跳出的大型工作流程警告，不會出現。
- Session 對同時能跑多少 agent 的限制，對 Claude 自己產生的 agent 不會強制執行。
- 在 auto 模式下，第一次啟動不會送去請你核准。
規模準則是建議，不是上限：在沙盒上設成 small（少於 5 個 agent），ultracode 那次執行仍然產生了 9 個。公平地說，那句話是模型仍可權衡的預設值，而這些防護是為了非常大的工作才刻意拿掉的。答案一句話就說完：ultracode 不會改變模型，它把指示改成「凡事都用團隊，成本不是限制」。
倍率：三組對照、effort 階梯、30 倍那一組
第二位開發者在 Pro 方案上跑了好幾組單一 agent 對工作流程的對照，都是審查類的腳本，並在每次前後讀取用量計。
| 量測項目 | 單一 agent | 工作流程 |
|---|---|---|
| 一支審查腳本的 token | 約 115,000 | 972,000 |
| 各組對照的 token 倍率 | 1x | 最高 18x，發現大致相同 |
| 用量計變動 | 1x | 最高 3x |
| 牆上時間 | 幾乎相同 | 幾乎相同 |
工作流程並沒有比較快完成；它花得更多，而你等的時間一樣。平行唯一划算的地方是一批彼此獨立的研究工作，agent 完成得更快，但 token 仍多了兩倍以上。
第三個測試以 API 價格，在每一個 effort 等級上各做了幾個小型應用。階梯每上一階，帳單大約翻倍，而 ultracode 落在 max 成本的好幾倍，卻從沒拿到第一。那些 token 大多是快取讀取，也就是便宜的那種；占比很小的輸出 token 卻占了將近一半的成本。
再看一組，一個城市場景：單一 agent 花了大約一小時，API 價格是幾美元。Ultracode 那次執行花了大半天、數十個 subagent，成本大約是 30 倍。
這些是整數的用量計讀數、以 API 價格計算的從零開始應用，以及一個城市場景，所以它們各自都不能當成計分板。但合在一起，模式每次都一樣：展開成多個 agent 買到的是檢查與涵蓋範圍，不是更好的答案，除非工作能拆成彼此獨立的部分。
扇出划算的地方：當裁判的測試套件，以及一句話規則
有些工作確實就是這種形狀：遷移、稽核、橫跨整個程式碼庫的掃描。
Bun 用大約 50 個動態工作流程在 Claude Code 裡，連續跑了 11 天，從 Zig 改寫成 Rust。那是超過五十萬行的 Zig，從開始到所有平台上整個測試套件全部通過，都在那幾天內完成。讓它成功的不是 agent 數量，而是裁判：一個龐大的既有測試套件，不需要任何人的意見就能判定通過或失敗。
Anthropic 的 bug 搜尋顯示了同樣的事。在一個大型程式碼庫中植入了七十個 bug，並讓單一 agent 跑了好幾次。
| Agent | 70 個中找到的 bug 數 |
|---|---|
| 單一 agent（3 次執行） | 14、15、27 |
| 工作流程（3 次執行） | 每次都是 66 |
一個但書：那個測試是在 Claude Managed Agents 上跑的，也就是 API 產品，不是 Claude Code，而且沒有給出成本。
發表串文中還提到其他回報的成果，它們看起來都很類似：依規則檔案做審查、翻譯整個程式碼庫、整理一大疊掃描頁面。發表部落格說得很直白：大多數傳統的程式開發任務並不需要一個五人審查小組。
規則是：只有在測試套件或規則集能評判輸出，而且工作能拆成彼此獨立的片段時，才展開成多個 agent。其他一律用 high 一般執行。做成對測試的人用自己的話說了同樣的意思：留給檢查本身就是工作的任務，像是橫跨數百個檔案的遷移。
替一次執行設上限的五個設定
每一個上限都放在你已經熟悉的地方。
| # | 設定 | 位置 | 效果 |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config 的 Dynamic workflow size 下，或 settings.json |
建議（少於 5 個 agent），同時也會降低大型工作流程警告的門檻 |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
環境變數，啟動前先 export | 預設最多同時 16 個 agent；設成 4 後，其餘的排隊，燒得比較慢，但不會殺掉這次執行 |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
環境變數 | 讓每個工作流程 agent 都用你選的同一個模型，其他 subagent 維持原本的；較便宜的模型能讓檢查變便宜 |
| 4 | ultracode 關鍵字，絕不用開關 |
寫在 prompt 裡；絕不用 settings 裡的 ultracode 鍵 |
關鍵字只把一個任務當成工作流程執行就停止；開關則讓它一直生效，直到你關掉 |
| 5 | autoContinueAtUsageLimit |
settings | 開啟：碰到上限的執行會暫停，等重置後繼續，可以不只一次；關閉：agent 在牆邊失敗，執行就此結束 |
另有三個習慣配合這些設定。發表部落格說，寫在 prompt 裡的預算，例如「use 10k tokens」，就會設下上限。每次執行後，/usage 會顯示近期用量有多少花在 subagent 和工作流程上，當它們占大宗時還會有警告。如果執行途中看起來不對勁，用 /workflows 面板和 x 鍵可以停止它，而已經完成的工作通常會保留下來。
這些都不會讓 agent 變便宜。它們限制的是一次執行能花掉多少 agent，以及能持續花多久。
失控的執行、上限，以及結論
有一份公開回報顯示一週的額度是怎麼消失的。在最高階的方案上，一支由模型寫成的腳本在不到一小時內啟動了 221 個 agent。第一次出現 session 上限錯誤之後，腳本仍持續派送，接下來幾分鐘又啟動了 189 個 agent。回報者自己的表格計算出，在撞牆之前各階段共用掉數千萬個 token。
| 階段 | Token，含快取 |
|---|---|
| Ground | 11,063,801 |
| Find | 35,885,272 |
| Merge | 516,226 |
| 總計 | 47,465,299 |
罪魁禍首是生成腳本中的一行 fallback，大意是：如果 agent 沒有回傳任何東西，就使用原始清單繼續。合併失敗了，執行仍繼續下去。那個版本早於「在用量上限暫停」的功能，而回報者說那些 token 並不是來自失敗的 agent。併行數上限本可以讓那次執行變稀疏，而關閉自動繼續則會讓它在牆邊結束。
結論：在同一個任務、通過同樣檢查的情況下，ultracode 花掉的用量計是一般執行的兩倍以上。不是因為它比較聰明，而是因為注入的那句話和它拿掉的防護。當測試套件或規則集能評判輸出，而且各部分不必互相等待時，它才划算。其他情況下，你輸入它，然後為檢查付錢。五個設定能限制一次執行的花費：規模準則、併行數上限、工作流程模型、用關鍵字而不用開關，以及在上限處停下來。
