Was ein KI-Agent in der Produktion wirklich kostet — und wie Sie die Token-Kosten im Griff behalten

Als wir den ersten Agenten für einen Kunden aus der Schwerindustrie deployten — Aufgabe: wöchentliche Berichte aus fünf Systemen automatisch zusammenstellen — überstiegen die gesamten Token-Kosten im ersten Monat unsere ursprüngliche Schätzung um das Fünffache. Nicht weil der Agent irgendetwas falsch gemacht hätte. Sondern weil wir nicht zu Ende gedacht hatten, wie viele Token jeder Schleifenschritt verbraucht, wenn der Verlauf wächst, wenn ein Tool-Aufruf wiederholt retried wird und wenn bei jedem Aufruf die gesamte Konversation in den Kontext kommt. Was im Prototyp Cents pro Anfrage kostete, schlug in der Produktion mit Dutzenden Benutzern und Tausenden täglicher Aufgaben um Größenordnungen höher durch.

Dieser Artikel ist keine hypothetische Preiskalkulation. Er zeigt, wo beim Agenten-Deployment das Geld wirklich fließt, warum gängige Schätzungen so weit von der Realität entfernt liegen — und welche Optimierungen in der Praxis funktionieren: von kürzerem Kontext über Routing auf günstigere Modelle bis hin zu Prompt-Caching.

Wo die Token-Kosten eines Agenten entstehen

Agenten sind teurer als einfache LLM-Aufrufe — aus einem einzigen Grund: Jeder Schleifenschritt ist ein neuer API-Aufruf, in den der wachsende Verlauf vollständig eingeht. Vergleichen Sie das mit klassischem RAG: eine Anfrage, ein Aufruf, eine Antwort. Ein Agent mit zehn Schritten macht zehn Aufrufe — und jeder trägt den gesamten bisherigen Kontext.

Die konkrete Kostenstruktur sieht so aus:

• System-Prompt — wiederholt sich bei jedem Aufruf. Ein System-Prompt mit 2 000 Token und acht Agentenschritten bedeutet, dass Sie für denselben Text achtmal bezahlen.
• Konversationsverlauf — jeder Reason-Act-Observe-Zyklus fügt weitere Token zum Kontext hinzu. Bei langen Aufgaben wachsen die Input-Token quadratisch.
• Tool-Ausgaben — Antworten von Tools (Datenbankergebnisse, API-Antworten, Dokumente) werden in den Kontext eingefügt und vergrößern ihn weiter. Umfangreiches RAG-Retrieval vor jedem Schritt kann die Input-Token verdoppeln.
• Retry-Schleifen — schlägt ein Tool-Aufruf fehl, versucht der Agent es erneut. Eine Retry-Rate von 10–15 % ist in Produktionssystemen üblich. Jeder Retry = ein weiterer Aufruf mit dem vollständigen Kontext.
• Output-Token — das Reasoning von Agenten (chain-of-thought, schrittweises Denken) erzeugt lange Antworten. Output-Token sind typischerweise 3–5× teurer als Input-Token.

Ergebnis: Ein realer Agent in der Produktion verbraucht pro Aufgabe eine Größenordnung von 5–50× mehr Token, als Sie aus dem Prototyp schätzen würden.

Größenordnungen — was das in Euro bedeutet

Modellpreise ändern sich alle 1–3 Monate, daher nenne ich orientierungsweise ungefähre Größenordnungen, die zum Zeitpunkt der Abfassung dieses Artikels galten. Überprüfen Sie stets die aktuelle Preisliste direkt beim Anbieter.

Frontier-Modelle bewegen sich derzeit zwischen etwa $0,10 und $5 pro Million Input-Token und zwischen etwa $5 und $30 pro Million Output-Token — ein Unterschied von 50× zwischen dem günstigsten und dem teuersten Tier. Das ist die entscheidende Zahl: Die Modellwahl ist der stärkste Kostenhebel, stärker als jede andere Optimierung.

Stellen Sie sich einen Agenten vor, der täglich 100 Aufgaben verarbeitet:

• Günstiges Tier (Flash/Haiku-Äquivalent, $0,10–0,30/1M Input-Token): Selbst bei 50 000 Token pro Aufgabe bewegen Sie sich im Bereich weniger Euro pro Tag. Monatlich einige hundert Euro.
• Mittleres Tier (Sonnet-Äquivalent, ~$3–5/1M Input-Token): Dieselbe Last kann 1 000–3 000 Euro monatlich kosten.
• Premium-Tier (Opus-Äquivalent, ~$15+/1M Input-Token): Dieselbe Last kann 5–10× teurer sein als das mittlere Tier.

