Du zahlst nicht für die Antwort. Du zahlst für den Kontext.
Das ist die eine Erkenntnis, die den Unterschied macht zwischen einem AI-Setup das 200 € im Monat verbrennt und einem das 15 € kostet — bei gleicher Qualität.
Die meisten AI Builder, Solopreneure und Entwickler optimieren an der falschen Stelle. Sie experimentieren mit Prompts, testen neue Modelle, bauen komplexe Agenten. Aber sie schauen nie auf das, was tatsächlich Geld kostet: wie viel Kontext sie bei jedem einzelnen API-Call mitschicken.
Dieser Artikel zeigt, warum deine ChatGPT- und Claude-Setups wahrscheinlich 5-10x teurer sind als nötig. Und was du konkret dagegen tun kannst.
Das Token-Problem: Warum AI plötzlich teuer wird
Ein Claude Sonnet-Call mit 1.000 Tokens Input und 500 Tokens Output kostet rund 0,01 €. Klingt harmlos.
Derselbe Call nach 20 Nachrichten in einer Konversation: 80.000 Tokens Input, 500 Tokens Output. Kosten: 0,25 € — für eine einzige Antwort.
Das ist kein Bug. Das ist das Standardverhalten jeder Chat-API. Jede neue Nachricht sendet den gesamten bisherigen Verlauf als Kontext mit. Die Conversation History wächst linear, die Kosten wachsen mit.
Bei Agenten wird es schlimmer. Ein Agent der in einer Loop arbeitet — Tool aufrufen, Ergebnis verarbeiten, nächsten Schritt planen — akkumuliert pro Iteration den kompletten vorherigen Kontext. Nach 10 Iterationen schickst du bei jedem Call den 10-fachen Kontext mit.
Das ist Token Explosion. Und die meisten Builder bemerken es erst auf der Rechnung.
Die tatsächlichen Kosten: Ein Realitätscheck
Hier die aktuellen Preise pro 1 Million Tokens (Stand Mai 2026):
| Modell | Input | Output | Context Window |
|---|---|---|---|
| Claude Opus 4 | $15 | $75 | 200K |
| Claude Sonnet 4 | $3 | $15 | 1M |
| Claude Haiku 3.5 | $0,80 | $4 | 200K |
| GPT-4o | $2,50 | $10 | 128K |
| GPT-4.1 | $5 | $15 | 1M |
| GPT-4.1 Mini | $0,40 | $1,60 | 1M |
Die Differenz zwischen dem teuersten und günstigsten Modell: Faktor 37 beim Input, Faktor 47 beim Output.
Wer Opus für eine Aufgabe nutzt, die Haiku genauso gut erledigt, zahlt 19x mehr. Pro Call. Bei einem Agenten mit 50 Calls pro Task ist das der Unterschied zwischen 0,03 € und 0,57 €. Bei 100 Tasks am Tag: 1,70 € vs. 57 €.
Das ist kein Optimierungsproblem. Das ist ein Architekturproblem.
Warum große Context Windows gefährlich sind
Claude Sonnet hat ein Context Window von 1 Million Tokens. Das klingt nach einem Feature. In der Praxis ist es eine Kostenfalle.
Ein großes Context Window ist eine Kapazität, kein Auftrag.
Die meisten Builder denken: „Ich kann dem Modell einfach alles geben, dann findet es schon die richtige Information.” Das funktioniert — technisch. Aber es ist, als würdest du für jede Google-Suche das komplette Internet herunterladen.
Drei Probleme mit Full-Context-Ansätzen:
1. Lineare Kostenexplosion. Jedes Token im Input kostet. 100K Tokens Kontext bei Sonnet = 0,30 € pro Call. Bei 20 Calls pro Session: 6 €. Für eine Aufgabe, die mit 5K Tokens Kontext identisch gut funktioniert hätte.
2. Qualitätsverlust. Studien zeigen konsistent: LLMs performen schlechter, je mehr irrelevanter Kontext im Window liegt. Das „Lost in the Middle”-Problem ist real. Mehr Kontext bedeutet oft schlechtere Antworten.
3. Latenz. Mehr Input-Tokens = längere Time-to-First-Token. Bei interaktiven Anwendungen spürbar. Bei Agenten-Loops summiert sich die Latenz über Iterationen.
Die Lösung ist nicht, das Context Window zu ignorieren. Die Lösung ist Context Engineering — bewusst steuern, was reinkommt.
Context Engineering: Die eigentliche Kernkompetenz
Context Engineering ist der Unterschied zwischen einem teuren AI-Setup und einem effizienten. Es bedeutet: bei jedem API-Call genau die Informationen liefern, die für diese spezifische Aufgabe relevant sind. Nicht mehr, nicht weniger.
Das klingt offensichtlich. In der Praxis machen es die wenigsten.
Strategie 1: Selective Context Loading
Statt dem Modell ein ganzes Dokument zu geben, extrahierst du vorher die relevanten Abschnitte. Statt einer kompletten Datenbank den spezifischen Datensatz. Statt der gesamten Konversationshistorie die letzten 3 relevanten Nachrichten plus eine Zusammenfassung.
Vorher: 80.000 Tokens Input → 0,24 € pro Call (Sonnet) Nachher: 5.000 Tokens Input → 0,015 € pro Call Ersparnis: 94 %
Strategie 2: Retrieval statt Full Context
Wer mit Dokumenten arbeitet, sollte nie das komplette Dokument in den Kontext laden. RAG (Retrieval-Augmented Generation) existiert genau dafür: relevante Chunks per Embedding-Suche finden, nur diese dem Modell geben.
Das gilt auch für Code. Wenn ein Claude Code-Agent eine Datei analysieren soll, braucht er selten die ganze Datei. Die relevante Funktion plus Typ-Definitionen reichen fast immer.
Strategie 3: Context Compression
Conversation History muss nicht wörtlich mitgeschickt werden. Ein günstiger Haiku-Call kann 20 Nachrichten zu einer 200-Token-Zusammenfassung komprimieren. Diese Zusammenfassung ersetzt die 20 Nachrichten im nächsten Call.
Kosten der Kompression: ~0,001 € Ersparnis pro folgendem Call: 0,05-0,20 €
Das rechnet sich ab dem zweiten Call.
Strategie 4: Klare System-Prompts
Ein guter System-Prompt ist kurz, präzise und aufgabenspezifisch. Kein Roman. Keine „Du bist ein hilfreicher Assistent”-Floskeln.
Schlecht (850 Tokens):
Du bist ein erfahrener Marketingexperte mit 15 Jahren Erfahrung im B2B-SaaS-Bereich. Du kennst alle modernen Marketing-Frameworks, bist vertraut mit Growth Hacking, Content Marketing, SEO, Paid Ads…
Gut (120 Tokens):
Schreibe LinkedIn-Posts für B2B-SaaS. Tonalität: direkt, operativ. Format: Hook + 3 Absätze + CTA. Max 200 Wörter.
Beide liefern vergleichbare Ergebnisse. Der erste kostet 7x mehr Input-Tokens — bei jedem einzelnen Call.
Wer System-Prompts für Claude strukturiert aufbaut, spart bei produktiver Nutzung hunderte Euro im Monat.
Model-Tiering: Das richtige Modell pro Aufgabe
Die teuerste Fehlentscheidung in AI-Setups: für alles dasselbe Modell nutzen.
Ein Multi-Agent-System mit 15 Agenten, das für jeden Agenten Opus nutzt, verbrennt Geld. Die Realität: 80 % der Aufgaben in einer Pipeline brauchen kein Frontier-Modell.
Die Faustregel für Model-Tiering:
| Aufgabe | Empfohlenes Modell | Kosten-Faktor |
|---|---|---|
| Klassifizierung, Routing, Extraktion | Haiku / GPT-4.1 Nano | 1x |
| Zusammenfassung, Analyse, Transformation | Sonnet / GPT-4o | 4-6x |
| Komplexes Reasoning, Kreation, Planung | Opus / GPT-4.1 | 19-37x |
Ein Topic-Ranker-Agent der 60 Headlines bewertet, braucht kein Opus. Haiku reicht — bei 1/19 der Kosten. Ein Visual Orchestrator der Sub-Agents koordiniert, braucht Reasoning-Power. Da ist Sonnet oder Opus gerechtfertigt.
In der Praxis sieht die Kostenverteilung einer optimierten Pipeline so aus: 2-3 teure Calls für die Kernlogik, 10-15 günstige Calls für Routing, Extraktion und Formatierung. Gesamtkosten pro Task: unter 0,05 €.
Prompt Caching: Der größte Einzelhebel
Anthropic bietet Prompt Caching für die Claude API. Und es ist der effektivste Kostensenker, den die meisten Builder ignorieren.
So funktioniert es: Wenn du bei mehreren API-Calls denselben Kontext-Block sendest (System-Prompt, Dokumentation, Schema-Definitionen), wird dieser Block gecacht. Wiederholte Calls zahlen nur 10 % des normalen Input-Preises für den gecachten Teil.
| Ohne Caching | Mit Caching | |
|---|---|---|
| System-Prompt (2.000 Tokens) × 100 Calls | 0,60 € (Sonnet) | 0,07 € |
| Dokument-Kontext (20.000 Tokens) × 50 Calls | 3,00 € | 0,33 € |
| Schema + Tools (5.000 Tokens) × 200 Calls | 3,00 € | 0,33 € |
Ersparnis: 89 % auf wiederholte Kontextblöcke.
Für Agenten, die in Loops arbeiten und bei jedem Durchlauf denselben System-Prompt senden, ist Prompt Caching nicht optional. Es ist Pflicht.
Cache-Writes kosten einen Aufschlag (1,25x für 5-Minuten-Cache). Aber ab dem zweiten Read rechnet es sich. Bei Agenten mit 10+ Iterationen spart es massiv.
Warum AI-Agenten oft ineffizient arbeiten
Die meisten AI-Agenten sind architektonisch verschwenderisch. Nicht weil die Logik falsch ist, sondern weil der Kontextfluss nicht durchdacht ist.
Problem 1: Conversation Accumulation
Ein Agent der in einer Chat-Loop arbeitet, akkumuliert bei jeder Iteration den gesamten Verlauf. Nach 15 Tool-Calls sind 80 % des Kontexts vergangene Tool-Aufrufe und deren Ergebnisse — irrelevant für den aktuellen Schritt.
Lösung: Nach jedem Schritt den Kontext komprimieren. Nur das Ergebnis behalten, nicht den Weg dorthin. Oder: Agenten mit striktem Working-Memory statt Conversation-History bauen.
Problem 2: Monolithische Agenten
Ein einzelner Agent der alles können soll — recherchieren, analysieren, schreiben, formatieren — braucht einen riesigen System-Prompt und akkumuliert Kontext aus allen Phasen.
Lösung: Task-Splitting. Separate Agenten für separate Aufgaben. Ein Recherche-Agent (Haiku, klein) übergibt sein Ergebnis an einen Analyse-Agent (Sonnet, mittel), der an einen Writing-Agent (Sonnet, fokussiert) übergibt. Jeder Agent startet mit frischem, aufgabenspezifischem Kontext.
Wer Agenten in n8n baut, kann das mit Workflow-Nodes direkt umsetzen: jeder Node ein eigener Agent-Call mit eigenem Kontext.
Problem 3: Redundante Tool-Responses
Wenn ein Agent ein Tool aufruft und das Tool 5.000 Tokens zurückgibt, landen diese 5.000 Tokens im Kontext — für alle folgenden Calls. Auch wenn der Agent nur einen Satz daraus braucht.
Lösung: Tool-Responses vor der Rückgabe an den Agenten filtern oder zusammenfassen. Ein MCP-Server kann das direkt tun — wer einen eigenen MCP-Server baut, hat volle Kontrolle über die Response-Größe.
Problem 4: Fehlende Memory-Architektur
Viele Agenten nutzen den Konversationskontext als Gedächtnis. Das ist die teuerste Form von Memory. Jede „Erinnerung” wird bei jedem Call mitbezahlt.
Lösung: Externes Memory. Relevante Informationen in einer Datenbank oder Datei speichern, per Retrieval laden wenn nötig. Der Kontext bleibt klein. Das Memory bleibt persistent.
Runtime-Optimierung: Latency vs. Cost
Token-Kosten sind nur eine Dimension. Die andere: Latenz. Und beide hängen zusammen.
| Optimierung | Kosten-Effekt | Latenz-Effekt |
|---|---|---|
| Kleinerer Kontext | Günstiger | Schneller |
| Prompt Caching | Günstiger | Schneller (Cache-Hit) |
| Model-Tiering (Haiku statt Opus) | Günstiger | Deutlich schneller |
| Parallele Agent-Calls | Gleich | Schneller |
| Batch API (Anthropic) | 50 % günstiger | Langsamer (async) |
Für nicht-zeitkritische Aufgaben ist die Batch API ein Hebel: 50 % Rabatt auf alle Modelle gegen asynchrone Verarbeitung. Reporting, Analyse, Content-Generierung — alles was nicht sofort fertig sein muss.
Für interaktive Anwendungen: kleinerer Kontext und Caching reduzieren Time-to-First-Token. Ein Agent der mit 5K statt 80K Tokens Kontext arbeitet, antwortet nicht nur günstiger, sondern auch spürbar schneller.
Claude Code: Kosten im Griff behalten
Claude Code ist ein mächtiges Tool. Aber es kann teuer werden, wenn man es falsch nutzt.
Die häufigsten Kostentreiber bei Claude Code:
Ganze Repos lesen lassen. Claude Code liest Dateien Token für Token. Wer „lies dir mal das ganze Projekt durch” sagt, zahlt für jedes Byte. Besser: gezielt auf relevante Dateien verweisen.
Keine CLAUDE.md nutzen. Die CLAUDE.md ist persistenter Kontext, den Claude Code bei jedem Start lädt. Projektstruktur, Konventionen, Tech-Stack — einmal dokumentiert, spart es tausende Tokens an wiederholten Erklärungen.
Zwischen Tasks nicht aufräumen. /clear zwischen unabhängigen Aufgaben verhindert, dass der Kontext einer abgeschlossenen Aufgabe in die nächste überläuft.
Zu vage Anweisungen. „Verbessere den Code” führt zu breitem Scanning. „Optimiere die Funktion processOrder in src/lib/orders.ts für Error Handling” führt zu gezieltem, günstigem Zugriff.
Die Checkliste: Token-Kosten sofort reduzieren
Hier die Maßnahmen nach Impact sortiert — starte oben:
Sofort umsetzbar (5 Minuten):
- Prompt Caching aktivieren (90 % Ersparnis auf wiederholte Blöcke)
- System-Prompts kürzen und präzisieren
/clearzwischen unabhängigen Tasks in Claude Code
Kurzfristig (1-2 Stunden):
- Model-Tiering einführen: Haiku für einfache Tasks, Sonnet für mittlere, Opus nur für komplexe
- Batch API für nicht-zeitkritische Aufgaben nutzen (50 % Rabatt)
- Conversation History nach N Nachrichten komprimieren
Mittelfristig (1-2 Tage):
- RAG-Pipeline für dokumentenbasierte Workflows aufsetzen
- Agent-Architektur auf Task-Splitting umbauen
- Lokale Modelle für einfache Aufgaben evaluieren (0 € Token-Kosten)
- Externes Memory statt Conversation-basiertes Gedächtnis
Langfristig (Architektur-Entscheidungen):
- MCP-Server für kontrollierte Tool-Responses bauen
- Multi-Agent-Pipeline mit spezialisierten Sub-Agenten
- Cost-per-Task-Monitoring einrichten
- Token-Budgets pro Agent und Task definieren
Fazit: Tokens sparen ist eine Architekturentscheidung
Die meisten AI-Kosten entstehen nicht durch teure Modelle. Sie entstehen durch schlechte Architektur: zu viel Kontext, falsche Modellwahl, fehlende Kompression, monolithische Agenten.
Die Hebel sind klar:
- Context Engineering statt Full-Context → 60-90 % weniger Tokens
- Model-Tiering statt One-Model-fits-all → 5-19x günstiger pro Task
- Prompt Caching → 90 % auf wiederholte Blöcke
- Task-Splitting statt monolithischer Agenten → kleinere, günstigere Calls
Wer diese Prinzipien umsetzt, kann mit demselben Budget 10x mehr Tasks ausführen. Oder dieselben Tasks für ein Zehntel der Kosten.
Das ist kein Geheimwissen. Es ist die Basis, auf der jedes professionelle AI-System gebaut sein sollte. Und der Grund, warum die Teams die in Produktion arbeiten, nicht über Token-Kosten klagen — sie haben es richtig aufgebaut.
