Ultracode 與 Effort 等級：把 Claude Code 開到十一級

在 Claude Code 的大部分歷史裡，你只有一個大旋鈕：用哪個模型。到了 Fable 5 時代，出現了第二個旋鈕，而且它在日常使用中可能更重要。對支援的模型而言，/effort（推理強度）控制每一步推理的用力程度。Ultracode 與這個五級模型旋鈕分開：它是 session-only 的 Claude Code 模式，為實質任務結合 xhigh 與 dynamic workflow 編排。

本指南涵蓋五個標準 effort 等級、ultracode 實際改變了什麼、官方用來監看與限制 workflow 規模的控制方式，以及——同樣重要的——什麼時候該把這一切通通關掉。

Effort 實際控制什麼

/effort 為你的 session 設定推理強度。它不會改變由哪個模型回答你——那是 /model 的事——它改變的是那個模型在行動之前，對每一步花多少思考。

這筆交易很直接：

more effort  →  deeper reasoning per step
             →  more tokens, more latency
             →  better answers on hard problems

less effort  →  faster, cheaper turns
             →  perfectly fine for mechanical work

/model 和 /effort 都可以在 session 中途切換，但持久化有例外：max 只限 session，除非透過 CLAUDE_CODE_EFFORT_LEVEL 設定；ultracode 則一定會在 session 結束時重設。所以流程是：先設一個模型支援的合理預設值，當特定任務值得比預設更多（或更少）時，再伸手去轉旋鈕。

如果你同時也在決定要跑哪個模型，建議搭配我們的模型選擇指南一起讀——模型層級與 effort 等級是兩個獨立的旋鈕，而有趣的配置正是把它們混搭起來。

五個標準等級

對支援 effort 的模型，/effort 提供五個標準等級：low、medium、high、xhigh 與 max。

官方沒有逐等級的規格表，你也不需要。有用的心智模型來自 effort 在多代理 workflow 內部的使用方式：便宜、機械式的階段用低 effort；困難的驗證與判斷階段用高階層級。把同樣的邏輯套用到你的 session：

等級	什麼時候用它
low	機械式工作：改名、格式化、樣板程式碼、「讀這個檔案告訴我 X」
medium	日常寫程式：例行功能、直觀的修復
high	真正困難的問題：棘手的除錯、跨多檔案的重構、設計問題
xhigh	最困難的判斷型工作：架構決策、對抗式驗證、「這絕對不能錯」
max	額外花費確實有價值時的最深模型推理；留意效益遞減

Claude Code 2.1.226 將 Fable 5、Opus 5、Sonnet 5 與上一代 Opus 4.8 列為支援全部五級。Haiku 4.5 未列為支援 effort 的模型，因此使用時不要附加 --effort 或 workflow 的 effort 選項。模型可見性與 entitlement 可能因 provider、方案、帳號與 rollout 而不同，請以你環境中的 /model 為準。

關鍵轉變在於：對支援的模型來說，品質與成本現在是一個握在你手上的旋鈕，可以逐 session 調整，而且——如下所見——可以逐個子代理（subagent）調整。

Ultracode：Session-Only 的 xhigh 加編排模式

Ultracode 不是第六個 effort 等級，也不位於 max 之上：它是 Claude Code 的 session 模式，ultracode = xhigh effort + 動態 workflow 編排。

後半部分才是讓它在「種類」而非只是「程度」上與眾不同的原因。開啟 ultracode 後，Claude Code 被指示要：

為最詳盡、最正確的答案最佳化——而不是最快或最便宜的答案
在每個實質任務上使用多代理 Workflow 編排，而不是只在你要求時才用
接受實質任務可能會使用更多 tokens 並花更久時間

實務上這代表：像「review 這個 diff」這樣的任務，不再是一個 agent 讀檔案，而是變成一個腳本化的 Workflow：平行的搜尋者在整個變更範圍扇出（fan out），懷疑者 agent 嘗試反駁每一項發現，再由綜整階段組裝存活下來的結果。Workflow 可以生成數十個 agent、消耗大量 token——這正是 ultracode 採用選擇加入（opt-in）機制的原因。執行框架（harness）要求你明確請求那種規模；它絕不會在你不知情的情況下替你燒掉一筆 workflow 等級的 token 帳單。

如何選擇加入

Ultracode 本身有兩條啟用路徑：

關鍵字。 在 prompt 中包含「ultracode」進行單次選擇加入：
```
ultracode: audit the payments module for correctness bugs
```
那一輪會以全規模執行。下一輪就回到正常。
Session 切換。 透過 /effort 選擇 ultracode 進行常駐選擇加入——session 中的每個實質任務都會得到這種待遇，直到你把旋鈕調回去或結束 session。Ultracode 不能儲存為常設 effortLevel，並會在 session 結束時重設。

拉遠一層來看，更廣義的 workflow 編排還有第三扇門：當你明確要求（「用一個 workflow 來……」）或你呼叫的 skill 指示時，workflow 也會執行。沒有這三種選擇加入之一——ultracode、明確請求或 skill——Claude Code 預設使用個別子代理或獨自作業。大規模的編排永遠是你主動要求的。

成本控制：可見性、警告與規模指引

Ultracode 是對更大規模編排的選擇加入，不是固定花費的保證。官方控制方式是操作層面的：

/workflows 會在執行期間顯示逐 agent token 用量，也能停止 run。
排程超過 25 個 agent 或預估超過 150 萬 tokens 時，會顯示 Large workflow 警告。
/config 的 Dynamic workflow size 設定會引導 Claude 將 agent 數量控制在少於 5、15 或 50。

