Am 22. September 2026 hat OpenRouter, die Aggregationsplattform für KI-Modell-APIs, im offiziellen Blog den Start der Batch API bekannt gegeben: Man bündelt eine Reihe von Anfragen und reicht sie gemeinsam ein – der Anbieter legt die Ausführung innerhalb eines 24-Stunden-Fensters selbst fest, und im Gegenzug sinkt der Preis in der Regel auf 50 % der Standard-Token-Preise, bei manchen Modellen sogar darunter. Zum Start werden über 70 Modelle unterstützt.
Was der halbe Preis kostet: Gewissheit
Der Kern-Deal der Batch API ist simpel: Man verzichtet auf „Ergebnis sofort", der Anbieter gewinnt die Freiheit, Off-Peak zu planen. Aufgerufen wird sie per POST einer Anfrageliste an api/v1/batches mit Angabe der Endpoint-Form – Chat Completions, Responses, Messages und Embeddings werden alle unterstützt. Nach dem Einreichen fragt man den Batch-Status ab, bis completed, failed, expired oder cancelled erreicht ist; die Ergebnisse kommen inline zurück.
Die Idee entspricht OpenAIs Batch API, doch OpenRouters Variante unterscheidet sich in zwei Punkten: Erstens wählt das Routing standardmäßig den „günstigsten Batch-Endpoint unter Allowlist, Datenrichtlinie und BYOK-Einstellungen", wobei ein Batch an einen einzigen Anbieter gebunden bleibt; zweitens werden die Ergebnisse jeder Anfrage unabhängig zurückgegeben, sodass ein paar fehlerhafte Zeilen nie den ganzen Job gefährden. Eingaben und Ergebnisse werden 30 Tage aufbewahrt und lassen sich jederzeit per DELETE löschen.
Zwei Wochen Beta-Daten: schneller als gedacht, aber die Uhrzeit zählt
OpenRouter veröffentlichte Daten aus über 230.000 Batches einer zweiwöchigen Beta: Der Median lag bei 7 Minuten bis zur Fertigstellung, 90 % waren innerhalb einer Stunde fertig. Man wartet also fast nie annähernd 24 Stunden.
Doch die Tageszeit spielt eine deutliche Rolle: Batches, die zwischen 5 Uhr morgens und mittags pazifischer Zeit eingereicht wurden, waren merklich langsamer – das langsamste Zehntel brauchte 2 bis 4,5 Stunden; zu anderen Zeiten sinkt das 90. Perzentil unter 1,1 Stunden, und nach 18 Uhr pazifischer Zeit unter 50 Minuten. Die Batch-Größe wirkt sich dagegen weniger aus: Batches mit über 1.000 Anfragen sind im Median in 12 bis 21 Minuten fertig.
Welche Workloads passen – und welche nicht
Passend: Korpus-Labeling, Embedding-Backfills, Eval-Set-Scoring, Aufarbeitung von Ticket-Rückständen, derselbe Prompt über tausende Datenzeilen – jede Workload, die „über Nacht warten kann".
Unpassend: Echtzeit-Chat, Aufgaben mit Audio- oder Video-Input (im Batch noch nicht unterstützt), Anfragen, die auf OpenRouters Websuche-Plugin angewiesen sind (Suchaufrufe werden zum Standardtarif abgerechnet, und das Plugin unterstützt kein Batching); Bild- und Datei-Inputs müssen öffentliche URLs sein.
Bedeutung für API-Kostenstrukturen
Die Batch API macht „Latenz" offiziell zu einer handelbaren Ware. Für Indie-Entwickler und kleine Teams bedeutet das: Evals und Datenverarbeitung, die früher zu teuer für große Läufe waren, haben nun einen offiziellen Kanal zum festen halben Preis. Der Preis ist eine Workflow-Umstellung: Einreichen – Abfragen – Ergebnisse einsammeln, statt des einen Request-Response-Roundtrips. Teams, die diese Umstellung mitgehen, halbieren ihre Inferenzrechnung direkt.
