OpenRouter Batch API: Lohnt sich der 50-Prozent-Rabatt trotz Wartezeit?

Eine API zum halben Preis klingt verlockend – bis das Ergebnis nach Ablauf der Deadline eintrifft. Die Batch API von OpenRouter eignet sich gut für Offline-Aufgaben mit Texten und Embeddings, nicht aber für interaktive Anfragen: Sie arbeitet asynchron, sieht ein Abschlussfenster von 24 Stunden vor und der beworbene Rabatt gilt nicht automatisch für jeden Kostenbestandteil.

Die Kaufentscheidung in einem Satz

Nutze die OpenRouter Batch API für Labeling, Evaluierungen, Embeddings, die Zusammenfassung von Rückständen und andere langlebige Jobs, die warten können. Nutzer-Chat, IDE-Agenten, Websuche und multimodale Anfragen bleiben besser auf der synchronen API.

OpenRouter zufolge liegen die Tokenpreise im Batch-Betrieb bei mehr als 70 Modellen normalerweise rund 50 % unter den regulären Preisen. Das formale Abschlussfenster beträgt 24 Stunden. In der Ankündigung zum Start meldete OpenRouter während der Beta eine mediane Laufzeit von 7 Minuten; 90 % der Jobs wurden innerhalb einer Stunde abgeschlossen. Das sind Beobachtungswerte und kein SLA (offizielle Ankündigung).

Worauf sich der 50-Prozent-Rabatt tatsächlich bezieht

Der Rabatt gilt in erster Linie für die Tokenpreise des Modells. Eine pauschale Reduzierung aller Bestandteile der Inferenzrechnung ist damit nicht gemeint.

Der Kostenüberblick zum Batching von Will Cygan zeigt am Beispiel von Claude Sonnet 5, wie die Kosten für 10 Millionen Eingabe- und 2 Millionen Ausgabetokens von 40 $ bei synchroner Verarbeitung auf 20 $ im Batch-Betrieb sinken. Das ist eine modellspezifische Rechnung, kein allgemeingültiger Preis.

„Die Batch-Route wird exakt mit der Hälfte des Sync-Preises abgerechnet.“ – Will Cygan, Batching (LLM Inference)

Plane die Ersparnis nicht ein, bevor Provider und Modell geprüft sind. Ein echter Nutzer, @fogelmania, berichtete, dass ein Beta-Modell wegen eines anderen Providers im Batch-Betrieb teurer war als parallele synchrone Aufrufe: Beitrag von @fogelmania. Das ist ein Hinweis darauf, die tatsächlichen Kosten nach Abschluss zu kontrollieren – kein Beleg dafür, dass sich jedes Modell so verhält.

Ein Batch ist ein Job – kein schnellerer Endpoint

Die Ankündigung der OpenRouter Batch API und der Quickstart beschreiben einen Job-Workflow, keine sofort abgeschlossene Anfrage. Eine erfolgreiche Einreichung liefert den HTTP-Status 202 Accepted sowie eine Batch-ID mit dem Status validating. Der reguläre Lebenszyklus sieht so aus:

validating → in_progress → finalizing → completed

Weitere Endzustände sind failed, expired und cancelled. Dein Worker sollte die Batch-ID dauerhaft speichern und bis zu einem Endzustand pollen, statt eine interaktive Anfrage offen zu halten.

OpenRouter meldete mehr als 230.000 Beta-Batches, eine mediane Laufzeit von 7 Minuten und 90 % abgeschlossene Jobs innerhalb einer Stunde. Ein Test von @luismmolina kam am Starttag zeitweise auf 5–8 Minuten (Testbeitrag). Diese Beobachtungen ersetzen jedoch nicht die Planungsgrenze von 24 Stunden.

So sieht die Implementierung aus, ohne später alles umzubauen

Der aktuelle Quickstart verwendet ein eingebettetes JSON-Array namens requests und keinen Upload einer JSONL-Datei. Jede Zeile braucht eine eindeutige custom_id. Über diese ID lässt sich eine abgeschlossene Antwort oder ein Fehler dem ursprünglichen Datensatz zuordnen.

Eine minimale Anfrage sieht so aus:

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

Der Quickstart dokumentiert POST https://openrouter.ai/api/beta/batches. Endpoint und Modell auf oberster Ebene gelten für den gesamten Batch. Unterschiedliche API-Formate oder Modelle erfordern deshalb separate Batches. Unterstützt werden Chat Completions, Responses, Anthropic Messages und Embeddings.

Nach dem Absenden fragst du GET https://openrouter.ai/api/beta/batches/:id regelmäßig ab. Ein abgeschlossener Batch liefert die Ergebnisse inline zurück. Jede Zeile enthält entweder eine response oder einen error; über request_counts lassen sich die Gesamtzahl sowie abgeschlossene und fehlgeschlagene Zeilen unterscheiden. Wiederhole nur die fehlgeschlagenen Zeilen anhand ihrer custom_id – nicht automatisch den gesamten Batch.