警告與 size 設定都只是建議。Claude Code 並未記載 +500k prompt 指令是硬上限，workflow 腳本也沒有公開的 budget.total / budget.remaining() 強制 API。高成本 run 應先從單一目錄或較窄問題開始，觀察結果與 token 用量，再有意識地擴大。

逐 Agent 的 Effort：把錢花在判斷所在之處

在 workflow 腳本內部，推理強度是逐個子代理設定的：effort: 'low' | 'medium' | 'high' | 'xhigh' | 'max'。大型執行的經濟學實際上就是在這裡決定的。模式是：

便宜的機械式階段（搜尋、讀取、格式化）→ 支援模型使用低 effort，或 Haiku 不覆寫 effort
困難的驗證/評判階段→ 高階層級

以下是一個有明確停止條件的探索迴圈，把兩個想法結合在一起——便宜的搜尋者在連續兩輪沒有新發現後停止，然後由昂貴的懷疑者處理所有找到的東西。（Workflow 腳本以一個 export const meta = { ... } 字面值開頭，宣告 name、description 和 phases；下面的片段是主體。）

phase('Discover');

let dryRounds = 0;
const seen = [];

while (dryRounds < 2) {
  const round = await parallel([
    () => agent(
      `Hunt for correctness bugs in the payments module.
       Already seen: ${seen.join('; ') || 'none'}.
       Report only NEW findings, or the word NONE.`,
      { label: 'hunt-correctness', model: 'haiku' }
    ),
    () => agent(
      `Hunt for error-handling gaps in the payments module.
       Already seen: ${seen.join('; ') || 'none'}.
       Report only NEW findings, or the word NONE.`,
      { label: 'hunt-errors', model: 'haiku' }
    ),
  ]);

  const fresh = round.filter(Boolean).filter(r => !r.trim().startsWith('NONE'));
  if (fresh.length === 0) dryRounds += 1;
  else { dryRounds = 0; seen.push(...fresh); }
}

phase('Verify');

const verdicts = await parallel(
  seen.map(finding => () => agent(
    `Try to REFUTE this finding. Confirm only if you cannot:
     ${finding}`,
    { label: 'skeptic', effort: 'xhigh' }
  ))
);

注意花費的形狀：可能跑很多輪的迴圈使用 Haiku 且不覆寫 effort，而 xhigh 保留給驗證階段——在那裡，一個錯誤的判斷才真的會讓你付出代價。搜尋者會被告知已經看過哪些東西，這樣它們就不會重複兜售舊發現；而迴圈只在連續兩輪空手而回之後才停止——這就是「loop-until-dry」（搜到枯竭）模式，在 effort 與 ultracode 教學及其品質模式姊妹篇中有深入說明。

什麼時候不該用 Ultracode

強力旋鈕的失敗模式，就是一直開著不關。以下情況請跳過 ultracode：

瑣碎的編輯。 改名、修錯字、調整設定只需要一個 agent 和低 effort。為此生成一個編排 workflow 純屬浪費。
對話式回合。 「這個函式在做什麼？」或「你偏好哪種做法？」從上下文（context）就能回答。沒有什麼可以扇出的。
單一事實查詢。 如果你知道答案在哪個檔案，直接讀取勝過任何委派。
任何你想要快速迭代的情況。 Ultracode 為詳盡與正確最佳化，這與你還在打草稿時需要的快速回饋迴圈恰恰相反。

經驗法則：ultracode 適合那些漏掉東西代價高昂、且搜尋空間大於單一 agent 上下文的任務。其他所有事情用正常 effort 跑得更好——而且便宜得多。關於更全面的成本考量，請見成本最佳化教學。

三個配方

稽核。 ultracode: audit the auth module for security issues. 這是 ultracode 的主場：完整性很重要的廣泛探索。先界定範圍，使用上面 loop-until-dry 的形狀、對每項發現做對抗式驗證，並明確交代覆蓋限制。

遷移。 ultracode: migrate every deprecated API call in src/ to the new client. 平行修改檔案的 agent 需要在它們的 agent() 呼叫上設定 isolation: 'worktree'——每個 agent 都拿到一個全新的 git worktree，這樣它們就不會互相踩踏，若無變更則自動移除。Worktree 每個 agent 都要花費實際的設置時間與磁碟空間，而這正是你輸入這個關鍵字時所同意的那種規模。

研究掃描。 ultracode: map every place we handle currency rounding, and how. 一次多模式掃描——平行的 agent 各自用不同的方式搜尋（按檔案位置、按內容、按實體、按時間）——接著由一個完整性評論者問「還缺什麼？」，其答案為下一輪播種。Haiku 可不覆寫 effort 來掃描，或讓支援 effort 的經濟模型使用 low；最終綜整才享受昂貴的待遇。

重點結論

對支援的模型而言，effort 等級把答案品質變成你可以逐任務控制的東西，而不是烙死在模型裡的定數。Ultracode 則是獨立的 session-only 模式：xhigh 推理加上常駐 workflow 編排，因為它可能花費更多時間與 tokens 而需要明確選擇加入。成本控制來自範圍、規模指引、即時可見性與停止 run 的能力，不是未記載的 token 硬上限。

值得培養的技能不是「永遠用 ultracode」——而是知道你的哪些任務值得轉這顆旋鈕。稽核、遷移、研究掃描：值得。你正要修的那個錯字：不值得。

想更深入？Effort 等級與 Ultracode 教學整理了已驗證的成本控制方式，而什麼是 Workflow？則解釋了 ultracode 賴以建立的編排層。