LLM API Kosten-Vergleich 2026: Framework statt veralteter Tabelle

Jeder LLM API Kosten-Vergleich, den man online findet, hat dasselbe Problem: nach zwei Wochen ist er veraltet. Ein Provider dropped eine neue Stufe, ein anderer halbiert den Output-Preis, ein Reasoning-Modell kommt zum dreifachen Preis. Bis der Beitrag bei Google rankt, stimmen die Zahlen nicht mehr und das Ranking ist wertlos.

Dieser Beitrag ist deshalb keine Tabelle, die man einmal prüft. Er beschreibt das Framework, mit dem ich LLM-API-Pricing für eigene Production-Workloads modelliere, plus einen Snapshot der Listenpreise Stand April 2026, plus vier realistische Szenarien durch dieses Framework gerechnet. Die Szenarien sind der Punkt. Ihren eigenen Traffic einsetzen, Modell ändern, eine verteidigbare monatliche Kostenzahl rausbekommen.

Kurzes Fazit vorweg: Für die meisten DACH- und EU-Teams, die 2026 produktive KI-Arbeit ausliefern, ist der kosteneffiziente Default-Stack Haiku 4.5 für Klassifikation und Extraktion, Sonnet 4.6 für Agentic-Workloads mit Tool Use, und Opus 4.7 selektiv, wenn Reasoning-Qualität den Aufpreis rechtfertigt. GPT-4o-mini, Gemini Flash und DeepSeek V3 konkurrieren am unteren Ende aggressiv. o1/o3 und Claude Extended Thinking lohnen sich nur, wenn ein falscher Zwischenschritt echten Schaden verursacht.

Aktuelle Listenpreise (2026-04)

Nur Snapshot. Auf der Pricing-Seite des Providers gegenprüfen, bevor etwas ins Budget kommt. Die Preise verschieben sich quartalsweise.

Zwei Dinge fallen auf. Erstens: Output liegt fast immer bei dem 4- bis 5-fachen des Inputs im selben Modell. Dieses Verhältnis ist der größte einzelne Hebel auf Ihre monatliche Rechnung. Zweitens: der Spread zwischen günstigster und teuerster Stufe beträgt rund 200x. Das heißt, die Modellwahl dominiert jede andere Optimierung, die Sie machen können.

Für eine tiefere Tradeoff-Analyse der beiden Provider, die ich täglich nutze, siehe Claude API vs OpenAI für Business-Automation. Wer bereits auf OpenAI ist und einen Wechsel prüft, findet die praktischen Schritte in Von OpenAI zu Claude migrieren.

Die Kosten, die nicht in der Tabelle stehen

Der Listenpreis ist die Überschrift. Die Rechnung formt alles drumherum.

Batch-API-Rabatte. Die meisten Provider bieten 50 % Nachlass, wenn bis zu 24 Stunden Turnaround akzeptabel sind. Dokumentenverarbeitung, Embeddings, nächtliche Zusammenfassungen, Evaluations-Läufe: alles Kandidaten. Wer die Hälfte seines Volumens async fahren kann, halbiert die halbe Rechnung.

Enterprise-Commitments. Ab 5 Millionen Tokens täglich lassen sich 10 bis 30 % aushandeln, im Tausch gegen zugesagtes Spend. Das bindet an einen Provider, und Provider-Lock-in ist real. Nicht zu empfehlen, bevor der Workload mindestens ein Quartal stabil läuft.

Rate-Limits. Frontier-Modelle kommen mit engen Rate-Limits auf niedrigen Tiers. Wer mehr Durchsatz braucht, zahlt für eine höhere Stufe, was ein monatliches Minimum bedeuten kann, das auf der Token-Preisseite nirgends auftaucht.

