聯繫我

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

• Email

前言

Day 9 講的快取，省錢的前提是「內容重複」。今天要講的 Batch API，省錢的邏輯完全不同——它不管你的內容重不重複，只問你一件事：這個任務，你願不願意晚一點拿到結果？

如果答案是「可以晚一點」，Batch API 直接把 input 和 output 通通打五折。不用重複內容、不用調整 prompt 結構，單純用「非即時」換「五折」。

這篇適合誰？如果你曾經需要一次處理成千上萬筆資料——幫一批客服工單分類、幫一堆文件產生摘要、跑大規模的模型評測——今天這篇就是為你寫的。如果你只是偶爾問幾個問題,這篇可以先收藏,等你真的有批量需求時再回來查。

本篇規格、折扣比例、限制條件，均於 2026 年 8 月對照 Batch processing 官方文件 查證。

目錄

一、運作方式：丟一整批進去，之後回來拿結果

Batch API 的流程跟平常呼叫 Messages API 完全不同，它是三個步驟：

1. 建立批次：把一整組請求打包送出，每個請求要帶一個獨一無二的 custom_id。
2. 非同步處理：系統獨立處理批次裡的每一筆請求，你不用等在那裡。
3. 輪詢狀態、取回結果：等 processing_status 變成 ended，就能下載結果。

from anthropic.types.message_create_params import MessageCreateParamsNonStreaming
from anthropic.types.messages.batch_create_params import Request

client = anthropic.Anthropic()

message_batch = client.messages.batches.create(
    requests=[
        Request(
            custom_id="ticket-001",
            params=MessageCreateParamsNonStreaming(
                model="claude-haiku-4-5-20251001",
                max_tokens=200,
                messages=[{"role": "user", "content": "將這則客服工單分類：..."}],
            ),
        ),
        Request(
            custom_id="ticket-002",
            params=MessageCreateParamsNonStreaming(
                model="claude-haiku-4-5-20251001",
                max_tokens=200,
                messages=[{"role": "user", "content": "將這則客服工單分類：..."}],
            ),
        ),
    ]
)

批次的規模上限：單一批次最多 100,000 筆請求或 256 MB，先達到哪個上限就以哪個為準。

二、時效：多數在 1 小時內完成，最長不超過 24 小時

官方明講：系統會盡快處理批次，多數批次在 1 小時內完成。 你可以在「所有請求都處理完」或「送出後滿 24 小時」這兩個條件中，先到者取得結果。

批次如果在 24 小時內沒處理完，會直接過期——過期的請求不會被處理，也不會被收費。除了過期，還有「使用者取消」的情況，取消前已處理的部分仍會保留結果，未處理的部分不收費。

結果保存期限是 建立後 29 天。過了這個期限，批次本身還查得到，但結果檔案就沒辦法下載了——如果你有留存需求，記得在這個時間窗內把結果搬到自己的儲存空間。

三、計價：全面打五折，可以跟快取疊加

批次的折扣很單純——不管 input 還是 output，一律是標準單價的一半：

（原價分別是 Opus 5 的 $5/$25、Sonnet 5 的 $2/$10、Haiku 4.5 的 $1/$5——五折之後正好是一半，換算方式跟 Day 2 的基準價一致。以上批次價格於 2026 年 8 月查證。）

更值得注意的是：Batch API 支援 Prompt Caching，而且兩種折扣可以疊加。 也就是說,同一段被快取命中的內容,先套用快取的 0.1 倍價,再套用批次的 5 折——理論上能壓到極低的成本。但要留意,因為批次請求是非同步、並行處理,快取命中屬於「盡力而為」,官方觀察到的命中率區間是 30% 到 98%,取決於你的流量模式。

想拉高批次情境下的快取命中率，官方給了三個建議：

1. 每一筆請求都用完全相同的 cache_control 結構——哪怕內容一樣，結構不一致也會找不到匹配。
2. 維持穩定的送出節奏，避免快取條目因為 5 分鐘 TTL 到期而失效（批次處理時間可能超過 5 分鐘，這時候該用 1 小時版本的快取）。
3. 盡量讓多筆請求共用最多的內容——結構設計上,把共用的系統提示、規則放在前面。

四、什麼東西不能放進批次

批次幾乎支援所有 Messages API 的功能——視覺輸入、工具使用（含 web search、code execution 等伺服器工具）、多輪對話、extended thinking，大部分 beta 功能都可以用。但有幾個參數會直接觸發驗證錯誤：

實務上的建議：先用一般的 Messages API 把單筆請求的格式驗證過，確定沒問題，再把同樣的結構包進批次。 批次的驗證是非同步的，如果格式錯了，你得等整批處理結束才會看到錯誤訊息——先驗證單筆，能省下大量除錯時間。

五、Before / After：客服工單分類的真實情境

❌ Before：一筆一筆即時呼叫，卡在 rate limit 也卡在錢

results = []
for ticket in all_tickets:  # 一萬筆工單
    response = client.messages.create(
        model="claude-haiku-4-5-20251001",
        max_tokens=200,
        messages=[{"role": "user", "content": f"分類這則工單：{ticket}"}],
    )
    results.append(response)
    # 一萬次即時呼叫，逐一排隊，還要處理 rate limit 重試

✅ After：包成一個批次，五折處理，不用管 rate limit 節奏

