LLM-Kostenrechner 2026: Rechne pro Aufgabe, nicht pro Token

Die nützliche Einheit für eine LLM-Rechnung ist nicht eine Million Tokens. Gemeint ist eine erledigte Aufgabe: ein beantwortetes Support-Ticket, eine extrahierte Rechnung, ein geprüfter Pull Request, eine gelöste interne Frage. Der Preis pro Token ist nur die Preisliste. Cost per Task ist die Rechnung nach Retries, Tool-Calls, Kontext, Cache-Hits, Routing, Batch-Rabatten und schlechten Outputs. Das ist der Rechner, den wir vor jeder Kostenoptimierung nutzen.

Engineering-Perspektive, keine Preisberatung. Die Formeln sind stabil; die Beispielpreise musst du vor einem Commit mit aktuellen Providerpreisen ersetzen. Stand 8. Juli 2026: OpenAI nennt für die Batch API 50% Rabatt und ein 24-Stunden-Fenster, OpenAI Prompt Caching startet ab 1.024 Prompt-Tokens, Anthropic bepreist Cache Reads mit 0,1x des Inputpreises und die Batches API mit 50% des Standardpreises, und Gemini aktiviert implizites Caching standardmäßig für Gemini 2.5 und neuere Modelle. Prüfe die verlinkten Primärquellen, bevor du budgetierst.

Der Rechner in einer Formel

Starte mit einer Aufgabe, nicht mit einem API-Call. Eine Aufgabe kann mehrere Modellaufrufe, Retrieval, Tools, einen Verifier und manchmal einen Retry enthalten. Die Gesamtkosten sind:

Kosten pro erledigte Aufgabe = Modellkosten aller Calls + Retrieval und Infra + Retry-Kosten + menschliche Nacharbeit.

Genau deshalb haben wir über Cost per Token vs Cost per Task geschrieben. Ein günstigeres Modell, das mehr Schleifen braucht, längere Outputs erzeugt oder häufiger scheitert, kann teurer sein als das Modell mit der schmerzhaften Preisliste.

Welche Eingaben gehören in den Rechner?

Wenn dein Sheet nur Input-Tokens, Output-Tokens und Modellpreis enthält, zählt es zu wenig. Nimm diese Felder auf:

• Aufgabenvolumen. Zähle echte Geschäftseinheiten: Tickets, Dokumente, Angebote, Pull Requests, Checks, Research-Briefings.
• Calls pro Aufgabe. Agentische Workflows verbrennen die Rechnung oft in Schleifen: Klassifikation, Retrieval, Entwurf, Tool-Call, Verifier, Rewrite, Audit-Log.
• Input pro Call. Trenne stabilen Prefix, Retrieval-Kontext, Verlauf, Tool-Schemas und volatile Nutzerdaten. Hier zeigen sich Caching und Kontext-Kompression.
• Output pro Call. Reasoning- und Coding-Agenten sind oft outputlastig. Billiger Input hilft wenig, wenn das Modell tausende Output-Tokens schreibt.
• Cache-Hit-Rate. Messe gecachte Tokens, nicht nur gecachte Requests. OpenAI liefert `cached_tokens`, Gemini cached Token Counts, Anthropic trennt Cache Write und Cache Read.
• Batchbarer Anteil. Alles, was warten kann, gehört zuerst in Batch: Evals, Offline-Extraktion, Enrichment, Klassifikation, Zusammenfassungen.
• Eskalationsrate. Wenn ein günstiges Modell den ersten Pass macht und ein starkes Modell die schweren Fälle übernimmt, ist die Eskalationsrate ein Produkt-KPI.
• Qualitätsgrenze. Stelle die Pass-Rate deines Eval-Harness neben die Kosten. Sonst vergleichst du Rechnungen und ignorierst, ob die Arbeit noch funktioniert.

"Wenn dein Rechner nicht zeigt, was eine erfolgreiche Aufgabe kostet, ist er kein KI-Kostenrechner. Er ist ein Token-Beleg."

Beispiel: Support-Triage

Ein Support-Workflow liest ein Ticket, holt Policy-Auszüge, schreibt eine Antwort und lässt prüfen, ob die Antwort belegt ist. Das naive Sheet sagt: ein Answer-Call, vielleicht 4.000 Input-Tokens und 600 Output-Tokens. Der Production Trace sagt etwas anderes:

