1. 首頁
  2. AI應用

Claude Max 20x 夠用嗎？我一天燒光週額度，Fable 只分到 50%

  • 更新日期：2026-09-07 22:49:32
  • 瀏覽數：15
目錄

💡 核心結論速覽 (TL;DR)

  • Claude Max 20x 的天花板不是一份，是兩份：官方寫明 Fable 模型在 Max 方案「最多只能用掉週額度上限的 50%」，而且 FAQ 自問自答否認這是加碼——它是同一池子裡的分區上限。
  • 多代理模式才是主要放大器：Anthropic 自家數據是 agent 約吃聊天的 4 倍 token、多代理系統約 15 倍；Claude Code 文件另給 agent teams 約 7 倍。
  • 開 ultracode 等於同時關掉兩道煞車：25 個 agent／150 萬 token 的「大型工作流」警告不再顯示，20 個並行子代理的上限也不再執行。
  • 先做這件事：把 Fable 從 max 降到 xhigh——官方評測顯示兩者分數在信賴區間內相當，但輸出 token 少 19～25%，這是零風險的第一刀。

那天我只是想跑一個跨資料夾的重構稽核，任務本身不算大。我把模型切到 Claude Fable 5.1，順手開了 ultracode，讓它自己決定要不要展開工作流。

跑到第三次，五小時視窗就滿了。

我當下的判斷是「那就等重置吧」——結果不服氣又繼續跑，等到晚上再看一次用量頁，整週的額度已經見底。我付的是 Claude Max 20x，一個月 US$200，官方文案寫著「20 倍」。一天燒完一週，這個比例怎麼算都不對。

後來我把官方文件從頭翻過一遍，才發現問題根本不在方案不夠大，而是我同時踩了三個放大器，而其中兩個是我自己親手把煞車拆掉的。這篇就是那次的完整拆解：Max 20x 到底承載得了什麼、額度是被誰吃掉的，以及我現在的「模型 × 模式」配對是怎麼重排的。

Claude Max 20x 夠用嗎？先看官方沒印在方案頁上的那條 50%

Claude Max 20x 對絕大多數單人工作流是夠的——但前提是你沒有長時間掛著 Fable 模型跑多代理。因為 Fable 在 Max 方案上有一條獨立的分區上限，這條規則不在訂閱結帳頁，而在 Anthropic 說明中心的 Fable 方案頁裡。

原文是這樣寫的：

「You can use up to 50% of your weekly usage limits on Fable models at no extra cost. They draw from your plan's regular weekly usage limits and use them faster than other Claude models.」

兩句話裡藏了兩顆地雷。第一顆是 50% 是上限，不是加碼。我最初的直覺跟很多人一樣——以為 Max 內含 Fable，那 Fable 就是「額外送的」。官方在同一頁的 FAQ 直接把這個誤會拿出來自問自答：

問：「Will I get 50% more for my weekly limit for Fable models if I'm on the Max plan…?」

答：「No. You can use up to 50% of your weekly limit on Fable models, but your use of other models draws from the same usage limits and you can never use more than your weekly limit.」

翻成白話：你的週額度是一個池子，Fable 最多只能舀走一半，而且你用 Opus、Sonnet 的量也從同一個池子扣。它不是「原本的量 + Fable 的量」，是「原本的量裡面，Fable 最多佔一半」。

第二顆地雷更直接——官方自己承認 Fable 吃額度比其他模型快。這不是社群推測，是「use them faster than other Claude models」這一句白紙黑字。

Anthropic 的企業版消耗指南講得更露骨：把 Claude Fable 的 token intensity 標成 Very High，備註寫「Premium pricing and faster usage draw than Opus」——比 Opus 更貴，而且扣得更快。

把這兩件事疊起來，就是我那天的體感來源：我以為自己有一整週的額度，實際上 Fable 能碰到的只有一半，而且它每個動作扣得比 Opus 兇。感覺上「一天燒光一週」，實際燒光的是那被切走的一半。