Läuft das System zusätzlich mit einer Retry-Rate von 12 %, zahlen Sie effektiv 1,12× pro Aufgabe — was sich bei größerem Volumen schnell aufaddiert.

Human Escalation ist ein weiterer versteckter Kostenfaktor: Wenn der Agent bei 5 % der Aufgaben scheitert und jede Eskalation an einen menschlichen Operator 2–10 Euro kostet (Zeitaufwand), kann dieser Posten die reinen Token-Kosten übersteigen.

Vier Stellen, wo sich Kosten effektiv reduzieren lassen

1. Kontext systematisch kürzen — nicht zufällig

Die größte Einsparung liegt nicht im günstigeren Modell, sondern in weniger Token pro Aufruf. Konkrete Maßnahmen:

• System-Prompt komprimieren. Jede überflüssige Zeile im System-Prompt wird hundertfach täglich bezahlt. Prüfen Sie regelmäßig, was dort wirklich gebraucht wird.
• Konversationsverlauf zusammenfassen. Statt den gesamten Verlauf in den Kontext zu laden, lassen Sie den Agenten nach N Schritten eine Zusammenfassung erstellen. LangGraph bringt dafür einen eingebauten Summarization-Node mit. Es geht etwas Granularität verloren, für die meisten Aufgaben spielt das keine Rolle.
• Tool-Ausgaben filtern. Gibt RAG-Retrieval fünf Dokumente zurück, braucht der Agent aber nur eines, zahlen Sie unnötig für vier. Setzen Sie Reranking ein und begrenzen Sie die Anzahl der in den Kontext eingefügten Fragmente.
• Ausgabelänge begrenzen. Der Reasoning-Fluss muss nicht immer unbegrenzt sein. Für Standardschritte reicht eine kurze Antwort; detailliertes chain-of-thought reservieren Sie nur für wirklich komplexe Entscheidungspunkte.

2. Einfache Schritte auf günstigere Modelle routen

Nicht jeder Agentenschritt braucht ein Frontier-Modell. Typische Verteilung:

• Orchestrierungsschritte (was als nächstes tun, welches Tool aufrufen): meist reicht ein günstigeres Modell
• Retrieval und Datenfilterung: günstiges Modell oder sogar deterministische Logik
• Finale Antwortsynthese für den Benutzer: hier lohnt sich ein stärkeres Modell
• Verifikation und Self-Consistency-Check: günstiges Modell in der Schleife

LLM-Routing — die dynamische Modellwahl nach Schrittkomplexität — ist eine Optimierung, über die wir gesondert im Artikel über LLM-Routing und Cascading geschrieben haben. Im Agenten-Kontext gilt dasselbe Prinzip: Ein Dispatcher klassifiziert jeden Schritt und leitet ihn an das günstigste Modell weiter, das ihn zuverlässig bewältigen kann.

3. Prompt-Caching — System-Prompt einmal bezahlen

Prompt-Caching ist eine Technologie, die Anthropic, OpenAI und Google in ihren APIs anbieten. Das Prinzip: Wiederholt sich der Anfang des Kontexts (typischerweise System-Prompt oder ein langer statischer Dokumentblock) über mehrere Aufrufe hinweg, cached der Anbieter ihn serverseitig und berechnet die Wiederholungsnutzung zu einem Bruchteil des Standardpreises — in der Größenordnung von –90 % auf den gecachten Anteil.

Für einen Agenten mit langem System-Prompt, der in Dutzenden gleichzeitiger Sessions läuft, ist Caching eine der am schnellsten implementierbaren Einsparungen. Im Artikel über Prompt-Caching und Kosten gehen wir ausführlicher darauf ein.

Voraussetzung: Caching funktioniert gut für stabile Promptanteile. Enthält jeder Aufruf anderen dynamischen Inhalt zu Beginn, bleibt die Cache-Hit-Rate niedrig und die Einsparung minimal.

4. Limits setzen — vor dem Deployment, nicht nach dem Vorfall

Das ist der Punkt, der in der technischen Literatur oft als Fußnote erscheint, in der Praxis aber Gesetz ist: Ein Agent ohne Hard-Limits ist ein finanzielles Risiko.

• max_steps (oder Äquivalent): maximale Anzahl Schleifenschritte vor dem Stopp
• max_tokens_per_run: gesamtes Token-Budget pro Aufgabe
• timeout: Zeitlimit, nach dem der Agent stoppt und ein Teilergebnis zurückgibt
• cost_budget_per_day: auf Systemebene, überwacht mit einem Alert