Error-Retries. Fehlgeschlagene Calls kosten trotzdem. Timeouts, fehlerhafte JSON, die der Parser ablehnt, Tool-Call-Schleifen, 5xx-Fehler auf Provider-Seite. Ich multipliziere jede Schätzung mit Faktor 1,1 als Sicherheits-Reserve und liege trotzdem manchmal daneben.

Self-Hosting. GPU-Instanz-Kosten plus Personalzeit plus Observability plus die gelegentliche 3-Uhr-Nachts-Bereitschaft. Lohnt sich bei sehr hohem Volumen oder wenn Data Residency das Senden von Tokens zu einem US-Provider verbietet. Nicht lohnend für ein Wochenendprojekt. Aufgedröselt in Hetzner vs AWS für AI-Workloads.

Tokenizer-Eigenheiten. Verschiedene Tokenizer zählen denselben Text unterschiedlich. GPT-4os Tokenizer ist für englische Prosa rund 15 % effizienter als Claudes. Bei Deutsch, Code und langen strukturierten Daten wird die Lücke kleiner, manchmal dreht sie sich um. Die naive Aussage “wir sind zu Provider X gewechselt und sparen 20 %” ist oft 5 % echte Ersparnis plus 15 % Tokenizer-Differenz.

Prompt Caching verändert die Mathematik

Hier verlieren die “günstigste LLM API 2026”-Headlines den Faden. Caching strukturiert die Rechnung um.

Anthropic. Cache-Writes kosten das 1,25-fache der normalen Input-Rate. Cache-Reads das 0,1-fache. Standard-TTL sind 5 Minuten, es gibt eine längere Option. Für jeden Workload mit stabilem System-Prompt, festem Tool-Schema oder wiederkehrendem Dokument-Prefix sinken die Input-Kosten auf dem gecachten Anteil nach dem ersten Write um etwa 90 %. Das Production-Pattern beschreibe ich in Claude API Prompt Caching.

OpenAI. Automatisch 50 % Nachlass auf gecachte Inputs, keine Code-Änderung. Weniger Kontrolle, weniger Ersparnis, aber null Konfigurations-Overhead.

Gemini. Context Caching existiert mit eigener Preisstruktur. Rabatt ist kleiner als bei Anthropic und das Setup aufwendiger.

Wenn ein Workload einen 20k-Token-Prefix hat, der sich bei jedem Call wiederholt (langer System-Prompt, Tool-Katalog, Referenzdokument), und mehr als eine Handvoll Calls pro Minute läuft, kann Anthropic Caching die Entscheidung sein. Ich habe Agentic-Workloads gesehen, bei denen Caching Sonnet von 20 % teurer als GPT-4o auf 40 % günstiger gedreht hat.

Output-Tokens kosten mehr, als man denkt

Das schmutzige Geheimnis des LLM-API-Pricings: Output kostet das 4- bis 5-fache des Inputs auf Frontier-Stufen. Der Grund ist simpel: Output ist, wo die Rechenarbeit stattfindet. Jeder Output-Token ist ein voller Forward-Pass. Jeder Input-Token ist, sobald Caching greift, nahezu kostenlos.

Die Implikation ist direkt. Wenn Ihr Prompt geschwätzige Antworten ermutigt, zahlen Sie auf jedem Füllwort-Token den Aufpreis. Ich habe Production-Rechnungen um 30 % gesenkt, nur durch straffere Anweisungen: “Antworte in maximal 3 Stichpunkten. Keine Einleitung. Keine Zusammenfassung.” Output-Tokens sind das Erste, worauf ich bei einer Kosten-Regression schaue.

Beim Schema-Design für Structured Output gilt dieselbe Regel. Eine JSON-Antwort mit 20 Feldern, wenn Sie 5 brauchen, ist nicht nur unsauber, sie ist teuer.

Extended Thinking und Reasoning: für Qualität zahlen

