聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

第二階段走到這裡，我們講了計價結構（Day 2）、tokenizer 原理（Day 7、11）、快取與批次（Day 9、10）、長對話的成本累積（Day 12）。這些都是「怎麼讓每一筆花費更划算」的技巧。

今天要處理一個不一樣的問題：你怎麼知道自己正在花多少錢、還剩多少配額、什麼時候會被擋下來？

Day 6 結尾埋過一句話：「帳單超出預期時，先確認錢花在哪。」今天就是兌現這句話——把 Claude 的用量管理，從「月底看帳單嚇一跳」，變成一個你能主動監控、事先設好防線的系統。

本篇關於用量層級、費用上限、rate limit 標頭的規格，對照 Rate limits 官方文件 查證。

目錄

一、兩種上限，先搞清楚差在哪

官方文件把限制分成兩種，很多人會混著講，但它們管的是不同的事：

• Spend limits（費用上限）：組織每個月最多能在 API 上花多少錢。
• Rate limits（速率限制）：組織在特定時間內最多能發出多少請求。

費用上限依你的用量層級（usage tier）而定：

超過這個上限，API 用量會暫停到下個月，除非你申請調高限制。你也可以在自己的層級上限之下，自訂更低的費用上限來做更保守的控制——這個設定在 Console 的 Billing 頁面。

二、用量層級：新帳號從哪裡開始、怎麼升級

官方講得很明白：層級是自動判定的，根據你的用量歷史與帳號狀況，隨著你持續使用 API，會自動往更高的層級移動。

新帳號或用量歷史還很少的組織，會先落在 Evaluation 層級，限制比 Start/Build/Scale 這幾個標準層級都低——這是官方用來防止濫用與詐騙的機制，隨著帳號累積使用歷史會自動提升。

如果標準層級的限制不夠用，可以在 Console 的 Rate limits 頁面申請調高；急件也可以直接聯繫官方支援。

三、Rate limits 的三個計量單位：RPM、ITPM、OTPM

Messages API 的速率限制用三個指標衡量，依模型類別分別計算：

• RPM：每分鐘請求數
• ITPM：每分鐘輸入 token 數
• OTPM：每分鐘輸出 token 數

超過任何一項，會收到 429 錯誤，回應裡的 retry-after 標頭會告訴你該等多久再重試。

有一個對快取使用者非常有利的規則，很容易被忽略：多數模型的 ITPM，只計算「未命中快取」的 input token。

官方原文：

"For most Claude models, only uncached input tokens count toward your ITPM rate limits."

具體拆解各欄位是否計入 ITPM：

官方舉的例子很直白：如果你的 ITPM 上限是 200 萬，快取命中率 80%，你實際上每分鐘能處理的總 input token 量可以到 1000 萬（200 萬未快取 + 800 萬走快取，快取的部分不佔用額度）。這代表 Day 9 的快取策略，不只省錢，還能實質拉高你的有效吞吐量——不用申請更高的 rate limit，光靠提高快取命中率就能達到類似效果。

（有個例外：Claude Haiku 3.5（已退役機型，僅 Bedrock / Google Cloud 保留）的 cache_read_input_tokens 會計入 ITPM，這是唯一的特例。）

OTPM 則是即時依實際產生的輸出 token 計算，max_tokens 這個參數本身不影響 OTPM 額度計算——也就是說，把 max_tokens 設高一點，不會對你的 rate limit 造成任何額外負擔，這也呼應了 Day 5 提過的：max_tokens 應該當保險絲用，不用怕設太高。

四、標準層級的實際數字（節錄）

以 Opus 5 為例，三個標準層級的差異：

（完整的各模型對照表請查官方 Rate limits 頁面，每個模型類別的數字不同，且部分舊世代模型的額度是跨版本共用的合併額度。）

Batch API 的速率限制是獨立的一組，跟 Messages API 分開計算——用批次不會侵蝕你即時呼叫的額度，反之亦然。這也是 Day 10 沒展開的一個細節：批次除了折扣，還有自己專屬的吞吐量配額。

五、怎麼監控：Console 的 Usage 頁面與回應標頭

① Console 的 Usage 頁面：提供兩張獨立的速率限制圖表——Input Tokens 和 Output Tokens——各自顯示每小時最高用量、目前的額度上限，以及（針對 input）快取命中率。官方明講這個頁面就是拿來「看你還有多少成長空間、什麼時候接近尖峰、該申請多高的額度、以及怎麼調整快取策略」的工具。

② 每次 API 回應都帶著即時額度資訊，透過標頭回傳：

