Claude Batch API für Übersetzungen: 50 % günstiger, aber es ist eine Queue

Für The Clinic Praha — eine Zahnklinik mit internationaler Patientenschaft aus Deutschland, Frankreich, Russland und dem arabischen Raum — haben wir eine Übersetzungspipeline gebaut. Die Website läuft in sechs Sprachen (Tschechisch als Quelle plus fünf Übersetzungen, inklusive RTL-Arabisch). Jeder Artikel, jede Dienstleistung und jede Behandlungsseite ist ein langer Text, typischerweise 2–5 k Tokens. Die Redakteurin ändert das Tschechische, und die Pipeline muss fünf Übersetzungen nachziehen.

Die erste Iteration war die synchrone Claude API. Fünf parallele Requests, warten, speichern. Funktionierte. Zwei Schmerzen zeigten sich: Kosten und Druck aufs Kontextfenster bei Artikeln mit langen FAQ-Sektionen, die an die Limits stießen.

Was die Batch API ist

Anthropic bietet die Messages Batches API. Sie reichen bis zu 10.000 Requests auf einmal als JSONL-Payload ein, bekommen eine batch_id zurück, Anthropic verarbeitet sie im Hintergrund (beworbenes SLA 24 Stunden, in der Praxis typischerweise Dutzende Minuten), und Sie holen die Ergebnisse ab, sobald sie fertig sind.

Preis: 50 % Rabatt auf Input- und Output-Tokens. Haken: Batch ist asynchron.

Ökonomie in der Praxis

Für einen typischen The-Clinic-Artikel (~4.000 Input-Tokens, ~4.000 Output-Tokens × 5 Zielsprachen) sieht die Rechnung so aus:

• Sync: 5× (4 k Input + 4 k Output) zum vollen Preis.
• Batch: dasselbe mit 50 % Rabatt → eine glatte 50 % Ersparnis.

Der eigentliche Trick ist die Kombination mit Prompt Caching. Alle fünf Calls teilen sich die gleiche tschechische Quelle; nur die Zielsprachen-Instruktion unterscheidet sich. Wenn Sie die Quelle cachen:

• 1× Cache Write (1,25× Preis der Input-Tokens)
• 4× Cache Read (0,1× Preis der Input-Tokens)
• + 50 % Batch-Rabatt obendrauf

Konkrete Auswirkung auf einen 4 k-Token-Artikel in fünf Sprachen: von rund $0,32 im Sync auf rund $0,07 mit Batch + Cache. Etwa 80 % günstiger als die naive Sync-Variante. Bei Dutzenden Artikeln pro Monat wird daraus ein realer Betriebsunterschied.

Arbeit mit der Queue — der Preis für den Rabatt

Sync ist Fire-and-forget. Batch verlangt einen ordentlichen Orchestrator. Was wir für The Clinic bauen mussten:

1. Persistenter Job-Status

Eine TranslationJob-Tabelle in der DB: batchId, status (PENDING, IN_PROGRESS, COMPLETED, FAILED), articleId, submittedAt, completedAt. Ohne das verlieren Sie den Überblick über alles, was gerade läuft, und ein Service-Restart zerlegt die ganze laufende Welle.

2. Polling oder Webhooks

Anthropic bietet beides. Für The Clinic pollen wir alle 60 Sekunden aus einem .NET-Hintergrundjob (IHostedService). Sicherheits-Timeout — jeder Job, der länger als 4 Stunden läuft, scheitert geschlossen und löst einen Alert aus. Das beworbene 24-Stunden-SLA ist der Worst Case; produktiv sieht man es selten, aber die Pipeline muss ihn aushalten.

3. Idempotenz und Versionskollisionen

Wenn die Redakteurin mitten in einem Batch auf „neu übersetzen“ klickt (typischerweise, weil sie einen Tippfehler in der Quelle entdeckt hat), muss der neue Batch entweder den vorherigen abbrechen oder sein Ergebnis verwerfen. Sonst werden frische Übersetzungen von alten überschrieben, die einfach zufällig später fertig geworden sind. Pragmatisch: Jeder Job trägt eine sourceVersion der Quelle, und wenn das Ergebnis zurückkommt, prüfen wir, ob sich die Quelle inzwischen weiterbewegt hat; wenn ja, wird das Ergebnis verworfen.

4. Partial Failures innerhalb eines Batches

Einer der fünf Requests kann scheitern — Rate Limit, Model Error, seltsamer Input. Anthropic liefert ein JSONL zurück, in dem jede Zeile ihren eigenen Status hat. Die Pipeline muss die erfolgreichen anwenden und die fehlgeschlagenen auf einen individuellen Retry schicken — üblicherweise über die Sync API, weil ein einzelner Rerun keinen weiteren Batch wert ist.

5. Status für die Redakteurin sichtbar

Das Admin-Portal beschriftet jeden Artikel mit „Übersetzung läuft“, „Übersetzung fertig“ oder „Übersetzung fehlgeschlagen: <Sprache>“. Ohne das versteht die Redakteurin nicht, warum der Artikel, den sie gerade veröffentlicht hat, für weitere Minuten (oder Stunden) nicht in der fremdsprachigen Variante auftaucht.

Wann Batch die falsche Wahl ist

• Dringlichkeit. Redakteurin hat gerade eine Dienstleistung angelegt und will sie sofort in allen Sprachen live haben. Sync, nicht Batch.
• Kleines Volumen. Ein paar Requests pro Tag. Der Orchestrierungs-Overhead ist die Ersparnis nicht wert. Sync.
• Striktes Latenz-SLA. Chat, Live-Assistent, interaktives Authoring. Batch ist unbrauchbar.

Das Hybrid-Muster, das bei uns funktioniert

Für The Clinic gilt: Redakteurin legt einen Artikel an oder ändert ihn substantiell → Batch-Job. Wenn jemand „dringend übersetzen“ für eine einzelne Sprache klickt (z. B. weil er schnell die deutsche Variante für eine Pressemitteilung braucht), geht der Request über die Sync API. 90 % des Traffics fließen durch Batch, 10 % durch Sync.

Dieser Split nimmt 100 % der Batch-Ersparnis mit und hält die Pipeline gleichzeitig reaktiv, wenn sie es sein muss.

Was zum Mitnehmen

Die Batch API ist kein funktionaler Sprung — sie ist eine Verschiebung in der Ökonomie. Jedes Workload im Stil „hohes Volumen, nicht dringlich“ ist ein Kandidat. Übersetzungen, Bulk-Zusammenfassungen, Klassifikation alter Inhalte, Metadaten-Generierung für tausende Items — alles passt.

Der Preis der Umstellung liegt in der Orchestrierung — grob ein bis zwei Engineer-Tage für einen sauberen Job-Layer, danach ist es wartbar. Für The Clinic hat es sich innerhalb des ersten Produktionsmonats amortisiert.