Wenn das Provider-Verhalten für Datenschutz, BYOK oder Assets per URL relevant ist, solltest du den Provider mit den dokumentierten Provider-Einstellungen festlegen, statt dich auf das Routing zum günstigsten Provider zu verlassen. Prüfe vor dem Rollout, ob das ausgewählte Modell und der Provider tatsächlich einen geeigneten Batch-Weg anbieten.

Hier gerät Batch an seine Grenzen

Die Einschränkungen des Quickstarts machen Batch zu einem textorientierten Workflow. Bilder, Audio, Video und Dateiinhalte in Batch-Anfragen werden abgewiesen. Auch Base64-Assets und data:-URIs sind nicht erlaubt; welche Assets per URL funktionieren, hängt vom Provider ab. Openrouters eigenes Websuch-Plugin steht in Batch nicht zur Verfügung.

Nutze die synchrone API, wenn ein Nutzer auf die Antwort wartet, ein Modell einen lokalen Upload analysieren muss, Audio oder Video erforderlich sind oder die Anwendung eine Antwortzeit im Sekundenbereich verspricht.

Kostenbeispiel: Wann die Ersparnis tatsächlich greift

Nehmen wir 10.000 Support-Tickets an, die jeweils 1.000 Eingabetokens und 200 Ausgabetokens benötigen. Das ergibt 10 Millionen Eingabe- und 2 Millionen Ausgabetokens.

Die nominelle Ersparnis beträgt 20 $ pro Durchlauf – oder 1.040 $ im Jahr, wenn dieses Beispiel wöchentlich ausgeführt wird. Tatsächlich fällt die Ersparnis geringer aus, sobald Wiederherstellung, Monitoring oder ein Notfall-Fallback über die synchrone API mehr kostet als die nominelle Differenz.

Diese Reserve gehört in die Entscheidung. Ist eine Deadline verbindlich, musst du das 24-Stunden-Fenster gegen die verbleibende Zeit für einen Lauf mit reduziertem Umfang oder einen synchronen Fallback abwägen. Ein Batch, der pro Token günstiger ist, aber nach Ablauf der Deadline nicht mehr nutzbar ist, spart diesem Geschäftsprozess kein Geld.

FAQ

Ist die OpenRouter Batch API immer halb so teuer?

Nein. OpenRouter beschreibt den Rabatt als typisch und modellabhängig. Websuchanfragen werden weiterhin regulär berechnet, Caching variiert, und bei BYOK sind Providerkosten für die Inferenz von den OpenRouter-Gebühren getrennt.

Wie lange dauert ein OpenRouter-Batch?

Das vorgesehene Abschlussfenster beträgt 24 Stunden. Die Beta-Werte zur Laufzeit sind hilfreiche Anhaltspunkte, aber keine garantierte Servicequalität.

Kann ich JSONL hochladen oder Modelle mischen?

Der Quickstart akzeptiert ein eingebettetes JSON-Array requests. Modell und API-Format gelten für den gesamten Batch. Für unterschiedliche Modelle oder Endpoint-Formate sind daher separate Batches erforderlich.

Kann ich nur fehlgeschlagene Zeilen wiederholen?

Ja. Liefert ein abgeschlossener Batch Fehler auf Zeilenebene zurück, kannst du anhand der jeweiligen custom_id einen kleineren Retry-Batch erstellen. Einen Batch-Fehler, das Ablaufen oder den Abbruch eines Batches solltest du separat behandeln, da Ergebnisse dann möglicherweise nicht verfügbar sind.

Sollte ich Batch oder die synchrone API verwenden?

Batch eignet sich für nicht dringende Hintergrundverarbeitung. Synchrone Inferenz ist die bessere Wahl, wenn das Ergebnis Teil einer aktiven Nutzerinteraktion ist oder nicht unterstützte Modalitäten und Tools benötigt werden.

Die praktische Empfehlung: Batch gezielt einsetzen

Prüfe vor der Umstellung eines Workloads fünf Punkte:

1. Auf der Modellseite ist ein geeigneter Batch-Weg mit dem erwarteten Provider ausgewiesen.
2. Der Geschäftsprozess kann das vollständige 24-Stunden-Fenster verkraften.
3. Jede Zeile besitzt eine stabile custom_id und einen Plan für Wiederholungen.
4. Die Anwendung protokolliert die tatsächlich abgeschlossene Nutzung und die Kosten.
5. Für Eingaben und Ergebnisse gibt es Verantwortliche sowie eine Löschrichtlinie.

Laut Openrouters Quickstart werden Batch-Eingaben und -Ergebnisse 30 Tage gespeichert, sofern sie nicht früher gelöscht werden. Lösche abgeschlossene Batches, sobald die Artefakte nicht mehr benötigt werden.

Die beste erste Migration ist ein eingefrorener, überprüfbarer Datenbestand – kein kundennaher Prozess, bei dem eine verspätete Antwort mehr kostet, als der Tokenrabatt einspart.