這些標頭在每一次呼叫都會回傳，代表你可以把「檢查剩餘額度」直接內建在你的應用程式邏輯裡，而不需要另外呼叫一支查詢 API：

response = client.messages.with_raw_response.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
)

remaining_input = response.headers.get("anthropic-ratelimit-input-tokens-remaining")
remaining_output = response.headers.get("anthropic-ratelimit-output-tokens-remaining")

if int(remaining_input) < 100_000:
    alert_team("Input token 額度即將見底")

③ Rate Limits API：如果你想用程式化的方式讀取組織與各 Workspace 目前設定的限制（而不是等回應標頭），官方也提供了專門的端點可以查詢。

六、Before / After：從「月底才知道」到「即時預警」

❌ Before：完全不監控，等帳單信來才知道

def call_claude(prompt):
    return client.messages.create(
        model="claude-opus-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    )
# 沒有任何地方在追蹤用量，直到月底收到帳單才知道花了多少

✅ After：把回應標頭接進監控，設好預警門檻

def call_claude(prompt):
    response = client.messages.with_raw_response.create(
        model="claude-opus-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": prompt}],
    )

    remaining = int(response.headers.get("anthropic-ratelimit-input-tokens-remaining", 0))
    limit = int(response.headers.get("anthropic-ratelimit-input-tokens-limit", 1))

    if remaining / limit < 0.2:   # 剩餘額度低於 20%
        send_alert(f"ITPM 額度僅剩 {remaining}/{limit}")

    return response.parse()

Before 版本的問題不是「一定會出事」——多數時候一切正常。它的問題是出事的時候你毫無準備，可能是流量突然暴增撞上 rate limit，也可能是某個功能悄悄把成本推高，等你發現時已經是下個月的帳單。After 版本只是把官方本來就免費提供的標頭資訊，接進你自己的告警系統——不需要額外的 API 呼叫，純粹是把已經有的資料用起來。

七、不寫程式的人：/usage 跟 /insights

前面六節都在講 API 的 usage 欄位、rate limit 標頭、Console 儀表板。但如果你是訂閱制使用者、平常在 Claude Code 裡工作——你有一組更直接的工具，而且不用寫任何程式。

/usage：這個 session 花了多少

執行 /usage，最上面的 Session 區塊會顯示這次 session 的詳細用量，依模型拆分：

Total cost:            $0.55
Total duration (API):  6m 20s
Total duration (wall): 6h 33m 10s
Usage by model:
   claude-sonnet-4-6:  1.2k input, 5.3k output, 940.0k cache read, 50.0k cache write ($0.55)

注意那個 cache read 數字——這就是 Day 9 講的快取在幫你省錢的實際證據。如果 cache read 遠大於 cache write，代表快取運作良好；如果 write 一直居高不下，代表有東西在反覆打斷你的前綴。

一個給訂閱制使用者的但書：官方明講 Session 區塊的金額是給 API 使用者看的，Pro／Max 訂閱者的用量已包含在訂閱裡，這個金額不代表你的實際帳單。它是用標準價在本機換算的，不反映促銷價或合約折扣。

訂閱制專屬：額度花在哪裡的分項統計

如果你是 Pro／Max／Team／Enterprise 方案，/usage 還會多顯示一段額度分項，這是我覺得最實用的部分：

• 歸因（Attribution）：最近的用量依 skill、subagent、外掛、個別 MCP 伺服器拆分，各自佔總量的百分比。這能直接告訴你是哪一個 MCP 伺服器在吃你的額度，比憑印象猜準確得多。
• 行為標記（Behavior flags）：當某個行為佔了最近用量的 10% 以上時會被標記出來，例如「long context」（對話太長）或「cache misses」（快取一直沒命中）。

按 d 或 w 可以在「最近 24 小時」與「最近 7 天」之間切換。

這個「行為標記」機制，等於官方幫你做了本篇第五節那套告警邏輯——API 使用者要自己讀標頭、自己設門檻，訂閱使用者則是系統主動告訴你「你這週有 15% 的用量花在快取沒命中上」。

/insights：你是怎麼工作的

/insights 分析的角度不同——它不看「花了多少 token」，看的是你平常怎麼用：常見的摩擦點（指令被誤解、產生有 bug 的程式碼）、以及可以更有效率的建議。報告會寫成 HTML 存在本機，適合每隔一段時間跑一次。

一次分析最多涵蓋 200 個尚未看過的 session，太短的會跳過。任何方案、任何供應商都能跑，但要注意它本身也會消耗 token（透過你現在用的同一個帳號）。