Die Modellkosten sind nicht der Answer-Call. Im Schnitt sind es 3,18 Calls plus Retrieval plus Retry-Tail. Wenn 60% des Draft-Inputs stabiler System-Prompt, Policy-Rahmen und Tool-Schema sind, zählt Prompt Caching mehr als ein Modellwechsel. Wenn nur 20% der Tickets das starke Modell brauchen, zählt Routing mehr als ein paar Cent beim Default-Modell. Das ist unser LLM-Kosten-Playbook als Rechner.

Wo Prompt Caching in die Rechnung kommt

Prompt Caching ist der erste Hebel, weil es wiederholten Input günstiger macht, ohne Modell oder Antwort zu ändern:

Input-Kosten = uncached_input * normal_input_price + cached_input * cache_read_price + cache_writes * cache_write_price.

Der operative Trick ist langweilig und wertvoll: stabiler Inhalt zuerst, volatiler Inhalt zuletzt. OpenAI empfiehlt für Caching bei Prompts ab 1.024 Tokens statische oder wiederholte Inhalte am Anfang. Anthropic bepreist Cache Reads mit 0,1x, während Cache Writes teurer sind als normaler Input, also zahlt sich der Write erst durch Wiederverwendung aus. Gemini sagt, implizites Caching sei für Gemini 2.5 und neuere Modelle standardmäßig aktiv und empfiehlt große gemeinsame Inhalte am Anfang.

• Guter Cache-Prefix: System-Instruktion, Tool-Definitionen, Output-Schema, Produktpolicy, stabiler Retrieval-Kontext.
• Schlechter Cache-Prefix: Timestamp, User-ID, zufällige Trace-ID, aktuelles Dokument, Ticket-Body.
• Metrik: gecachte Input-Tokens geteilt durch gesamte Input-Tokens, je Feature und Modell.

Primärquellen: OpenAI Prompt Caching, Anthropic Prompt Caching und Gemini Context Caching.

Wo Batch APIs in die Rechnung kommen

Batching ist kein Latenztrick. Es ist ein Preis- und Durchsatzhebel für Arbeit, die warten kann:

Gesamte Modellkosten = live_cost + batchable_cost * batch_multiplier.

OpenAI dokumentiert für die Batch API 50% Rabatt gegenüber synchronen APIs und ein 24-Stunden-Fenster. Anthropic nennt für Message Batches ebenfalls 50% geringere Kosten, meistens unter einer Stunde Laufzeit und Ergebnisse nach Abschluss aller Nachrichten oder nach 24 Stunden. Batch ist damit Standard für Evals, nächtliches Enrichment, Offline-Extraktion, Backfills, Moderation und Analytics-Zusammenfassungen.

Batch keine Live-UX, wenn Nutzer warten. Batch dein Eval-Harness. Viele Teams zahlen laufend für Prompt- und Modelltests und vergessen, dass diese Tests keine Live-Latenz brauchen. Warum sich das rechnet, steht in wann sich ein LLM-Eval bezahlt macht.

Primärquellen: OpenAI Batch API und Anthropic Batch Processing.

Routing: der Hebel mit Qualitätsfalle

Routing verändert den Modellmix pro Aufgabe. Der Rechner braucht daher einen Anteil fürs starke Modell:

Routing-Kosten = cheap_path_cost * (1 - escalation_rate) + strong_path_cost * escalation_rate + verifier_cost.

Das RouteLLM-Projekt beschreibt das Prinzip gut: einfache Queries gehen an günstigere Modelle, stärkere Modelle übernehmen die schwierigen Fälle, und der Threshold wird auf echtem Traffic kalibriert. Die README berichtet bis zu 85% Kostenreduktion bei 95% GPT-4-Performance auf Benchmarks. Behandle das als Forschungsreferenz, nicht als deine Produktionszahl. Dein Traffic kann anders routen, besonders bei domänenspezifischen Edge Cases.