要補充一句，避免誤會：Fable 5.1 這次改版把快取讀取價格砍到四分之一，看起來像是變便宜了。但那是 API 端按錢計費才吃得到的好處——訂閱制的額度是按 token 算的，不是按錢算的。快取讀取的 token 一樣扣你的週額度。所以「它變便宜了」這個印象，反而會讓人更放心地開大規模，這也是我當時的心態之一。

這條規則在各方案的落點差很多，別套錯：

方案／席次 Fable 5 與 5.1 怎麼算 撞牆後怎麼辦
Max 5x／Max 20x 方案內含，上限＝週額度的 50% 改用 usage credits，或換別的模型
Team Premium 席次 同上，內含且上限 50% 同上
Pro／Team Standard 席次 完全不含，從第一個 token 就走 usage credits 本來就是按量付費
Free 不提供 —

官方 方案比較頁把這件事縮成一列：Fable 這一行在 Free 是 No、Pro 是 Usage credits、Max 5x 與 Max 20x 都是「50% of weekly limits」。如果你還在猶豫要不要升級、或不確定自己該落在哪一檔，先看我把四檔價差整個算過一遍的那篇再回來——這篇假設你已經在 Max 上了。

這段可以帶走的一件事：打開 Settings > Usage，確認你的週額度條旁邊那條 Fable 用量條——那才是你真正的天花板。

Max 20x 的「20 倍」是跟誰比？官方從頭到尾沒給過絕對數字

Claude Max 20x 的「20 倍」是相對 Pro 方案、以「每個五小時 session」為單位計算的，不是相對免費版，也不是週的倍數。這個定義差異會直接害你算錯自己的預算。

官方在 Max 方案說明頁只給了倍數：

  • Max 5x：每個 session 是 Pro 的 5 倍，US$100／月
  • Max 20x：每個 session 是 Pro 的 20 倍，US$200／月
  • Pro：尖峰時段至少是免費版的 5 倍
  • Team Premium 席次：Pro 的 6.25 倍；Team Standard 席次：Pro 的 1.25 倍

然後就沒有了。你在官方任何一頁都找不到「Max 20x 每五小時 = 多少 token」這種數字。這不是漏寫，是刻意的——定價頁的 FAQ 直接寫死：「so there's no fixed message count」，並解釋能做多少事取決於對話長度、複雜度、你選的模型與功能。

所以每次看到那種帶著小數點的額度對照表（「Pro 每 5 小時約 44,000 tokens」之類），第一反應應該是打問號。那些是社群反推的，不是官方值，而且模型換代、斷詞器換代之後就會失準。

而且這個誤差還會被放大。Fable 5.1 這一代用的斷詞器會讓同一段文字比舊模型多算約 30% token——拿舊帳推新帳，光這一項就先錯三成。

更值得記的是兩個視窗的關係，因為這決定了「撐不撐得住」的答案：

❶ 五小時 session 視窗：滾動式，用到上限之後五小時重置，跨所有模型共用。

❷ 每週視窗：帳號被指派一個固定時點、每週同一時間重置，同樣跨所有模型共用。這是那波週限額加碼促銷加的、也是後來收回的那一層。

這裡有個流傳很廣的錯誤說法要澄清：週視窗不是統一週一午夜重置。官方原文是「resets at a fixed time each week that is assigned to your account」——每個帳號被指派一個固定時點，而且不會因為你何時訂閱而改變。

網路上那個「Mon 12:00am」其實是 Claude Code 錯誤訊息文件裡的範例字串（同段的 session 範例寫 3:45pm），被當成規則抄了出去。

你自己的重置時間在 Settings > Usage 看得到，別用別人的。

還有一條很多人低估的：claude.ai、Claude Desktop、Claude Code 三邊的用量算同一份，IDE 裡的使用也算同一份。所以「我今天只是在聊天視窗問了幾個問題」跟「我在終端機跑了半天 agent」，扣的是同一個池子。

這也是為什麼很多人會覺得 Claude 突然變慢變笨——不是模型被降智，是你在別的介面已經先花掉了。

這段可以帶走的一件事：把「20 倍」重新理解成「每五小時 20 倍於 Pro」，而不是「一週 20 倍」。週上限是另一道獨立的牆。

我一天燒光整週額度那次：兩個視窗是同時扣的