Ein Agent ohne max_steps-Limit kann bei unerwartetem Input oder einem fehlerhaften Tool in einer Schleife feststecken und über Nacht Tausende von Aufrufen erzeugen — mit einer Rechnung in der Größenordnung von Tausenden Euro. Das ist keine Hypothese. Wir sehen es in Produktionssystemen, und es ist stets vermeidbar.

Agentic RAG: wo Kosten unbemerkt eskalieren

Agentic RAG — also RAG, bei dem der Agent selbst entscheidet, wie oft und was er lädt — ist 5–10× teurer als klassisches RAG. Nicht weil er schlechter wäre, sondern weil er mehr leistet.

Typische Agentic-RAG-Sequenz für eine Frage:

1. 1.Entscheidung, welche Retrieval-Strategie zu verwenden ist (1 LLM-Aufruf)
2. 2.Erste Suche (Retrieval + Reranking)
3. 3.Bewertung, ob die Ergebnisse ausreichen (1 LLM-Aufruf)
4. 4.Ggf. weitere Suche mit angepasster Anfrage (Retrieval + Reranking)
5. 5.Antwortsynthese (1 LLM-Aufruf mit dem gesamten gesammelten Kontext)

Jeder Schritt hat seinen Preis. Wird bei jedem dieser Aufrufe ein starkes Modell eingesetzt, wachsen die Kosten rasch.

Optimierung: Verwenden Sie ein günstiges Modell für die Entscheidungsschritte (1, 3) und ein starkes Modell nur für die finale Synthese (5). Begrenzen Sie außerdem die Anzahl der Retrieval-Iterationen — die meisten Fragen lösen sich in 1–2 Runden, nicht in fünf.

Mehr zur Architektur von Agentic RAG finden Sie im Artikel Agentic RAG — wie es in der Praxis funktioniert.

Batch API: wenn Sie das Ergebnis nicht sofort brauchen

Bei Aufgaben, die keine Echtzeit-Antwort erfordern — Offline-Dokumentenverarbeitung, nächtliche Analyseläufe, Trainingsdaten — ist die Batch API eine erhebliche Einsparung. Anthropic (und andere Anbieter) bieten –50 % auf Batch-Aufrufe gegenüber dem synchronen Preis, zu dem Preis einer Verarbeitungsverzögerung von einigen Stunden.

Architektur: Das Frontend-System sammelt Aufgaben in einer Warteschlange, der Batch-Job läuft nachts oder bei niedriger Last, Ergebnisse werden in die Datenbank geschrieben und stehen morgens bereit. Für viele Industrieanwendungen — Berichtszusammenfassungen, Dokumentationskategorisierung, Datenextraktion aus PDFs — ist dieser Ansatz finanziell um eine Größenordnung vorteilhafter.

Kosten messen: was in der Produktion zu beobachten ist

Token-Kosten ohne Observability sind eine Black Box. Wir empfehlen, mindestens folgende Metriken zu erfassen:

• Cost per Task Type — verschiedene Aufgabentypen haben verschiedene Kostenprofile. Ohne diese Unterscheidung wissen Sie nicht, wo Sie optimieren sollen.
• Retry Rate per Tool — welches Tool verursacht am häufigsten Retries? Liegt es am Tool selbst oder an einer schwachen Tool-Description?
• Average Steps per Run — wenn der Agent im Schnitt 8 Schritte benötigt, wo Sie 4 erwartet haben, muss die Architektur überprüft werden.
• Cache Hit Rate — wenn Sie Prompt-Caching verwenden: Wie viel Prozent der Aufrufe treffen tatsächlich den Cache? Unter 60 % ist das Caching falsch konfiguriert.
• Human Escalation Rate — wie viel Prozent der Aufgaben enden mit einer Eskalation? Steigt die Rate, scheitert der Agent wahrscheinlich an Szenarien, für die er nicht ausgelegt war.

Tools wie Langfuse (self-hostable, framework-agnostic) oder LangSmith (tiefe LangGraph-Integration) erfassen diese Metriken auf Ebene jedes einzelnen Nodes und Aufrufs. Ohne Observability sind Sie blind — mehr dazu im Artikel über Observability von KI-Agenten.

Open-Weight-Modelle als Kostenalternative

Für Teams, die in erster Linie die Kostenseite im Blick haben, sind aktuelle Open-Weight-Modelle eine reale Alternative. Modellfamilien wie Qwen 3.x, DeepSeek oder Llama 4 erzielen auf vielen Agentic-Benchmarks Ergebnisse, die mit Frontier-Closed-Source-Modellen vergleichbar sind — bei null oder minimalen API-Kosten, wenn sie on-premises betrieben werden.