Reasoning-Modelle (o1, o3, Claude mit aktiviertem Extended Thinking) erzeugen intermediäre Thinking-Tokens, die zum Output-Tarif abgerechnet werden. Ein einzelner Call kann 10k bis 50k Thinking-Tokens verbrauchen, bevor die sichtbare Antwort kommt. Bei 60 bis 75 US-Dollar pro Million Output-Tokens ist das echtes Geld pro Call.

Die Mathematik verschiebt den Break-Even. Ein Standard-Sonnet-4.6-Call mit 5k Input und 1k sichtbarem Output kostet rund 0,03 US-Dollar. Dieselbe Aufgabe über Extended Thinking mit 20k Thinking-Budget kostet rund 0,35 US-Dollar, mehr als das 10-fache. Bei 1000 täglichen Läufen wird die Wahl zur Budget-Position, nicht zum technischen Detail.

Wann lohnt sich Reasoning-Modus? Bei mehrstufigen Entscheidungen, bei denen ein falscher Zwischenschritt kaskadiert. Vertragsprüfung, medizinische Triage-Zusammenfassungen, Steuer-Logik, Code-Diagnose, die in eine automatisierte Aktion fließt. Wenn ein Fehler bei Schritt 3 den Wert der Schritte 4 bis 10 zerstört, zahlen Sie für Thinking. Wenn jeder Schritt unabhängig prüfbar und günstig wiederholbar ist, nicht. Der Beitrag Claude Extended Thinking geht die Budget-Entscheidung in Produktion durch.

Vier realistische Kosten-Szenarien

Der Teil eines LLM-Kostenrechners, der meistens übersprungen wird: echte Workloads mit echten Zahlen. Alle Kosten sind Listenpreis, ohne Caching, ohne Batch-Rabatt, ohne Retries eingerechnet. Auf den nächsten Dollar gerundet, mal 30 für monatliche Summen.

Szenario 1: Customer-Support-Bot, 10.000 Chats pro Tag

Annahmen: 2.000 Input-Tokens pro Turn, 500 Output pro Turn, 5 Turns pro Chat.

Täglich: 100M Input-Tokens, 25M Output-Tokens.

Auf dieser Stufe ist die Token-Preis-Lücke real. Gemini Flash und GPT-4o-mini unterbieten Haiku um Faktor 4 bis 12 beim reinen Listenpreis. Das Gegengewicht sind Qualität auf Edge Cases, Tool-Use-Zuverlässigkeit und die Kosten einer gescheiterten Eskalation. Wenn eine schlechte Antwort ein menschliches Support-Ticket im Wert von 8 US-Dollar auslöst, kann eine Menge Preisunterschied absorbiert werden, bevor Haiku sich nicht mehr auszahlt.

Szenario 2: Agentic-Workflow, 1.000 Läufe pro Tag

Annahmen: 15k Input, 3k Output pro Turn, 5 Turns pro Lauf mit Tool Use.

Täglich: 75M Input, 15M Output.

GPT-4o gewinnt gegenüber Sonnet 4.6 beim reinen Preis. Gemini Pro gewinnt gegen beide. Das Bild kippt, sobald Prompt Caching auf einem stabilen Tool-Schema aktiviert wird: Sonnet mit Caching auf 80 % des Inputs fällt auf rund 8.000 US-Dollar monatlich, und der Vergleich wird wieder interessant.

Szenario 3: Dokument-Zusammenfassung, 5.000 Dokumente pro Tag

Annahmen: 20k Input, 1k Output pro Dokument. Starke Prefix-Wiederverwendung bei konsistentem System-Prompt und geteilter Instruktions-Vorlage.

Täglich: 100M Input, 5M Output.

Hier leistet Anthropic Caching echte Arbeit. Das Dokument ist der variable Teil, System-Prompt plus Anweisungen plus Format-Guide ist konstant. Cachen Sie das Konstante, zahlen Sie den vollen Preis für das Dokument, und Sonnet schlägt GPT-4o mit komfortablem Abstand. Batch-API halbiert beide Zahlen nochmal, wenn Sie warten können.