我原本以為五小時視窗是「小限制」、週視窗是「大限制」，撞到小的等一等就好。這個理解錯得很徹底，而且官方文件其實早就寫了，只是藏在錯誤處理那一頁。

Claude Code 錯誤說明文件原文：

「Usage counts against the session and weekly allowances at the same time. A single burst of heavy activity, such as a large workflow fanout, can exhaust the weekly allowance before the session window resets.」

我看到 large workflow fanout 這幾個字的時候真的笑出來——官方等於把我那天做的事直接寫進文件裡當範例。一次大規模的工作流展開，可以在五小時視窗都還沒重置之前，就把整週的額度用光。

兩個視窗是同時扣的，不是先扣小的再扣大的。所以「撞到五小時上限 → 等重置 → 再跑一輪 → 又撞牆」這個循環，每一輪都在往週額度上挖一大塊。我那天等了兩次重置、跑了幾輪，就是這樣把週的額度挖穿的。

而且——換模型救不了。這是我當下第二個反射動作，也錯了。官方寫得很白：session 與 weekly 這兩個視窗跨所有模型共用，「switching models doesn't restore access」。

唯一的例外是 Opus、Sonnet 這種模型家族專屬的額度訊息（「You've hit your Opus limit」），那種換到家族外的模型還能繼續做事。

但你看到的如果是「You've hit your weekly limit」，換誰都一樣。

撞牆之後 Claude Code 會問你要不要等重置再自動接著跑——這個開關預設是開的，但它接的是哪一道牆、又有哪些情況它幫不上忙，我另外寫過一篇。簡單說：它是等，不是幫你付錢，而且週限額那張卡沒有這個選項。

這段可以帶走的一件事：撞到五小時上限的當下，先去看週額度用掉幾成再決定要不要繼續。如果週的已經過半，等重置只是換一個姿勢繼續挖。

為什麼多代理特別吃額度？官方自己給了兩組倍數

多代理不是「同一份工作分給很多人做」，是「同一份脈絡複製給很多人各讀一遍」。每個代理都有自己獨立的脈絡視窗、自己的思考、自己的工具呼叫——成本是加總的，不是攤分的。

這件事 Anthropic 自己公布過數字。工程部落格那篇多代理研究系統的文章寫得毫不修飾：

「There is a downside: in practice, these architectures burn through tokens fast. In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats.」

純聊天當 1 倍基準，單一 agent 約 4 倍，多代理系統約 15 倍。同一篇文章還補了一句經濟性但書：多代理只有在「任務價值高到付得起這個增幅」時才划算。

Claude Code 官方文件另外給了一組數字，講的是 agent teams：teammate 跑 plan mode 時大約是一般 session 的 7 倍 token，理由寫得很清楚——每個 teammate 各自維持一個脈絡視窗、各自是一個獨立的 Claude 實例。

這三組倍數不能互相換算（架構不同、量測情境不同），但方向完全一致：並行放大的是總量，而且大致跟活躍代理數成正比。

我把它整理成一張比較好記的對照：

執行方式 規模 官方給的相對量級
一般對話 一次一輪 1 倍（基準）
單一 agent 一輪內幾個委派 約 4 倍
agent teams（plan mode） 每個 teammate 一個獨立實例 約 7 倍
多代理系統 一次 run 數十到數百個 agent 約 15 倍

還有一個放大器藏在模型本身。Anthropic 給 Opus 5 的提示工程指南裡有這麼一段自承：

「Claude Opus 5 delegates to subagents more readily than prior models. Delegation pays off on genuinely independent, sizeable tracks of work, but it multiplies cost and time when applied to small tasks.」

新一代模型比舊模型「更愛派工」。所以就算你沒有主動開任何並行模式，光是換到新模型，同一個任務被拆成子代理去跑的機率也變高了。這條我覺得是最容易被忽略的——你什麼都沒改，帳單卻自己長大了。

如果你想看更完整的「並行到底省不省」拆解，我之前寫過動態工作流那把雙面刃；這篇不重複機制，專講訂閱額度這一側。

這段可以帶走的一件事：估算一個並行任務的成本時，用「代理數 × 單代理成本」，不要用「總工作量 ÷ 代理數」。後者是直覺，前者才是實際。