requests = [
    Request(
        custom_id=f"ticket-{i}",
        params=MessageCreateParamsNonStreaming(
            model="claude-haiku-4-5-20251001",
            max_tokens=200,
            messages=[{"role": "user", "content": f"分類這則工單：{ticket}"}],
        ),
    )
    for i, ticket in enumerate(all_tickets)
]

batch = client.messages.batches.create(requests=requests)
# 之後輪詢 batch.processing_status，等 "ended" 再拿結果

這正是官方文件本身用來說明計價的情境：一萬筆客服工單、平均每則對話約 3,700 token、用 Haiku 4.5 處理，即時價大約 37 美元——換成批次，同樣的工作直接砍半，而且不用擔心一萬次連續呼叫撞上 rate limit。

這裡的取捨很清楚：你换到的是省一半的錢和更高的吞吐量，付出的代價是「不能馬上拿到結果」。 如果這是客服系統即時要回覆使用者的工單分類，Batch API 就不適合；但如果是每天跑一次的批次分類作業，這正是它的主場。

六、什麼情況不該用 Batch API

批次不是所有場景的答案，官方文件本身也點出了幾個限制值得先知道：

① 批次是 Workspace 層級的。 你只能看到「你的 API key 所屬 Workspace」建立的批次與結果——如果你的組織有多個 Workspace，批次不會跨 Workspace 共享，規劃時要記得這一點。

② 高吞吐量可能小幅超出你設定的 Workspace 費用上限。 因為批次處理是高並行的，官方明講「可能會稍微超出你 Workspace 設定的費用限制」——如果你的費用控管很嚴格，這是需要納入緩衝的細節，不要把費用上限設在剛剛好的邊界上。

③ 需要即時互動的場景完全不適用。 這聽起來像廢話，但實務上容易在灰色地帶誤判——例如「使用者送出表單後，系統在背景處理，晚一點用 email 通知結果」這種場景，看起來可以接受延遲，但如果使用者期待的是「幾秒鐘內」而不是「一小時內」，批次的時效仍然不夠快，這時候該用的是即時呼叫加上 Day 9 的快取，而不是批次。

一個簡單的判斷句：如果你會因為「結果晚一小時才出來」而需要另外設計一套通知機制，那通常就適合批次；如果晚一小時會讓使用者卡在畫面前不知道發生什麼事，那就不適合。

七、結果怎麼讀：用 custom_id 對應，不要依賴順序

批次結果是 .jsonl 格式，每一行對應一筆請求的結果。官方特別提醒：結果的回傳順序不保證跟你送出的順序一致，一定要用你自己設定的 custom_id 去比對，不要假設第一筆結果對應第一筆請求。

結果分四種類型：

只有真正成功的請求才會被收費——這代表你不用擔心格式寫錯了還要付冤枉錢，但也代表你需要自己檢查 request_counts，確認有多少筆真的成功，而不是假設送出去的一定全部處理完。

八、一個具體的數字感：換算下來省多少

拿 Day 9 提過的那個官方情境延伸：一萬筆客服工單、平均每則對話約 3,700 token、用 Haiku 4.5 處理，即時價（標準單價）大約 37 美元。

把同樣的工作換算成三種處理方式，感受一下數量級的差異：

這三種選項不是互斥的，而是同一個任務的三種配置。決定用哪一種，回到本篇一直在強調的那個判斷句：你能不能接受晚一點拿到結果。 能，就往批次的方向靠；不能，那就用即時呼叫搭配 Day 9 的快取策略，把「重複的部分」的成本壓低。

本篇自我挑戰

• 今日挑戰：盤點你目前的 Claude 使用情境裡，有沒有「其實不需要馬上拿到結果」的重複性任務——批次打標籤、批次摘要、批次翻譯都算。如果有，估算一下把它改成 Batch API 之後，五折能省下多少錢，值不值得為此重構一次流程。

• 反思：Batch API 的核心取捨是「用等待時間換金錢」。你的團隊裡，有哪些任務其實一直被當成「即時任務」在做，但仔細想想根本不需要即時？為什麼會養成「什麼都要馬上跑」的習慣——是真的有時效需求，還是單純圖方便沒去想過?

總結

Batch API 的邏輯跟 Prompt Caching 完全不同軸線：快取靠「內容重複」省錢，批次靠「時間換金錢」省錢——兩者可以疊加，而且疊加時官方觀察到的快取命中率可以到 98%。

三個最重要的數字：五折（input 和 output 一致）、多數 1 小時內完成、最長 24 小時、結果保留 29 天。加上一個容易被忽略的細節：失敗、取消、過期的請求都不收費，你只為真正處理成功的部分付錢。

如果你的工作是大量、重複、不需要即時回應的任務，今天這篇就是那個「原來我一直在多付錢」的答案。

本日關鍵字回顧

• Message Batches API：非同步批次處理端點，input / output 均以標準價 5 折計費。
• custom_id：批次結果比對用的識別碼，結果回傳順序不保證與送出順序一致。
• 24 小時過期機制：批次未在 24 小時內處理完即過期，過期請求不收費。
• 快取 × 批次疊加：兩種折扣可同時套用，命中率因非同步並行處理呈「盡力而為」，區間 30%–98%。
• 不收費的三種結果：errored、canceled、expired 均不計費，只有 succeeded 才收費。

明天回到 Day 7 沒講完的伏筆——Claude 4.7 世代換了新的 tokenizer，同樣的中文內容，token 數變多了。這對已經在營運中的系統，實際衝擊有多大？

Day 11，新世代 tokenizer 對中文使用者的真實影響。