Szenario 4: Heavy Reasoning, 100 Läufe pro Tag

Annahmen: 5k Input, 2k sichtbarer Output, 20k Reasoning-Tokens pro Lauf.

Täglich: 0,5M Input, 2,2M effektiver Output (inklusive Thinking).

Die Reasoning-Prämie beträgt rund das 5-fache eines normalen Sonnet-Calls. Wenn es keinen Beleg gibt, dass die Chain-of-Thought die Genauigkeit für diese spezifische Aufgabe spürbar verbessert, zahlen Sie 4.000 US-Dollar monatlich für eine Benchmark-Headline.

Batch-API, Commits und Self-Hosting

Drei Hebel außerhalb der Headline-Tabelle.

Batch. Alles, was 24 Stunden Turnaround toleriert, in Batch kippen und halbieren. Nächtliche Reports, Backfill-Jobs, Evaluations-Läufe, Content-Pipelines, die am nächsten Tag publishen. Es gibt keinen Grund, Echtzeit-Preise für Arbeit zu zahlen, die um 3 Uhr nachts läuft.

Commits. Wenn Ihr Spend seit zwei Quartalen stabil ist und Sie keinen Provider-Wechsel planen, ist ein Commit-Rabatt von 15 bis 25 % verhandelbar. Wenn sich der Spend noch bewegt, lassen. Der Lock-in kostet mehr als die Ersparnis.

Self-Hosting. Llama 3.x, Qwen 2.5, Mistral und DeepSeek V3 im Self-Hosting können API-Pricing bei Dauerlast um Faktor 3 bis 10 pro Token unterbieten. Die echten Kosten sind On-Call-Last, GPU-Verfügbarkeit und die Engineer-Wochen, um den Stack stabil zu bekommen. Ich empfehle Self-Hosting nur, wenn mindestens eines zutrifft: (a) Daten dürfen die eigene Infrastruktur nicht verlassen, (b) Dauer-Spend über 10k US-Dollar monatlich auf einer Nicht-Frontier-Stufe, oder (c) GPU- und Ops-Expertise ist inhouse schon da.

Tokenizer-Eigenheiten im Provider-Vergleich

Ein häufiger Fehler: 1M Tokens bei Provider A mit 1M Tokens bei Provider B zu vergleichen, ohne zu bemerken, dass derselbe Text unterschiedlich tokenisiert wird.

• GPT-4os o200k_base-Tokenizer ist bei englischer Prosa rund 15 % effizienter als Claudes Tokenizer.
• Bei Deutsch wird die Lücke deutlich kleiner. Lange Komposita tokenisieren auf beiden schlechter, Claudes Tokenizer behandelt einige gängige Endungen etwas besser.
• Bei Code hängt die Tokenizer-Effizienz stark von Sprache und Einrückungsstil ab. Python mit 4-Spaces-Einrückung ist nahezu ein Wash. Stark verschachteltes JSON kann um 10 % oder mehr auseinanderlaufen.

Beim Benchmarking von OpenAI vs Anthropic Pricing die echten Production-Prompts durch beide Tokenizer schicken und die Rechnung vergleichen, nicht den Listenpreis. Ich habe “20 % günstiger” zu “5 % günstiger” werden sehen, nachdem die Tokenisierung korrigiert war.

Welches LLM für welchen Kostenrahmen?

Die Budget-Stufen bilden klare Entscheidungsregeln ab.

Unter 50 US-Dollar monatlich. Nach Feature-Fit wählen, nicht nach Preis. Jede Stufe ist günstig genug, dass Modellqualität und SDK-Ergonomie mehr wiegen als ein paar Dollar.

50 bis 500 US-Dollar monatlich. Haiku 4.5, GPT-4o-mini und Gemini Flash dominieren. Zeit in Prompt-Straffung, Output-Kürzung und Evals investieren. Auf dieser Stufe schlägt ein besserer Prompt einen günstigeren Provider.