開 ultracode 等於同時關掉兩道煞車

Ultracode 不是模型的推理等級，是 Claude Code 的一個設定：它送給模型 xhigh 的推理強度，再額外讓 Claude 對每一個有份量的任務自動編排工作流。這個「額外」才是重點。

官方在 workflows 文件裡自己講了後果：一個請求可能連續變成好幾個工作流（一個理解程式碼、一個做修改、一個驗證），而且這適用於 session 裡的每一個任務，所以「每個請求都會用掉更多 token、也更慢」。

到這裡都還算合理——你選了更貴的模式，付更多是應該的。真正讓我沒察覺的是下面這兩條：

❶ 「大型工作流」警告會消失。

Claude Code 本來有一個提醒機制：當一次 run 排超過 25 個 agent、或預估總 token 超過 150 萬，任務面板就會跳出「Large workflow」警告，讓你有機會去 /workflows 把它停掉。但官方文件同一段接著寫：

「Sessions with ultracode on don't show the warning, because turning ultracode on already opts you in to large runs.」

邏輯上說得通——你都開 ultracode 了，代表你接受大規模執行。但實務上的結果是：你唯一的儀表板被關掉了。我那天完全不知道自己排了幾個 agent、預估要燒多少，因為那行字根本沒出現。

❷ 並行子代理的數量上限不再執行。

一般情況下，Claude Code 在同一個 session 有 20 個子代理同時跑的時候，再開就會失敗並回報 Concurrent subagent limit reached。但 子代理文件寫著：

「Sessions with ultracode active are exempt: the limit isn't enforced there.」

兩道護欄，一道是儀表板、一道是限流器，開一個開關同時消失。而工作流本身還有幾條硬上限沒被拿掉——同一次 run 最多 16 個 agent 同時跑、單次 run 全部加起來最多 1,000 個 agent——但那是防止程式失控的地板，不是保護你錢包的天花板。

還有一條容易誤會的：工作流跑的 token 就是算在你的訂閱額度上，沒有另計。官方原文是「Runs count toward your plan's usage and rate limits like any other session」——跟一般 session 一視同仁。

最關鍵的一條在這裡，也是 Fable 特別致命的原因：工作流裡每個 agent 的模型，沒人指定時就跑你 session 的模型。

我把主 session 設成 Fable 5.1，就等於把那一整批並行的代理全部設成 Fable 5.1。一個 Very High 消耗等級的模型，乘以十幾個並行——這才是「一天燒光」的完整算式。

（順帶釐清一個常見混淆：ultracode 和 ultrareview 不是同一回事。前者是本機 session 的推理與編排設定；後者是 /code-review ultra，跑在雲端沙箱的付費多代理程式碼審查，走 usage credits 而不是方案內含額度。兩個名字很像，計費方式完全不同。）

這種「開了某個開關，帳就多算一份」的陷阱不只出現在 ultracode。我之前算過Claude Code 接 Codex 外掛要不要付兩份錢，結論裡也有一個「先別開」的開關——同一個型態的坑，換一個地方出現而已。

這段可以帶走的一件事：如果你要用 ultracode，先去 /config 把 Dynamic workflow size 調成 small（目標少於 5 個 agent）。預設是 medium（少於 15 個），而那只是建議、不是上限。

我以為開 max 比較保守——官方說那是最浪費的一檔

這是整趟查證裡最打臉我的一段。

我當時的自我約束是：「ultracode 太兇，那我用 Fable 5.1 的時候只開 max 思考模式就好。」聽起來很節制對吧？我把「不開多代理」當成安全，卻沒發現 max 這個檔位在官方定義裡是：

「max: Absolute maximum capability with no constraints on token spending.」

「沒有 token 花費上限」。這不是保守，這是把煞車踩到底的另一個方向。而且 ultracode 送給模型的其實是 xhigh，比 max 低一階——所以就單則訊息而言，我「比較保守」的做法反而比 ultracode 更貴。

更精準的說法在 Fable 5.1 的官方提示工程指南裡。它直接點名了一個浪費模式：