1. Günstiger Default. Starte mit dem billigsten Modell, das die einfache Mehrheit besteht.
2. Verifier. Prüfe Schema, Grounding, Policy und Confidence.
3. Eskalation. Unsichere, teure oder fehlgeschlagene Fälle gehen an ein stärkeres Modell.
4. Eval-Gate. Vergleiche günstigen Pfad, starken Pfad und Routing auf echten Beispielen.
5. Monitoring. Steigt die Eskalationsrate, hat sich Traffic verändert oder das billige Modell ist überfordert.

Hier helfen LLM-Gateways und Router. LiteLLM, Portkey, OpenRouter oder eine eigene RouteLLM-Schicht bündeln Logs, Modellmix, Fallback, Budgets und Routing. Der Rechner ist der Grund für diese Schicht; das Gateway ist, wie du sie misst.

Forschung und Tools: RouteLLM, RouteLLM Paper, Batch-Level Query Routing und Routing mit Batch Prompting.

Lokale Modelle und Self-Hosting

Self-Hosting macht Inference nicht kostenlos. Es tauscht variable Tokenkosten gegen GPU-Kosten, Auslastungsrisiko, Ops, Redundanz und Eval-Pflege:

Self-Host-Kosten pro Aufgabe = (gpu_hour_cost + ops_hour_cost + redundancy + monitoring + eval_upkeep) / completed_tasks_per_hour.

Der Nenner entscheidet. Eine GPU mit 80% Auslastung kann lokale Inference rational machen. Eine GPU mit 12% Auslastung, weil dein Traffic spiky ist, wird zum teuren Souveränitäts-Symbol. Deshalb beginnt unser EU-Self-Hosting-Kosten-Guide mit Volumen und Datenresidenz, nicht mit GPU-Specs.

• Datenresidenz oder Governance zwingt dich. Dann ist Kostenoptimierung die zweite Frage.
• Hohes, stabiles Volumen füllt die Hardware. Gegen günstige Hosted Open-Weight-APIs brauchst du anhaltende Last, nicht gelegentliche Peaks.

Die Modellwahl kommt danach. Unser Open-Weight-LLM-Vergleich behandelt DeepSeek, Qwen, Kimi, GLM und Llama aus europäischer Deployment-Sicht. Dein Rechner muss die Pass-Rate auf deinem Eval enthalten, nicht nur Tokens pro Sekunde.

Kontext-Kompression und Semantic Caching

Nach Prompt Cache, Batch und Routing kommt die Frage, ob das Modell den Kontext überhaupt brauchte:

• Semantic Caching. Ist eine neue Anfrage nah genug an einer früheren, gibst du die alte Antwort oder eine leicht angepasste Antwort zurück. Das spart stark bei repetitivem Support und internen Assistenten, kann aber stale oder unberechtigte Antworten leaken, wenn Permissions und Invalidation schwach sind.
• Kontext-Kompression. Schicke den kleinsten korrekten Kontext: Zusammenfassungen, File Maps, relevante Snippets und bereinigte Tool-Ausgaben statt den ganzen Workspace in jedem Turn.

Das hängt direkt mit warum Coding-Agenten an Kontext scheitern und unserem Text über Text-as-Image Token Savings zusammen. Kompression ist stark, aber exakte Werte, IDs, Beträge, Hashes, Vertragsklauseln und Permissions müssen exakt bleiben. Ist die Optimierung verlustbehaftet, braucht der Rechner eine Fehlerkosten-Zeile.

Ein Sheet-Layout zum Kopieren

Lege eine Zeile pro Aufgabentyp an, nicht pro Modell:

In welcher Reihenfolge optimierst du?

1. Cost per Task instrumentieren. Logge Task-ID, Modell, Tokens, Cache-Hits, Retries, Latenz, Status und Eval-Urteil.
2. Caching ernst nehmen. Stabiler Prefix zuerst, volatile Daten zuletzt, gecachte Tokens je Feature messen.
3. Offline-Arbeit batchen. Evals und Enrichment sollten keine Live-Preise zahlen.
4. Mit Verifier routen. Günstiger Default, starker Fallback, überwachte Eskalationsrate.
5. Modell richtig dimensionieren. Teste Open Weights und kleinere Modelle auf deinem Eval-Set.
6. Kontext komprimieren. Entferne irrelevante History und wiederholten Workspace-Kontext.
7. Self-host nur bei Volumen oder Governance. Bepreise Auslastung und Engineers, nicht nur GPU-Stunden.