500 bis 5.000 US-Dollar monatlich. Sonnet 4.6, GPT-4o und Gemini Pro Tradeoffs dominieren. Prompt Caching ist Pflicht, nicht optional. Batch-API für nicht-Echtzeit-Arbeit. Output-Längen-Disziplin zahlt sich jede Woche aus.

5.000 US-Dollar monatlich und mehr. Commits verhandeln. Cache-Hit-Raten auditieren. Self-gehostete Nicht-Frontier-Modelle für die Aufgaben evaluieren, wo die Qualitäts-Toleranz es zulässt. Auf dieser Skala sind 20 % Ersparnis ein Engineer-Gehalt.

Kosten-Monitoring, das Probleme früh fängt

Ein kosteneffizientes Setup, das nie auditiert wird, driftet. Ein paar Muster, die mich vor bösen Überraschungen gerettet haben.

Nutzung pro Call loggen. Jede Response aus den Anthropic- und OpenAI-SDKs enthält ein Usage-Objekt. Persistieren. Sqlite reicht. Spalten: Zeitstempel, Modell, Input-Tokens, Output-Tokens, gecachte Tokens, Workload-Tag.

Wöchentliches Rollup. Ein Cron-Job, der die Woche summiert und mit der vorherigen vergleicht. Wenn der Spend um mehr als 20 % steigt und der Traffic nicht, ist etwas regrediert: längerer Prompt, schlechtere Cache-Hit-Rate, stille Retry-Schleife, neue Modell-Version, die gesprächiger ist.

Tägliche Anomalie-Alerts. Wenn die heutigen Kosten mehr als das 2-fache der gestrigen sind, selbst pingen. Ich lasse das über eine Telegram-Nachricht laufen. Meistens ist es ein Traffic-Spike. Gelegentlich ist es eine durchgeknallte Agentic-Schleife, die bis morgens vierstellig gekostet hätte.

Per-Feature-Attribution. Jeden Call mit einem Workload-Label taggen. Wenn die Rechnung wächst, sollen Sie wissen, ob das Wachstum aus dem Support-Bot, der Zusammenfassungs-Pipeline oder den Batch-Eval-Läufen kommt. Ohne Attribution wird jede Kosten-Regression zu einer zweistündigen Debugging-Session.

Welches sollten Sie wählen?

Wenn ich den ganzen Beitrag auf fünf Regeln reduzieren müsste:

1. Die LLM-Kostenrechner-Logik aus den Szenarien 1 bis 4 nutzen. Eigenen Traffic einsetzen. Nicht raten.
2. Prompt Caching aktivieren, wo der Prefix stabil ist. Der größte einzelne Hebel nach der Modellwahl.
3. Outputs kürzen. Jeder Output-Token ist das 4- bis 5-fache eines Input-Tokens.
4. Async-Workloads auf Batch-API umziehen. 50 % geschenkt.
5. Wöchentlich reviewen. Spend driftet. Ihr 2026-04-Benchmark ist bis 2026-07 veraltet.

Für die meisten Production-Workloads, die ich baue, ist der Default-Stack Haiku 4.5 für Extraktion und Klassifikation, Sonnet 4.6 mit Caching für Agentic-Tool-Use, und Opus 4.7 für die schmale Gruppe von Entscheidungen, bei denen Reasoning-Qualität das nachgelagerte Ergebnis verändert. GPT-4o-mini ist eine starke Alternative am unteren Ende. Gemini Flash ist einen Blick wert, wenn der reine Preis dominiert. o1, o3 und Extended Thinking bleiben im Regal, bis ein spezifischer Workload beweist, dass sie ihren Preis wert sind.

Verwandte Leitfäden

• Claude API vs OpenAI für Business-Automation
• Von OpenAI zu Claude migrieren
• Hetzner vs AWS für AI-Workloads