「At xhigh and especially max effort, Claude Fable 5.1 can think for longer before it starts writing its reply. When a single request asks for a long deliverable… it may draft much of that deliverable in its thinking and then write it out again as the reply… Composing an entire output or deliverable in full as reasoning and then again as a reply would double the length of the turn without improving the result.」

在 max，Fable 5.1 可能會在思考裡先把整份長交付物寫一遍，再在回覆裡重寫一遍。長度翻倍，品質沒變。而 Fable 系列的思考是關不掉的——這點跟 Opus 5 不一樣，Opus 5 在 high 以下還可以關掉思考，Fable 在任何 effort 等級都強制開著。

那降一階會損失多少？Anthropic 的 Fable 5.1 系統卡收錄了兩組獨立評測的數字，答案是幾乎沒有：

評測 max 分數 xhigh 分數 xhigh 省下的輸出 token
GDPval-AA v2 ELO 1853 ELO 1835 約 25%
AA-Briefcase ELO 1694 ELO 1686 19%

兩組都寫著「matches max within the confidence interval」——分數差距落在信賴區間內，統計上相當。同一份系統卡還提到，AA-Briefcase 上就算降到 high（ELO 1611），仍然勝過所有非 Claude 模型，而且輸出 token 少 47%。

這幾個評測不是廠商自評，是由第三方評測機構 Artificial Analysis獨立執行的——在「降檔會不會變笨」這種問題上，誰量的跟量到什麼一樣重要。

所以那條「零風險的第一刀」就在這裡：把 Fable 從 max 降到 xhigh，用 /effort xhigh，省下大約兩成輸出 token，分數在誤差範圍內不變。我現在的預設就是這個，只有真的撞牆的難題才升到 max，而且只升那一則。

兩個必須一起講的但書，否則你會算錯：

❶ effort 影響的不只是思考。官方寫明它影響回應裡的「所有 token」——文字、工具呼叫、思考都算。低 effort 會讓工具呼叫變少、變短，高 effort 會讀更多檔、驗證更多次。所以它放大的是整條代理迴圈，不只是想得久一點。

❷ effort 的刻度是逐模型校準的。官方原文：「The effort scale is calibrated per model, so the same level name does not represent the same underlying value across models.」

白話說：Fable 的 high 和 Opus 的 high 不是同一個量。別把你在某個模型上調好的設定直接搬到另一個模型。

這段可以帶走的一件事：現在就打開 /effort，如果你的 Fable 停在 max，降成 xhigh。這是全篇投報率最高的一個動作。

Fable 5 和 5.1 誰比較吃額度？官方的答案是「一樣」

我最初的假設是新版更兇——畢竟體感差很多。但這條假設查完之後不成立，而且不成立這件事本身，才指向真正的變數。

官方說明中心那句話很硬：

「Fable 5 and Fable 5.1 work the same way on your plan.」

兩代在方案上是同一套規則：都內含在 Max、都是週額度 50% 上限、都比其他模型扣得快。

規格表也對得上——脈絡視窗都是 1M、最大輸出都是 128K、定價都是輸入 US$10／輸出 US$50 每百萬 token、都是永遠開著的 adaptive thinking、API 預設 effort 都是 high。硬體規格上找不到差異。

所以體感落差來自別的地方。我能查證的變數有三個，剛好也是最容易被忽略的三個：

❶ 你的 fable 別名可能被自動搬過去了。

Claude Code 從 v2.1.255 起，fable 這個別名解析到 Fable 5.1（之前是 Fable 5）。

而且如果你的使用者設定裡存的是舊的 claude-fable-5，第一次跑新版時它會被自動改寫成 fable 別名，啟動那行只會顯示一次 (auto-updated)。錯過那一行，你會以為自己還在同一個設定下比較。

❷ 官方對兩代的省錢建議語氣是相反的。

Fable 5 的文件寫「lower effort settings on Claude Fable 5 still perform well」，還鼓勵你「Reduce effort if a task completes but takes longer than necessary」——降 effort 是被推薦的常規動作。

Fable 5.1 的寫法變成「start with high, the default」，往下降要「once your evals show quality holds」——先證明品質守得住再降。

如果你在 Fable 5 時期養成了習慣性降 effort，換代後沒沿用，光這一項就是兩成以上的差距。

