Batch API 的 50% 折扣是怎麼算的，有沒有什麼例外？
折扣適用於標準定價的輸入和輸出 token，都是打五折。例如，如果 Claude Sonnet 的標準輸入定價是每百萬 token $3，Batch API 的輸入定價就是 $1.5；輸出同理。
需要注意的例外是 prompt caching（提示詞快取）。如果你同時使用 Batch API 和 prompt caching，快取 token 的定價邏輯會更複雜，需要查閱當前的官方定價頁面確認細節。另外，不同模型的原始定價不同，50% 折扣是一致的，但絕對金額取決於你用的是哪個模型。對於大量使用的場景，在部署前先用小規模測試估算實際費用，比只靠定價頁面的數字更準確。
我要怎麼知道我的 Batch 任務做完了？
有兩種方式。第一種是輪詢（polling）：用你收到的 batch_id 定期呼叫狀態查詢端點，它會回傳目前的狀態（in_progress、ended、canceling 等）以及已完成的請求數量。你可以設定一個迴圈，每幾分鐘到每小時查一次，取決於你的任務規模。
第二種是 webhook（如果你有自己的伺服器）：在送出 Batch 時指定一個 webhook URL，Anthropic 會在任務完成時主動呼叫你的端點，不需要輪詢。對於生產環境的自動化流程，webhook 通常更乾淨；對於腳本式的一次性任務，輪詢更簡單。兩種方式最後都是下載 JSONL 格式的結果檔案。
Batch API 有沒有什麼我可能沒想到的使用情境？
最常被忽略但很有價值的用途是自動化評測（eval）。如果你在開發 AI 產品，你需要評估模型輸出的品質——這通常意味著讓 Claude 評估另一組 Claude 的輸出（LLM-as-judge 模式）。這類任務通常需要跑幾百到幾千個評估樣本，完全適合 Batch API，而且因為打了五折，讓你可以跑更大規模的評測而不用擔心費用。
另一個常被忽略的是知識庫建構：把你的公司文件、FAQ、產品說明批次轉換成結構化格式，或者預先生成 embedding 的原始資料。這些任務不需要即時，但在 RAG 系統設計裡是很關鍵的前置步驟，用 Batch API 做成本效益最高。
進階：Batch API 有沒有可以同時搭配 prompt caching 的最佳做法？
可以同時使用，但要理解兩者的組合邏輯。Prompt caching 讓你在多個請求中重複使用相同的長前綴（例如一份很長的系統提示詞），第一次算全價、後續呼叫快取的部分只算一小部分費用。Batch API 在此基礎上再打五折。
最有效的組合是：你有一批請求，它們都共享一個很長的系統提示詞或前置文件，但每個請求的用戶輸入不同。在這種情況下，把那份長文件放進可快取的前綴，再用 Batch API 批量送出所有請求，兩個折扣疊加，可以讓長前綴的 token 成本壓到非常低。要注意的是：Batch API 裡的 prompt caching 行為和即時 API 可能略有不同，需要測試實際的快取命中率來確認費用是否符合預期。
如果你在用 Claude API 做批量處理的任務——評估大量資料、標注訓練集、批次生成內容——你可能正在為不需要付的錢付帳。Anthropic 的 Batch API 讓這類任務的 token 費用直接打五折，代價是你要等最多 24 小時才拿到結果。這篇文章說清楚它怎麼用、什麼時候值得用、以及你需要注意的幾個地方。
一般的 Claude API（即時 API）是「送一個請求、等幾秒、拿到一個回應」的即時模式。Batch API 則是「一次送幾百到幾萬個請求、讓系統在閒置時間處理、24 小時內給你全部結果」的非同步模式。
兩者的本質差別是時間換金錢。即時 API 讓你幾秒內拿到答案，但付完整的 token 費率。Batch API 讓 Anthropic 在他們方便的時候處理你的任務，作為交換，你拿到 50% 的折扣。目前 Batch API 的折扣是輸入 token 和輸出 token 都打五折。
判斷標準只有一個：這個任務有沒有時效性要求？ 如果沒有，Batch API 幾乎永遠是更划算的選擇。
最適合的場景是：資料集標注（你有一萬筆資料要讓 Claude 分類）、大規模內容評估（評估模型輸出品質、跑自動化評測）、批次文件處理（把幾百份合約摘要成結構化資料）、離線的內容生成（預先生成大量 FAQ 或產品描述）。這些任務有個共同點——你不需要每個結果在幾秒內到，你只需要它在今天或明天到。
不適合的場景是：任何用戶在等待的互動（聊天機器人、即時問答系統）、需要前一步結果才能決定下一步的串接任務、有嚴格截止時間（幾分鐘內）的任務。
使用 Batch API 分三步。第一步，把你的請求打包成 JSONL 格式——每一行是一個獨立的請求物件，包含你的 custom_id（自定義識別碼，方便你後來對應結果）和 API 請求參數。第二步，送出這個檔案給 Batch API 端點，它會回傳一個 batch_id。第三步，用 batch_id 輪詢狀態（或設定 webhook），等到狀態變成 ended，下載結果檔案。
結果同樣是 JSONL 格式，每一行對應一個請求，帶著你的 custom_id 和回應內容。所以你需要在發送時就把 custom_id 設計好，才能在收到結果時正確對應回去。
第一，24 小時是上限，不是保證。官方說明是「通常在一小時內完成，但最長可能到 24 小時」。如果你在跑時效性敏感的任務，不要把 Batch API 的完成時間算進你的關鍵路徑裡。
第二，Batch API 目前支援的模型和即時 API 相同，但並非所有功能都支援。工具使用（function calling）和視覺（vision）在 Batch API 裡是支援的；但一些更新的功能可能有延遲支援的情況，使用前確認一下官方文件。
第三，單一 Batch 有請求數量上限（目前是 100,000 個請求或 256MB，取先達到的為準）。如果你的任務超過這個數量，需要拆成多個 Batch 分批送出。
如果你現在有任何批量的 Claude API 用量，而且這些任務不需要即時回應，Batch API 可以讓你的 API 帳單直接砍半。你不需要改變任何模型或提示詞設計，只需要改變送出請求的方式。對於資料密集的 AI 應用來說，這通常是最快、最低工的成本優化手段。