Anfang 2025 lag das monatliche KI-Rechnungsniveau vieler Marketing-Teams noch bei einem drei- bis mittelvierstelligen Betrag. Wer Anthropic, OpenAI und lokale Modelle kombiniert, Content-Reviews automatisiert und Sales-Emails personalisiert, war da schnell dabei. Anderthalb Jahre später, im zweiten Quartal 2026, kippt bei fast jedem Team, mit dem ich arbeite, dieselbe Zahl in den mittleren fünfstelligen Bereich. Das Volumen der Anfragen ist gestiegen — aber nicht um den Faktor, den die Rechnung nahelegt.
Der Grund ist nicht schlechte Verhandlung mit Modell-Anbietern und selten das Modell selbst. Der Grund ist, dass in einer Beschleunigungs-Phase strukturelle Kosten-Leaks eingebaut werden, die sich erst zeigen, wenn das Volumen wächst — und dann geometrisch wachsen, nicht linear.
Diese Notiz beschreibt die drei Leaks, die ich in jedem laufenden Mandat 2026 vorfinde, die Reporting-Kategorie, die sie schnell sichtbar macht, und die drei bis fünf konkreten Änderungen, die eine Halbierung ohne Rollout-Schmerz möglich machen.
Leak 1: Prompt-Caching, das nicht cached.
Prompt-Caching bei Anthropic und OpenAI funktioniert so, dass ein statischer System-Prompt oder eine gleichbleibende Dokument-Basis nach der ersten Anfrage im Cache liegt und bei den folgenden Anfragen nur zu einem Bruchteil der Input-Token-Kosten abgerechnet wird. Anthropic verlangt für Cache-Reads etwa ein Zehntel der regulären Input-Token, mit einer TTL von fünf Minuten. OpenAI hat vergleichbare Mechanik.
Der Bug entsteht so: ein Marketing-Team hat einen Agenten, der für jede Content-Review einen 12.000-Token System-Prompt lädt. In der Vorstellung des Teams cached dieser Prompt. In der Praxis wird der System-Prompt jedes Mal leicht anders zusammengebaut — mit Team-Namen, User-Kontext, Datum, das aktuelle Uhrzeit-Timestamp im Prefix. Jede minimale Abweichung invalidiert den Cache. Der 12.000-Token-Prompt wird bei jeder Anfrage voll neu abgerechnet.
Zweiter Anti-Pattern: Sub-Agenten, die untereinander System-Prompts kopieren, aber mit marginal anderen Präambeln. Was aussieht wie „wir cachen den Prompt-Präfix" ist in Wirklichkeit „wir haben fünf ähnliche, aber nicht identische Präfixe im Cache — jeder muss initial voll bezahlt werden."
Der Test dauert 15 Minuten: nehmt einen Standard-Workflow, führt ihn zehnmal hintereinander aus, und schaut in eurem Provider-Dashboard, ob die Cache-Hit-Rate auf System-Prompts über 90 % steigt oder unter 30 % steckenbleibt. Die zweite Zahl ist der Standardbefund.
Leak 2: Retries, die keiner sieht.
Der zweite Leak ist die stille Retry-Kaskade. Frameworks wie LangChain, das Anthropic SDK, MCP-Client-Implementationen und interne Wrapper haben alle sinnvolle Default-Retry-Regeln: bei einem 429 (Rate Limit) oder 5xx wird zwei- bis dreimal mit exponentiellem Backoff neu versucht. Das ist korrekt so.
Der Kosten-Leak entsteht, wenn diese Retries auf mehreren Schichten gleichzeitig laufen. Die Anfrage geht durch: (a) einen Retry-Wrapper des Backend-Frameworks, (b) den SDK-eigenen Retry-Layer, (c) den HTTP-Client-Retry-Layer. Jede Schicht denkt, sie ist die einzige, die retried. Bei einem tatsächlich fehlerhaften Request werden nicht drei, sondern neun oder siebenundzwanzig Anfragen bezahlt. Modelle wie Claude Sonnet 4.5 mit 1M-Context sind besonders anfällig, weil sie bei transienten Rate-Limits häufiger 429 zurückgeben.
Der zweite unsichtbare Multiplikator: Retries bei erfolgreichem partial-output, wenn der Client denkt, der Stream sei „hängengeblieben". In Streaming-Setups wird eine bereits halb-fertige Antwort verworfen und neu gestartet — die halbfertige zählt trotzdem als Ausgabe-Token.
Der Test dauert einen Tag: instrumentiert einen Request-Counter pro End-User-Aktion. Vergleicht ihn mit der Zahl der Requests, die euer Provider-Dashboard für denselben Zeitraum zeigt. Ein Faktor von 1,3× bis 1,8× ist normal (echte Retries, gelegentliche 429er). Über Faktor 2,5× beginnt der Alarm.
Leak 3: Agent-Tiefe, die kein Product Owner freigegeben hätte.
Der teuerste der drei Leaks ist zugleich der schleichendste. Agenten-basierte Workflows haben die Eigenschaft, dass sie ihre eigene Tiefe wählen — ein Agent kann sich entscheiden, Sub-Agenten zu spawnen, die wiederum Sub-Sub-Agenten spawnen. In einem gutartigen Setup sind das drei Ebenen. In einem realen Setup, das in Wochen gewachsen ist ohne Review, sind es fünf bis sieben.
Jede Ebene kostet Token in zwei Richtungen: der übergeordnete Agent muss das Ergebnis formatieren und weiterreichen (Output-Token), der untergeordnete Agent muss den Kontext neu aufbauen (Input-Token, oft ohne Caching, siehe Leak 1). MCP-Server-Roundtrips addieren zusätzliche Overhead-Token für Handshakes und Metadaten.
Der Anti-Pattern hier heißt: agentic drift. Ein Marketing-Content-Reviewer wird vor drei Monaten spezifiziert als „ein Agent, der Copy prüft und Freigabe-fähig macht". Heute besteht er aus einem Orchestrator, der einen Research-Sub-Agenten anfragt, der einen Wettbewerbs-Sub-Sub-Agenten anfragt, der drei parallele Web-Recherchen startet. Für einen Content-Review, der ursprünglich als 5.000-Token-Aktion gedacht war.
Der Test dauert eine Stunde: nehmt eure fünf teuersten Workflows im letzten Monat und zählt die tatsächliche Zahl der Tool-Calls und Sub-Agent-Aufrufe pro Ausführung. Wenn die Zahl vom Product-Owner-Design um mehr als Faktor 2 abweicht, habt ihr agentic drift.
Warum Reporting nach Team-Runde alles ändert.
Das gängige KI-Reporting geht nach API-Key: „unser Marketing-Key hat diesen Monat X gekostet". Diese Zahl ist nutzlos zur Diagnose. Sie sagt nicht, welche der Leaks aktiv sind, welcher Workflow wächst, wo die Verhältnisse nicht mehr stimmen.
Das nützliche Reporting geht nach Team-Runde: eine Team-Runde ist eine wiederkehrende Business-Aktion (ein Sales-Email-Versand, ein Content-Review, ein Krisenkommunikation-Draft). Für jede Runde protokolliert ihr drei Metriken:
- Input-Token pro Runde, aufgesplittet in Cache-Miss und Cache-Hit. Zeigt Leak 1. Wenn Cache-Miss über 60 % liegt, cached euer Prompt nicht wirklich.
- Requests pro Runde, verglichen mit Design-Intent. Zeigt Leak 2 und 3. Wenn die Anzahl der API-Calls für eine Content-Review-Aktion nicht 1–3 ist, sondern 15, habt ihr Agent- oder Retry-Drift.
- Latenz pro Runde und deren Standardabweichung. Zeigt Retry-Explosion. Runden, die manchmal 8 Sekunden und manchmal 45 Sekunden dauern, retryen intern.
Diese drei Metriken monatlich in einem Dashboard, aufgesplittet pro Workflow-Typ, und ihr habt in einer Woche das, was ihr in 12 Monaten API-Key-Reporting nicht seht.
Ein konkretes Fallbeispiel — anonymisiert.
Mid-Market-SaaS-Company in DACH, Marketing- und Content-Team von acht Personen. Cost pro Monat Ende Q1 2026: rund € 8.400 an OpenAI + Anthropic zusammen. Prognose für Q3 nach linearem Trend: € 22.000. Nach zwei Wochen Diagnose-Arbeit stellte sich heraus:
- Cache-Hit-Rate auf System-Prompts: 18 %. Ursache: ein Timestamp im Prompt-Prefix, der auf die Minute genau war. Nach Fix auf Tag-Level-Timestamp: Cache-Hit-Rate 91 %. Sofort-Einsparung: ~ € 1.900 monatlich.
- Retry-Kaskaden: durchschnittlich 2,7× mehr Requests als End-User-Aktionen. Ursache: drei Retry-Layer aktiv (Backend-Wrapper, SDK, HTTP-Client). Nach Konsolidierung auf einen Retry-Layer mit strikterem Backoff: durchschnittlich 1,15× Requests. Einsparung: ~ € 1.400 monatlich.
- Ein Content-Review-Agent hatte über sechs Wochen eine Sub-Agent-Kette von fünf Ebenen aufgebaut. Nach Rückführung auf zwei Ebenen — Orchestrator plus ein einziger Research-Agent — bei gleicher Output-Qualität: Einsparung ~ € 2.200 monatlich.
Neue Prognose nach 14 Tagen Optimierung: € 4.100 pro Monat. Halbierung ohne Feature-Verlust, ohne Model-Downgrade, ohne Vertragsneuverhandlung. Der einzige Verzicht war der auf agentic drift — was, in der Rückschau, keine Fähigkeit war, sondern ein Bug.
Was diese Woche noch passieren sollte.
- Cache-Hit-Rate messen. Falls unter 60 %: prüft eure Prompt-Prefixe auf variable Elemente (Timestamps, User-IDs, Session-Tokens). Statisch bauen, das Variable ans Ende.
-
Retry-Layer-Audit. Grep euren Codebase nach
retry,backoff,maxAttempts. Prüft, wie viele Schichten davon aktiv sind. Ziel: eine. - Ein Team-Runden-Dashboard bauen. Drei Metriken pro Workflow: Cache-Hit-Rate, Requests-pro-Runde, Latenz-Standardabweichung. Provider-Dashboards haben das oft nicht; eigene Instrumentierung ist nötig.
- Für Agent-Workflows: Product-Owner-Review der Sub-Agent-Tiefe. Jede Ebene über zwei braucht eine explizite Rechtfertigung. Ohne Rechtfertigung: zurückschneiden.
Diese vier Zeilen sind meistens der Unterschied zwischen einer KI-Rechnung, die proportional zum Wert-Beitrag mitwächst — und einer, die durch strukturelle Leaks expandiert, während der Wert-Beitrag stagniert.
Diese Notiz basiert auf zusammengefasstem Muster aus laufenden Mandaten 2026. Konkrete Zahlen sind anonymisiert und für Vergleichbarkeit gerundet. Wenn ihr eine eigene Kostenkurve analysiert haben wollt: Erstgespräch — 30 Minuten reichen für eine erste Verortung.