❸ 你的 Claude Code 版本一起變了。

Fable 5.1 需要 Claude Code v2.1.255 以上。而放大並行規模的那些機制——子代理巢狀深度預設、工作流規模建議值、ultracode 的護欄豁免——都是在這條版本線上陸續調整的。換模型的同時你也換了執行環境。

老實說，我沒有辦法拿出「5.1 比 5 多吃 X%」這種數字，因為官方沒公布，我也不打算自己編一個。但這三條都是你可以自己驗的——下一段就是驗法。

這段可以帶走的一件事：下次啟動 Claude Code 時看一眼模型那行，確認你以為在用的模型跟實際跑的是同一個。

額度被吃爆之前，我會先看的三個數字

診斷比省錢重要——你得先知道額度被誰吃掉，才知道要砍哪裡。這三個地方都是 Claude Code 內建的，不用裝任何東西。

❶ /usage 的 attribution：看是誰在吃

在 Pro、Max、Team、Enterprise 方案上，/usage 會把近期用量拆成四類歸屬——skills、subagents、plugins、以及個別的 MCP server，每一類顯示佔總量的百分比（官方成本管理文件有完整欄位說明）。按 d 或 w 可以切換近 24 小時與近 7 天。

同一畫面還有兩個東西值得看：behavior flags 會在某個行為（例如 long context 或 cache misses）佔近期用量 10% 以上時標出來；Loops 那一列會列出最吃 token 的排程任務，含每次執行的 token 量。

我那次回頭看，subagents 那一格的佔比高得很難看——如果我在跑之前先看一眼，故事會不一樣。

❷ 狀態列的兩條進度條：看還剩多少

Claude Code 的狀態列腳本可以直接讀到訂閱額度。官方文件寫明 rate_limits 物件裡有 five_hour 與 seven_day 兩個視窗，各自帶著 used_percentage（0 到 100）和 resets_at（重置時間的 Unix 秒數）。

把這兩條做成常駐的進度條，比事後查用量頁有用一百倍——因為額度爆掉的當下你通常正在專心做別的事，等你想起來要看已經來不及了。這是我事後補上的第一個防線。

❸ 知道 /cost 有一塊看不見：別被數字騙了

這是最容易誤判的一條。/usage 的 Prompt cache 統計那一行，官方註明「It covers the main conversation only, not subagents」——只涵蓋主對話，不含子代理。

也就是說：token 的歸屬有算子代理，但快取的統計沒算。你看到 91% 的快取命中率，那是主對話的成績，並行代理那一塊的快取表現你看不到。

還有一條同性質的盲區：/usage 的數字是「從這台機器的本機 session 紀錄推算的近似值」，官方明說「usage from other devices or claude.ai is not included」。你在手機上、在網頁版聊掉的量，這裡看不到，但它照樣扣同一個池子。

最後補一個會讓帳整個算錯的陷阱：如果你的環境變數裡有 ANTHROPIC_API_KEY，Claude Code 會改用那把金鑰計費，完全不吃訂閱額度。非互動模式（claude -p）更是連問都不問，只要環境裡有就直接用。

典型症狀是明明有訂閱卻收到「Credit balance is too low」。用 /status 看一眼目前生效的是哪一個，別到月底才發現付了兩次。

這段可以帶走的一件事：跑任何大型任務之前，先 /usage 按 w 看一眼週額度剩幾成。三秒的動作，省下的是一整週。

我現在的「模型 × 模式」配對表

把上面的機制收斂成一句話：成本 ≈ 單則的 effort 檔位 × 並行的代理數 × 模型的消耗係數。三個都是乘數，任何一個開到底都會失控，三個一起開就是我那天的下場。

所以我重排的原則不是「哪個模型最強」，是「哪個組合的乘積落在我付得起的範圍」。這是我現在實際在用的配對：

任務類型 模型 模式與 effort
日常改一支程式、查一段邏輯 Opus 5 單線，high（預設）
跨檔案重構、大範圍稽核 Opus 5 ultracode，size 設 small
單線卡關的硬題、長交付物 Fable 5.1 單線，xhigh（不開工作流）
大量機械性的重複處理 Sonnet 5 或 Haiku 4.5 並行，low 或 medium

