Leitfaden zur Kostenoptimierung
Beherrschen Sie die Techniken zur Kostenkontrolle bei Claude Code und erreichen Sie mit weniger Tokens mehr
Auf dieser Seite
Leitfaden zur Kostenoptimierung¶
Mit Claude Code macht das Programmieren Spaß. Wenn Sie die Nutzung jedoch nicht im Blick behalten, kann Ihre Rechnung Sie „überraschen“. Dieser Leitfaden hilft Ihnen zu verstehen, wie Kosten entstehen, und zeigt, wie Sie Ihre Ausgaben sinnvoll steuern, ohne Effizienz einzubüßen.
Die Token-Abrechnung verstehen¶
Bevor Sie Kosten optimieren, sollten Sie die Logik hinter der Abrechnung kennen: Tokens.
Was ist ein Token¶
Ein Token ist die kleinste Texteinheit, die ein KI-Modell verarbeitet. Sie können es sich als „Wort“ des Modells vorstellen:
- Englisch: 1 Token ≈ 4 Zeichen bzw. 0,75 Wörter
- Chinesisch: 1 chinesisches Schriftzeichen ≈ 1-2 Tokens (durchschnittlich ca. 1,5 Tokens)
- Code: Variablennamen, Schlüsselwörter und Symbole benötigen jeweils unterschiedlich viele Tokens
Schnelle Orientierung für die Schätzung:
| Inhalt | Ungefähre Zeichen/Zeilen | Ungefähre Token-Anzahl |
|---|---|---|
| Eine kurze chinesische Anforderungsbeschreibung | 100 Zeichen | ~150 Tokens |
| Eine TypeScript-Datei mit 200 Zeilen | ~5.000 Zeichen | ~1.500 Tokens |
| Eine typische Konversationseingabe mit Kontext | — | 5.000-20.000 Tokens |
| Claude Code System-Prompt | — | ~8.000 Tokens |
Input- vs. Output-Tokens¶
Jede Interaktion mit Claude setzt sich bei der Abrechnung aus zwei Teilen zusammen:
Total Cost = Input tokens × Input rate + Output tokens × Output rate
Wichtig: Output-Tokens sind in der Regel 5-mal so teuer wie Input-Tokens. Am Beispiel von Sonnet 5:
| Typ | Preis (USD/Million Tokens) | Kosten pro 1.000 Tokens |
|---|---|---|
| Input | $2.00 | $0.002 |
| Output | $10.00 | $0.010 |
| Cache Read | $0.20 | $0.0002 |
Das bedeutet: Wenn Claude lange Inhalte generiert, ist das teurer, als wenn Sie mehr Kontext bereitstellen.
Wie viele Tokens verbraucht eine typische Konversation¶
Am Beispiel von Sonnet 5 hier Kostenschätzungen für einige häufige Szenarien:
| Szenario | Input-Tokens | Output-Tokens | Geschätzte Kosten |
|---|---|---|---|
| Einfache Frage und Antwort (Erklärung eines Code-Snippets) | 3.000 | 500 | $0.011 |
| Eine Funktion ändern | 8.000 | 1.500 | $0.031 |
| Eine neue Komponente erstellen (inklusive Lesen von Dateien) | 15.000 | 3.000 | $0.060 |
| Entwicklung komplexer Funktionen (Konversation über mehrere Runden) | 50.000 | 15.000 | $0.250 |
| Umfangreiches Refactoring (10+ Dateien) | 200.000 | 50.000 | $0.900 |
Die obigen Zahlen dienen nur als Orientierung. Die tatsächlichen Kosten hängen von Ihrem Code-Umfang, der Anzahl der Gesprächsrunden und der Kontextgröße ab.
Strategie zur Modellauswahl¶
Die Wahl des passenden Modells ist der direkteste Weg, Geld zu sparen. Die Preisunterschiede zwischen den Modellen sind erheblich.
Die Positionierung der drei Modelle¶
| Modell | Input-Preis | Output-Preis | Positionierung |
|---|---|---|---|
| Haiku 4.5 | $1.00 | $5.00 | Leichtgewichtig und schnell, für einfache Alltagsaufgaben |
| Sonnet 5 | $2.00 | $10.00 | Bestes Gleichgewicht, Hauptmodell |
| Opus 5 | $5.00 | $25.00 | Aktuelles Flaggschiff, zum selben Preis wie 4.7 |
| Opus 4.7 | $5.00 | $25.00 | Vorheriges Flaggschiff, weiterhin verfügbar |
Kostenvergleich: Dieselbe mäßig komplexe Aufgabe (10K Input-, 3K Output-Tokens) abzuschließen kostet:
- Haiku: $0.025
- Sonnet: $0.050
- Opus: $0.125
Sonnet 5 kostet das 2-Fache von Haiku, Opus 5 das 5-Fache von Haiku.
Grundsätze der Modellauswahl¶
Use Sonnet as your daily default (80% of tasks can be handled by it)
Only switch to Opus for:
- Complex architecture design and technical decisions
- Large-scale code refactoring
- Cross-module modifications involving multiple systems
- Difficult bugs requiring deep reasoning
Only switch to Haiku for:
- Simple format conversions
- Generating repetitive code (like CRUD endpoints)
- Quick Q&A (questions answerable in one sentence)
- Code comments and documentation generation
Mit dem Befehl /model können Sie jederzeit wechseln:
/model sonnet # Switch to Sonnet
/model opus # Switch to Opus
/model haiku # Switch to Haiku
Kontextverwaltung – Tipps zur Kostensenkung¶
Die Kontextverwaltung ist der Kern der Kostenoptimierung. Bei jedem Gesprächsdurchlauf sendet Claude die gesamte vorherige Gesprächshistorie erneut – je länger das Gespräch, desto mehr Input-Tokens pro Durchlauf.
/compact zur Komprimierung der Historie¶
Wenn das Gespräch mehr als 10 Durchläufe umfasst oder Sie bemerken, dass die Antworten langsamer werden, verwenden Sie /compact:
/compact
/compact veranlasst Claude, die vorherige Gesprächshistorie in einer kompakten Zusammenfassung zusammenzufassen und diese an die Stelle der vollständigen Historie zu setzen. Das reduziert die Input-Tokens für den nächsten Durchlauf erheblich.
Wann verwenden:
- Das Gespräch umfasst mehr als 10 Durchläufe
- Eine Teilaufgabe ist abgeschlossen und die nächste soll beginnen
- Die Antworten von Claude werden schlechter (Hinweis auf Kontextüberlastung)
/clear für einen Neuanfang¶
Wenn Sie zu einem völlig anderen Thema wechseln, verwenden Sie /clear ohne zu zögern:
/clear
Wann verwenden:
- Wechsel von der Entwicklung von Funktion A zu Funktion B
- Debugging abgeschlossen, neuer Code soll geschrieben werden
- Das Gespräch ist vom Thema abgewichen, Sie möchten neu beginnen
Kosten ohne /clear: Wenn Ihre vorherige Gesprächshistorie 50K Tokens umfasst, zahlen Sie bei jedem Durchlauf im neuen Thema unnötig für diese 50K Tokens. Zu Sonnet-Preisen sind das $0,15 extra pro Durchlauf. 10 Durchläufe = $1,5 verschwendet.
Präzise @-Referenzierung¶
Der Kostenunterschied zwischen Claude selbst nach Dateien suchen lassen und Dateien direkt referenzieren ist erheblich:
# Expensive! Claude may search dozens of files to find relevant code
"Help me modify the email validation part of user registration logic"
# Cheap! Directly tell Claude where to look
"Modify the regex in the validateEmail method in @src/services/auth-service.ts"
Wenn Sie wissen, welche Datei geändert werden muss, verwenden Sie stets @ für eine direkte Referenz. Claude auf eigene Faust suchen zu lassen ist nicht nur teurer, sondern auch weniger präzise.
.claudeignore zum Ausschluss großer Dateien¶
Stellen Sie sicher, dass die folgenden Dateitypen in .claudeignore aufgeführt sind:
# These files consume massive tokens if read by Claude
node_modules/ # Tens of thousands of files
dist/ # Build output
*.min.js # Minified JS
*.sql # Database dump
*.csv # Data files
package-lock.json # Lock file (enormous content)
pnpm-lock.yaml # Lock file
yarn.lock # Lock file
Realer Fall: Ein Nutzer stellte ungewöhnlich hohe Kosten fest und entdeckte, dass Claude beim Durchsuchen des Codes eine 50MB SQL-Dump-Datei gelesen hatte – in einem Durchlauf wurden dabei ca. 15M Tokens verbraucht (~$45 an Input-Kosten).
Nutzung von Caching¶
Prompt Caching ist eine sehr wichtige Kostensenkungsfunktion der Claude-API.
Was ist Prompt Caching¶
Bei aufeinanderfolgenden Mehrdurchlauf-Gesprächen wird jeder Durchlauf mit allen vorherigen Inhalten erneut gesendet. Ohne Caching wird jedes Mal zum vollen Input-Preis abgerechnet. Mit Caching:
- Erster Sendevorgang: Abrechnung zum normalen Input-Preis (Cache-Schreibvorgang etwas teurer)
- Folgende Sendevorgänge: Gleiche Inhalte treffen auf den Cache, Abrechnung zum Cache-Lese-Preis (nur 1/10)
Am Beispiel von Sonnet 5:
| Typ | Preis/Mio. Tokens | Im Vergleich zum normalen Input |
|---|---|---|
| Normaler Input | $2.00 | 100% |
| Cache-Schreibvorgang | $2.50 | 125% |
| Cache-Lesevorgang | $0.20 | 10% |
Das bedeutet, dass Cache-Treffer nur 1/10 des Preises kosten.
Cache-Vorteile maximieren¶
Caching erfolgt automatisch, doch Sie können die Cache-Trefferrate durch Ihre Nutzungsgewohnheiten verbessern:
Gespräche zusammenhängend halten:
# Good habit: Continue developing the same feature in one conversation
> "Create UserService basic structure"
> "Add getUserById method" # Previous content hits cache
> "Add updateUser method" # Previous content hits cache
> "Add unit tests" # Previous content hits cache
# Bad habit: /clear after every sentence
> "Create UserService basic structure"
> /clear
> "Add getUserById method to UserService" # Cannot leverage cache
> /clear
> "Add updateUser method to UserService" # Cannot leverage cache
CLAUDE.md nicht häufig ändern:
Der Inhalt von CLAUDE.md wird bei jedem Gesprächsdurchlauf gesendet. Wenn der Inhalt stabil bleibt, trifft er langfristig auf den Cache. Häufige Änderungen führen zur Cache-Invalidierung.
Sinnvoller Zeitpunkt für /compact:
/compact ersetzt die Historie und führt zur Cache-Invalidierung. Verwenden Sie es daher nicht zu häufig – nur wenn das Gespräch wirklich zu lang ist.
Wie viel bringt Caching¶
Angenommen, ein Gespräch umfasst 10 Durchläufe mit jeweils ca. 20K Input-Tokens (einschließlich Historie):
| Ohne Cache | Mit Cache (90% Trefferquote) | |
|---|---|---|
| Gesamte Input-Tokens | 200K | 200K |
| Zum normalen Preis abgerechnet | 200K | 20K |
| Zum Cache-Preis abgerechnet | 0 | 180K |
| Gesamte Input-Kosten (Sonnet) | $0.60 | $0.114 |
| Ersparnis | — | $0.486 (81%) |
Caching kann ca. 80% der Input-Kosten einsparen.
Überwachung und Budgetierung¶
Gewöhnen Sie sich an, Ihre Kosten im Blick zu behalten, damit Sie nicht unbemerkt zu viel ausgeben.
Aktuelle Sitzung mit /cost anzeigen¶
Geben Sie in Claude Code jederzeit Folgendes ein:
/cost
Es zeigt die verbrauchten Tokens und die geschätzten Kosten der aktuellen Sitzung an. Prüfen Sie den Wert nach jeder abgeschlossenen Aufgabe.
Verlauf im QCode.cc Dashboard¶
Melden Sie sich in der QCode.cc Console an. Auf der Seite „Nutzungsstatistik“ sehen Sie:
- Details zu Modellaufrufen: Modell, Token-Anzahl und Kosten pro Aufruf
- Tages-/Monatsübersichten: Diagramme zum Kostenverlauf
- Verbrauchsfortschritt des Tarifs: Prozentsatz des bereits genutzten Tarif-Kontingents
Gewöhnen Sie sich an, täglich einen Blick ins Dashboard zu werfen, um ungewöhnlichen Verbrauch frühzeitig zu erkennen.
Empfehlungen zur Kostenkontrolle¶
| Nutzungsintensität | Empfohlene Modellstrategie | Monatsbudget (Richtwert) |
|---|---|---|
| Leichte Nutzung (1–2 Stunden täglich) | Hauptsächlich Sonnet | $30-80 |
| Mittlere Nutzung (3–5 Stunden täglich) | Sonnet + gelegentlich Opus | $80-200 |
| Intensive Nutzung (ganztägige Entwicklung) | Sonnet als Hauptmodell + Opus für Architekturentscheidungen | $200-500 |
Häufige Kostenfallen¶
Die folgenden Situationen verschwenden am leichtesten Tokens. Prüfen Sie, ob eine davon auf Sie zutrifft:
Falle 1: Große Dateien direkt einfügen¶
# Wrong approach: Pasting file content into the conversation
> "Here's my code, help me review it:
[pasted 500 lines of code]"
# Correct approach: Use @ reference
> "Review the createOrder method in @src/services/order-service.ts"
Der Unterschied: 500 eingefügte Zeilen entsprechen etwa 1.500 Input-Tokens, und diese werden in jeder Gesprächsrunde erneut gesendet. Wenn Sie dieselbe Datei per @ referenzieren, liest Claude sie nur bei Bedarf, und der gelesene Inhalt wird zwischengespeichert.
Falle 2: Denselben fehlgeschlagenen Befehl wiederholt ausführen¶
# Wrong approach: Asking Claude to run the same failed command repeatedly
> "Run npm run build"
# Failed
> "Try again"
# Still failed
> "One more time"
# Correct approach: Analyze the failure reason and try a different approach
> "Run npm run build"
# Failed
> "Look at the error logs, analyze the failure reason, fix the issue, then build"
Bei jedem Wiederholungsversuch wird der gesamte Gesprächsverlauf (einschließlich aller bisherigen fehlgeschlagenen Ausgaben) erneut gesendet, sodass der Token-Verbrauch schnell anwächst.
Falle 3: Vergessenes /clear führt zu aufgeblähtem Kontext¶
Dies ist die am besten versteckte Kostenfalle:
# Morning: Fixed a bug (conversation accumulated 30K tokens of history)
# Afternoon: Started writing a new feature, but no /clear
# Every turn of the new conversation carries the morning's 30K tokens unnecessarily
# Fix: Develop the habit of /clear when switching tasks
/clear
> "Now starting development of the new feature..."
Falle 4: Opus für einfache Aufgaben verwenden¶
# Wasteful: Using Opus to generate a simple interface
/model opus
> "Help me define a User interface with id, name, email fields"
# Savings: Haiku is sufficient for simple tasks
/model haiku
> "Help me define a User interface with id, name, email fields"
Die Ausgabe beider Modelle ist bei dieser Aufgabe nahezu identisch, Opus kostet jedoch das Fünffache.
Falle 5: Claude das gesamte Projekt durchsuchen lassen¶
# Expensive: Claude may read dozens of files
> "Find the code that handles payments in the project"
# Cheap: Tell it roughly where to look
> "Find the service handling payments in @src/services/"
# Cheapest: Specify the file directly
> "Check @src/services/payment-service.ts"
Checkliste zur Kostenoptimierung¶
Gehen Sie diese Checkliste bei jeder Nutzung von Claude Code durch:
- [ ] Das passende Modell gewählt (für die meisten Aufgaben Sonnet verwenden)
- [ ]
@-Referenzen statt eingefügter Dateiinhalte verwendet - [ ] Beim Themenwechsel
/clearausgeführt - [ ]
/compacterwogen, wenn die Unterhaltung mehr als 10 Runden umfasst - [ ]
.claudeignoreso konfiguriert, dass große Dateien ausgeschlossen werden - [ ] Anforderungsbeschreibung ausreichend klar formuliert (Nacharbeit durch Missverständnisse vermeiden)
- [ ]
/costgeprüft, um den aktuellen Verbrauch zu kennen
Wenn Sie sich diese Gewohnheiten angeeignet haben, werden Sie feststellen, dass sich die Kosten um 30–50 % senken lassen, ohne dass die Entwicklungseffizienz darunter leidet.
Prompt Caching und Kosten¶
Wir haben bereits erwähnt, dass ein Cache-Treffer nur 1/10 des Input-Preises kostet. Dieser Abschnitt erklärt, warum das so ist und wie Sie Ihren Kontext gezielt so gestalten, dass Sie den Cache-Vorteil maximal nutzen.
Nur stabile Präfixe werden gecacht¶
Das Prompt Caching der Claude API cacht das stabile Präfix Ihres Prompts, also den unveränderten Anfang: den System-Prompt, CLAUDE.md, umfangreiches Hintergrundmaterial usw. Einmal gecacht, kostet das Lesen dieses Teils nur etwa 10 % des normalen Inputs (rund 90 % günstiger). Entscheidend ist, dass der Cache nach Präfix arbeitet: Sobald sich etwas am Anfang des Präfixes ändert, wird der gesamte Cache ab der Änderungsstelle ungültig.
Das zentrale Spar-Prinzip lautet daher: Stellen Sie unveränderliche Inhalte an den Anfang und bearbeiten Sie sie möglichst nicht.
| Inhaltstyp | Platzierung | Cache-Eignung |
|---|---|---|
| System-Prompt, CLAUDE.md | Ganz vorn (stabil) | Hoch, dauerhafte Treffer |
| Projektkonventionen, API-Dokumentation, umfangreicher Hintergrund | Früh (stabil) | Hoch |
| Konkrete Anweisungen für die aktuelle Aufgabe | Später | Niedrig (ändern sich naturgemäß) |
| Laufender Gesprächsverlauf | Am Ende | Wächst mit dem Gespräch |
Kontext cachefreundlich gestalten¶
- Knappe, stabile CLAUDE.md: Inhalte mit hohem Informationswert, selten bearbeitet. Eine häufig geänderte CLAUDE.md macht den gesamten nachfolgenden Cache ungültig und erzwingt jedes Mal eine Neuberechnung zum vollen Preis.
- Sitzungen wiederverwenden: Führen Sie dieselbe Aufgabe innerhalb einer Sitzung weiter, damit das Präfix identisch bleibt und jede weitere Runde vom Preis für Cache-Lesezugriffe profitiert.
- Per Pfad referenzieren statt einfügen: Verwenden Sie
@path, um Dateien zu referenzieren, statt Inhalte in die Unterhaltung einzufügen. Das reduziert Tokens und verhindert zugleich, dass veränderliche Inhalte ins Präfix gelangen und den Cache zerstören. - /compact sparsam einsetzen:
/compactschreibt die Zusammenfassung des Verlaufs neu, ändert damit faktisch das Präfix und macht den vorhandenen Cache ungültig. Nutzen Sie es nur, wenn die Unterhaltung wirklich zu lang ist.
In einem Satz: Stabiles zuerst, Veränderliches zuletzt, und das Präfix nicht leichtfertig ändern – so sichern Sie sich den Cache-Rabatt mit minimalem Aufwand. Tipps zu Kontexthierarchie und Kürzung finden Sie ergänzend im Modellauswahl-Leitfaden.
Modell-Routing nach Rolle¶
„Täglich Sonnet verwenden“ ist ein guter Ausgangspunkt, noch wirtschaftlicher ist es jedoch, das Modell nach Aufgabenrolle zu wählen: Jede Art von Arbeit läuft auf dem kosteneffizientesten Modell, statt durchgehend ein einziges Modell zu nutzen.
Routing nach Rolle¶
| Aufgabenrolle | Empfohlenes Modell | Typische Szenarien |
|---|---|---|
| Nachschlagen / Formatieren / einfaches Umschreiben | Haiku 4.5 | Dokumentationsrecherche, Formatkonvertierung, Kommentare bearbeiten, Antworten in einem Satz |
| Alltägliche Implementierung / Bugfix | Sonnet 5 | Features schreiben, Logik ändern, routinemäßiges Debugging (~80 % der Arbeit). 4.6 weiterhin erhältlich |
| Architektur / großes Refactoring / Orchestrierung | Opus 5 | Modulübergreifendes Design, umfangreiches Refactoring, mehrstufige Orchestrierung, anspruchsvolles Reasoning. 4.8 weiterhin erhältlich |
| Coding im Codex-Stil | gpt-5.6-terra | Codegenerierung in Workflows im Codex-Stil |
Die Kernidee: Setzen Sie Opus nicht für triviale Aufgaben ein. Bei einer einfachen Interface-Definition liefern Haiku und Opus nahezu identische Ergebnisse, Opus kostet aber 5-mal so viel. Heben Sie sich das schwere Modell für die Schritte auf, die wirklich tiefes Reasoning erfordern.
Wechsel mitten in der Sitzung¶
Mit /model können Sie jederzeit wechseln, ohne die Sitzung neu zu starten:
/model haiku # Drop to a lightweight model for simple steps
/model sonnet # Switch back to the primary model to keep implementing
/model opus # Temporarily upgrade when hitting an architecture decision
Ein effizienter Spar-Rhythmus: Treiben Sie den Großteil der Entwicklung mit Sonnet voran, wechseln Sie für einen Architektur-Knackpunkt vorübergehend mit /model opus und kehren Sie nach der Entscheidung zu Sonnet zurück; übergeben Sie umfangreiche einfache Aufräumarbeiten an Haiku. Einen detaillierteren Vergleich der Fähigkeiten pro Modell und Auswahlempfehlungen finden Sie im Modellauswahl-Leitfaden.