Sie zahlen GPU-Server statt API. Bei großen Aufgabenvolumen (Zehntausende tägliche Aufrufe) liegt der Break-even-Punkt typischerweise im Bereich einiger Monate. Für regulierte Umgebungen, in denen Daten das Unternehmen nicht verlassen dürfen, ist On-Prem zudem eine Compliance-Anforderung, nicht nur eine Kostenfrage.

Tradeoff: On-Prem erfordert Engineering-Kapazitäten für Infrastructure-Management, Serving-Stack (vLLM, SGLang), Monitoring und Modell-Upgrades. Nicht jedes Team hat das.

Häufige Fragen

Warum ist mein Agent deutlich teurer als ursprünglich geschätzt?

Der häufigste Grund ist eine Kombination aus drei Faktoren: der wachsende Verlauf im Kontext bei jedem Schleifenschritt, Retry-Aufrufe bei Tool-Fehlern und lange System-Prompts, die bei jedem Aufruf wiederholt werden. Der Prototyp testet typischerweise 1–2 Schritte mit statischen Eingaben. Die Produktion bedeutet reale Eingaben, reale Tool- und Benutzerfehler sowie Benutzer, die den Agenten in unerwartete Zustände treiben. Wir empfehlen, den Cost-per-Run nach Komponenten aufzuschlüsseln (System-Prompt, Verlauf, Tool-Ausgaben, Output), bevor Sie mit der Optimierung beginnen.

Lohnt es sich, Prompt-Caching zu implementieren?

Wenn Ihr System-Prompt länger als 1 000 Token ist und der Agent in Dutzenden oder Hunderten von Sessions täglich läuft — ja, es lohnt sich fast immer. Die Implementierung ist meist einfach (ein Parameter beim API-Aufruf), die Einsparung auf dem gecachten Anteil liegt bei Anthropic in der Größenordnung von –90 %. Voraussetzung ist die Stabilität des Kontextbeginns — ändert sich der System-Prompt bei jedem Aufruf, bleibt die Cache-Hit-Rate niedrig.

Wann lohnt sich der Wechsel von API auf ein On-Prem-Modell?

Das hängt vom Volumen und von Compliance-Anforderungen ab. Als Faustformel: Übersteigt die monatliche API-Rechnung die Kosten eines dedizierten GPU-Servers (inklusive Betrieb und HW-Amortisierung) — typischerweise irgendwo im Bereich von einigen Tausend Euro monatlich — ist eine Analyse sinnvoll. Für regulierte Branchen (Gesundheitswesen, Recht, Finanzen) ist On-Prem darüber hinaus eine DSGVO-Compliance-Anforderung, nicht nur eine Kostenfrage.

Wie setzt man ein vernünftiges max_steps-Limit?

Beginnen Sie mit Profiling — wie viele Schritte braucht Ihre typische Aufgabe wirklich? Liegt der Median bei 4 Schritten und das 95. Perzentil bei 8, setzen Sie das Limit mit Sicherheitspuffer auf 12–15. Das Limit sollte hoch genug sein, um legitime lange Aufgaben nicht zu unterbrechen, aber niedrig genug, um Endlosschleifen abzufangen. Die Kombination aus max_steps + timeout + einem Monitoring-Alert für Runs, die mehr als 80 % des Limits ausschöpfen, ist in der Praxis robust.

Was ist der größere Kostenfaktor — Token oder Human Escalation?

Das hängt von der Eskalationsrate ab. Eskaliert der Agent 1–2 % der Aufgaben und kostet eine menschliche Bearbeitung 5 Euro, sind das bei 1 000 Aufgaben täglich 50–100 Euro/Tag für Eskalationen — was die Token-Kosten eines günstigeren Modells übersteigen kann. Bei Systemen mit hohem Aufgabenvolumen und nicht vernachlässigbarer Eskalationsrate ist die Reduktion der Eskalation (besseres Agenten-Training, klarere Guardrails) die bessere Investition als Token-Einsparungen.

*Die Kosten eines Agenten in der Produktion sind messbar und kontrollierbar — aber nur, wenn wir sie tatsächlich messen. Bei MP Industrial Solutions helfen wir Unternehmen, Agentic-Systeme mit einem klaren Cost-Profil von Anfang an zu konzipieren, statt retrospektiv zu optimieren, nachdem die erste Monatsrechnung für eine Überraschung gesorgt hat. Wenn Sie über den Einsatz eines Agenten nachdenken und vor der Implementierung ein realistisches Cost-Modell erstellen möchten, sprechen wir gerne mit Ihnen.*