三條規則說明我為什麼這樣排：

規則一：Fable 和多代理，一次只開一個。

這是全表最重要的一條。Fable 的消耗係數是 Very High，多代理的倍數是 4 到 15 倍——兩個相乘沒有任何方案撐得住，Max 20x 也不行，因為 Fable 只分到週額度的一半。要嘛用 Fable 深挖單一難題，要嘛用便宜的模型鋪開並行，不要同時。

規則二：需要並行的時候，我用 Opus 5 而不是 Fable。

多代理的價值在覆蓋面（同時看很多東西），不在單點深度。而覆蓋面這件事 Opus 5 做得夠好，價格只有 Fable 的一半（輸入 US$5／輸出 US$25 對 US$10／US$50），而且不吃那條 50% 的分區上限。

如果你的工作流會跨到別家、想知道同價位還有什麼選擇，同價位的旗艦對照我另外比過一輪。我之前算過 Opus 5 換代要改掉的幾個舊習慣，其中一條剛好就是「別放養子代理」。

規則三：便宜的模型不是次等品，是不同的工具。

官方 effort 文件把 low 的典型用途直接寫成「such as subagents」——子代理本來就適合用低 effort 跑。

如果你想把整批子代理釘在同一個便宜模型上，設 CLAUDE_CODE_SUBAGENT_MODEL 加上 CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1 就可以。四個模型各自擅長什麼、我平常怎麼分工另一篇有完整對照。

另外兩個可以直接設死的硬上限，比自律可靠：

  • CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS：限制同時執行的子代理數（注意：ultracode session 會豁免這條）
  • CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH：限制子代理再生子代理的層數

Anthropic 自己在 Opus 5 的提示指南裡就是這樣建議的——「set deterministic caps on how many agents can be launched」，設確定性的上限，而不是期待模型自己節制。

這段可以帶走的一件事：挑一個你最常跑的任務，照上表把它的「模型 × 模式」寫下來，下次直接照表開，不要臨場憑感覺。

撞牆之後三條路怎麼算帳？適合誰、不適合誰

如果你已經撞牆了，官方給的路只有三條。它們不是「哪個比較好」的選擇題，是看你撞的是哪一道牆——選錯了會花冤枉錢：

❶ 等重置（US$0）：適合撞到五小時視窗、而且今天沒有硬截止的人。不適合週額度已經過半的人——等重置只是換一個姿勢繼續挖。

❷ 開 usage credits（按標準 API 費率）：適合撞到週視窗、而手上的事有明確產出價值的人。不適合「因為設定太兇才撞牆」的人。

❸ 換模型繼續（US$0）：適合撞到 Fable 那條 50% 分區上限、但整體週額度還有餘的人。這是最多人沒想到還有的一條路——你的池子沒空，只是 Fable 那一格滿了。

什麼情況我會開 usage credits：手上這件事的產出價值明顯高於幾美元，而且離週重置還很遠。它是預付制、按標準 API 費率計費，可以設每月上限，也可以開自動加值。

要注意兩件事——一是這筆錢跟訂閱費分開收、會是帳單上另一筆；二是一旦開始吃 usage credits，快取生命週期會從訂閱制的 1 小時掉到 5 分鐘，長時間的 agent session 會因為更頻繁的快取失效而額外變貴。

什麼情況我不會開：如果你是因為設定太兇才撞牆（Fable 掛 max、ultracode 全開、子代理沒設上限），那開 credits 只是花錢延續同一個錯誤。先把設定調對，通常就不用花這筆。

什麼情況該考慮升級方案：如果你在 Max 5x 而且是天天撞週上限——不是偶爾，是天天——那 Max 20x 的 US$100 差價比 usage credits 划算。

但如果你撞的是 Fable 那條 50% 分區上限，升級不會解決問題，因為 50% 這個比例在 Max 5x 和 Max 20x 上是一樣的，池子變大但比例沒變。這是我覺得最容易花冤枉錢的一格。

