OpenRouter Batch API 定價：省 50%，值得等嗎？

API 費用直接打五折當然誘人，但如果結果在截止時間後才送達，省下的錢可能毫無意義。OpenRouter Batch API 很適合離線處理文字與 embedding 工作，卻不適合互動式請求：它採非同步執行、最長完成窗口為 24 小時，而且宣稱的折扣並不會同樣套用到帳單上的每一項費用。

先講結論：哪些工作該用 Batch

標註、評測、embedding、待辦內容摘要等可等待、可重跑的背景工作，很適合交給 OpenRouter Batch API。面向使用者的聊天、IDE agent、網頁搜尋流程，以及多模態請求，則應繼續使用同步 API。

OpenRouter 表示，Batch 在超過 70 個模型上通常可提供約 50% 較低的每 token 定價；正式承諾的完成窗口為 24 小時。OpenRouter 在產品發布公告中提到，beta 期間的中位完成時間為 7 分鐘，90% 的工作會在一小時內完成；不過這些只是觀察數據，並不是 SLA（官方公告）。

50% 折扣到底折了哪些費用？

折扣主要針對模型的 token 計費，並不代表整筆推論帳單的所有項目都會半價。

Will Cygan 的批次處理成本拆解以 Claude Sonnet 5 為例：1,000 萬輸入 token 加上 200 萬輸出 token，同步呼叫成本從 $40 降至 batch 的 $20。這是特定模型的計算案例，並不是通用報價。

「batch 路徑的計費恰好是同步費率的一半。」—— Will Cygan，Batching (LLM Inference)

在確認供應商與模型之前，不要先把節省金額編進預算。使用者 @fogelmania 曾回報，某個 beta 模型的 batch 成本反而高於同時發出的同步呼叫，原因是 batch 流量被送往不同供應商：@fogelmania 的貼文。這個案例提醒我們要檢查實際完成後的費用，而非證明所有模型都會如此。

Batch 是背景工作，不是更快的 API endpoint

OpenRouter 的Batch API 發布公告與快速入門都將它描述為工作任務流程，而不是立即回傳結果的呼叫。提交成功後，服務會回應 HTTP 202 Accepted，並附上狀態為 validating 的 batch ID。正常的生命週期如下：

validating → in_progress → finalizing → completed

其他終態則包括 failed、expired 與 cancelled。你的 worker 應保存 batch ID，並持續輪詢到進入終態，而不是讓一條互動式請求一路保持開啟。

OpenRouter 表示 beta 期間已處理超過 230,000 個 batch，中位完成時間為 7 分鐘，90% 在一小時內完成。使用者 @luismmolina 也曾在產品發布當天測得某個時間點約 5–8 分鐘完成（測試貼文）；但這些觀察結果都不能取代規劃時必須遵守的 24 小時界線。

能減少返工的實作方式

目前的快速入門採用內嵌 JSON requests 陣列，不是上傳 JSONL 檔案。每一列都必須有唯一的 custom_id，用來將完成的回答或錯誤對應回原始資料。

最精簡的請求格式如下：

{
  "endpoint": "/v1/chat/completions",
  "model": "openai/gpt-4o",
  "requests": [
    {
      "custom_id": "ticket-0001",
      "body": {
        "messages": [
          {"role": "user", "content": "Classify this ticket: ..."}
        ]
      }
    }
  ]
}

快速入門文件指定使用 POST https://openrouter.ai/api/beta/batches。頂層的 endpoint 與 model 會套用至整個 batch，因此不同 API 格式或不同模型都必須拆成不同 batch。支援的格式包括 Chat Completions、Responses、Anthropic Messages 與 Embeddings。

提交後，透過 GET https://openrouter.ai/api/beta/batches/:id 輪詢狀態。完成的 batch 會直接回傳結果；每一筆結果都包含 response 或 error，而 request_counts 會分別列出總筆數、完成筆數與失敗筆數。請依 custom_id 重試失敗列，不要自動重送整個 batch。

若供應商行為會影響資料政策、BYOK 或 URL 資產，應使用文件定義的供應商控制項來固定供應商，而不是依賴最低價供應商路由。部署前也要確認所選模型與供應商確實提供可用的 batch 路徑。

哪些需求會讓 Batch 不適用

快速入門中的限制顯示，Batch 是以文字為主的工作流程。Batch 請求會拒絕圖片、音訊、影片與檔案 content part；Base64 與 data: URI 資產同樣不支援，至於 URL 資產是否可用則取決於供應商。OpenRouter 自家的網頁搜尋 plugin 也無法在 Batch 中使用。

若使用者正在等待、模型需要讀取本機上傳檔、請求包含音訊或影片，或應用程式需要秒級回應時間目標，就應使用同步 API。

成本試算：折扣何時真的有意義

假設要處理 10,000 張客服工單，每張使用 1,000 個輸入 token 與 200 個輸出 token，合計為 1,000 萬輸入 token 與 200 萬輸出 token。

名目上，每次執行可省下 $20；若每週執行一次，全年可省 $1,040。但只要失敗復原、監控，或緊急改走同步 fallback 的成本超過這個差額，實際節省金額就會縮水。

做決策時應預留這類成本。如果截止時間不能延誤，就要把 24 小時窗口與「縮小範圍重跑」或「改走同步 fallback」所需的剩餘時間一併比較。單一 token 雖然較便宜、卻在期限後才拿到結果的 batch，對該業務流程而言並不是真的更便宜。

常見問題

OpenRouter Batch API 一定是半價嗎？

不一定。OpenRouter 將折扣描述為通常適用，且會因模型而異。網頁搜尋仍按標準費率計價，快取費用視模型而定，而 BYOK 會將供應商推論成本與 OpenRouter 費用分開計算。

OpenRouter batch 要跑多久？

支援的完成窗口為 24 小時。beta 期間的時間統計可作為參考背景，但不是保證的服務等級。

可以上傳 JSONL 或在同一批混用模型嗎？

快速入門接受內嵌 JSON requests 陣列。模型與 API 格式會套用到整個 batch，因此不同模型或 endpoint 格式必須建立個別 batch。

我可以只重試失敗的列嗎？

可以。若完成的 batch 回傳列級錯誤，可用每列的 custom_id 建立較小的重試 batch。不過 batch 整體失敗、過期或取消時要另外處理，因為結果可能無法取得。

我該用 Batch 還是同步 API？

不急迫的背景工作適合 Batch；若結果屬於進行中的使用者互動，或需要不支援的多模態與工具，請選擇同步推論。

實務建議：有選擇地導入 Batch

將工作負載移轉前，先確認以下五件事：

1. 模型頁面顯示可用的 batch 路徑，以及預期使用的供應商。
2. 業務流程能承受完整的 24 小時窗口。
3. 每一列都有穩定的 custom_id 與重試計畫。
4. 應用程式會記錄實際完成的用量與成本。
5. 輸入與結果都有負責人及清理政策。

OpenRouter 的快速入門指出，除非提前刪除，batch 輸入與結果會保留 30 天。當這些產物不再需要時，請刪除已進入終態的 batch。

最適合作為第一波遷移的，是內容已固定、可供審查的資料集；不要先搬遷到面向客戶的流程，因為答案遲到所付出的代價，可能高過 token 折扣帶來的節省。