八、把三道防線串起來：一份可以照抄的設定清單

前面六節分別講了費用上限、用量層級、rate limit 的三個指標、以及監控管道。實務上這些東西該怎麼一次設好，而不是東拼西湊？給一份可以照抄的順序：

第一步，設自訂費用上限，比你的層級上限低一截。 如果你的組織在 Build 層級（上限 $1,000），不要等到真的花滿 $1,000 才有感覺——在 Billing 頁面把自訂上限設在你能接受的「意外情境最大損失」，例如 $600，留一段緩衝讓你有時間反應。

第二步，決定你的預警門檻，而不是只設「到頂才擋」的硬上限。 Rate limit 的硬上限（撞到才會收到 429）跟你想要的「提早收到警訊」是兩回事。用第五節示範的程式碼邏輯，在剩餘額度低於某個比例（例如 20%）時就先發告警，而不是等真的被 429 擋下來才知道。

第三步，把快取命中率排進你定期會看的指標。 因為 Day 9 講過快取命中不太計入 ITPM，命中率下降不只讓你多花錢，還會讓你更容易撞到速率限制。Console 的 Usage 頁面本身就有這張圖，養成習慣定期看一次，比事後回頭查原因有效率得多。

第四步，區分「即時呼叫」與「批次呼叫」的監控。 Day 10 提過批次有自己獨立的速率限制，如果你的系統同時有即時互動與批次任務，兩邊的額度不會互相排擠，但也代表你需要分開監控，不能只看一個總量儀表板就以為涵蓋了全部。

這四步沒有一步需要額外的付費工具——全部建立在官方免費提供的標頭、Console 頁面與費用設定介面上，差別只在於「有沒有花時間把它們串起來」。

本篇自我挑戰

• 今日挑戰：找一支你正在使用的 Claude API 呼叫，加上讀取 anthropic-ratelimit-input-tokens-remaining 的邏輯，印出目前剩餘額度的百分比。如果你是網頁版使用者，去 Console 的 Usage 頁面看一次快取命中率圖表——這是你目前完全沒注意過的指標。

• 反思：多數人管理成本的方式是「先做，事後看帳單反省」。今天講的機制讓你可以「邊做邊看」，甚至「做之前先防」。你在其他系統（雲端資源、訂閱服務）上，有沒有類似「應該設預警但一直沒設」的地方？是什麼原因讓你一直拖著沒做？

總結

用量監控不是為了在出事之後追查原因，是為了在出事之前就先知道。今天釐清了三層防線：費用上限（Spend limits）是最後一道硬防線，超過就直接暫停；速率限制（RPM/ITPM/OTPM）是短期的流量閘門，撞到會收到 429 但有 retry-after 可以重試；回應標頭與 Console 儀表板則是讓你在撞到限制之前，就能主動觀察趨勢。

今天最值得記住的一個細節：快取命中的 token 多數不計入 ITPM——這代表 Day 9 學到的快取策略，除了省錢，還在幫你的有效吞吐量默默加分。把這件事跟 Rate Limits 一起看，你會發現前面幾天的技巧其實環環相扣，不是七個獨立的招式。

本日關鍵字回顧

• Spend limits vs Rate limits：前者是每月最高花費，後者是單位時間內的最高請求／token 數。
• Evaluation 層級：新組織或用量歷史不足時的起始層級，額度低於標準的 Start/Build/Scale，會隨用量歷史自動提升。
• RPM / ITPM / OTPM：速率限制的三個獨立計量單位，依模型類別分別計算。
• Cache-aware ITPM：多數模型的快取命中 token（cache_read_input_tokens）不計入 ITPM 額度，是拉高有效吞吐量的關鍵細節。
• anthropic-ratelimit-* 標頭：每次 API 回應都附帶的即時額度資訊，可直接用於自建監控告警。
• /usage 的額度歸因：訂閱制可看到用量依 skill、subagent、外掛、個別 MCP 伺服器拆分的佔比，並在單一行為佔比超過 10% 時自動標記（如 long context、cache misses）。

第二階段到這裡告一段落。七天下來，我們把「省 token」從一句口號拆成了七個可操作的維度：token 本身怎麼算、五個立即可用的習慣、快取、批次、tokenizer 換代、長對話陷阱、以及今天的監控機制。

明天進入第三階段——設定與調校。第一站是那個貫穿全系列、卻始終沒有完整展開的參數：effort。五個檔位到底該怎麼選，什麼時候該調、什麼時候不該調。

Day 14，effort 參數完整攻略。