Fable 額度用完之後的三條出路（額外使用量、升 Max、退回 Opus）我有另一篇把三種算法並排算過，數字都在那裡。如果你想從源頭少用一點，不升級也能把 token 砍半的那 10 個習慣是我認為最值得先做的一批。而AI agent 一個任務燒掉好幾美元的通論，可以當這篇的背景讀物。

這段可以帶走的一件事：撞牆時先分辨你撞的是哪一道牆（五小時／週／Fable 50%），三道牆的解法完全不同。

FAQ 常見問題

Claude Max 20x 和 Max 5x 該選哪個？用 Fable 的話有差嗎？

如果你天天撞週上限，Max 20x 的 US$100 差價通常划算，因為它是每個五小時 session 給 Pro 的 20 倍而不是 5 倍。

但如果你撞的是 Fable 那條 50% 上限，升級幫助有限——50% 這個比例在兩檔上是一樣的，池子變大、比例沒變，你只是撞得晚一點。這種情況下先降 effort、先把並行關掉，比多付 US$100 有效。

開了 ultracode 之後，怎麼知道自己排了幾個 agent？

用 /workflows 這個視圖——它會即時顯示每個 agent 的 token 用量，而且可以隨時停止，通常不會丟掉已完成的工作。

這在 ultracode session 特別重要，因為「Large workflow」警告在 ultracode 開啟時不會顯示，/workflows 是你唯一看得到規模的地方。

想壓成本的話，去 /config 把 Dynamic workflow size 設成 small（目標少於 5 個 agent）。

把 effort 降下來，品質會掉很多嗎？

在 Fable 5.1 上，從 max 降到 xhigh 幾乎不會——兩組獨立評測都顯示分數落在信賴區間內，但輸出 token 少 19～25%。

再往下降到 high 會有可測量的差距，但在長時程知識工作的評測上仍然勝過所有非 Claude 模型，而且再省 47% token。我的做法是預設 xhigh，只有真的卡住才單次升到 max。

要注意 effort 的刻度是逐模型校準的，你在 Fable 上調好的檔位不能直接搬到 Opus。

Fable 5.1 可以像 Opus 5 那樣關掉思考來省 token 嗎？

不行。Fable 系列在所有 effort 等級都強制開著 extended thinking，官方文件寫死「Disabling thinking is not available on Fable models」，連 API 上都關不掉。

Opus 5 在 high 以下可以關（但在 xhigh 或 max 嘗試關閉會回 400 錯誤）。所以在 Fable 上，effort 是你唯一的控制桿。

子代理跑的 token 算不算進我的訂閱額度？

算。工作流與子代理的用量都算進方案的用量與速率限制，官方寫明「like any other session」。

而且沒人指定模型時，子代理會跑你主對話的模型——所以主 session 設成 Fable，那一整批並行代理就都是 Fable。這是最容易被低估的一筆。你可以用 /usage 的 attribution 看到 subagents 佔了多少比例。

寫在最後：貴的不是模型，是你沒在看的那個乘號

我那天最大的誤判，其實不是選錯模型，而是把三個乘數當成三個獨立的選項。模型選最強的、思考開最深的、並行開到自動——每一個單獨看都很合理，乘起來就變成一天燒光一週。

而且最諷刺的是，我以為自己在節制。「不開 ultracode，只開 max 思考」聽起來像是保守派的做法，實際上 max 是官方定義裡「沒有 token 花費上限」的那一檔，而且在 Fable 5.1 上還可能把同一份東西寫兩遍。直覺在這件事上完全不可靠，因為每一層都是乘法，而人腦習慣用加法估算。

如果你今天只做一件事，我建議是最後那個：打開 /usage 按 w，看看 subagents 那一格佔了多少。那個數字會告訴你，你的額度到底是被工作吃掉的，還是被設定吃掉的。

喜歡這種把官方文件翻到底、再用自己的帳單驗證一次的拆解，可以到我整理的 Claude Code 常見問題總表看看還有哪些坑我先幫你踩過了——成本失控只是其中一類。

參考資料

以下是文中引用的原始出處，列英文原文版方便你比對引用原句。Anthropic 說明中心與 Claude Code 文件都有繁體中文版，把網址裡的 /en/ 換成 /zh-TW/ 就能切換。

 

延伸閱讀