Claude-Tokenkosten senken: Prompt Caching, MCP-Overhead, LSP und Modellwechsel

Eine Claude-Rechnung kann steigen, auch wenn niemand auf ein größeres Modell umsteigt. Meist steckt ein Haufen Tools dahinter, die geladen, aber nie aufgerufen werden. Das erste Anzeichen ist oft eine Session, die sich plötzlich zäh anfühlt, den Rest verraten die Nutzungszahlen. Bei vielen Entwicklern fressen immer dieselben paar Gewohnheiten das Budget auf, deshalb lohnt es sich, sie der Reihe nach durchzugehen.

Wohin das Geld fließt: Input-Tokens

Das Modell erinnert sich nicht an die vorherige Nachricht. In jeder Runde wird das komplette Gespräch erneut gesendet. Bei der zwanzigsten Nachricht zahlen Sie dafür, die ersten neunzehn noch einmal zu schicken, bevor überhaupt ein neues Wort entsteht.

Output-Tokens kosten etwa fünfmal so viel wie Input-Tokens, und diese Zahl zitiert jeder. In einem langen Chat bleibt der Output aber klein im Vergleich zum Input, und genau der Input sammelt sich an. Als grobe Faustregel: 100 Tokens entsprechen etwa 75 englischen Wörtern. Rechnen Sie das für eine einstündige Session durch, und die Summe wird schnell unangenehm. Input-Tokens wachsen mit jeder Runde, Output-Tokens nicht.

Prompt Caching, der Rabatt, den kaum jemand nutzt

Anthropic hält den Anfang eines Prompts im Cache, sofern er exakt übereinstimmt. Lesen aus dem Cache kostet ungefähr zehn Prozent des normalen Input-Preises. Ein Fehltreffer ist etwas teurer als gar kein Caching, denn das Anlegen eines Cache-Eintrags kostet einen Aufschlag von 1,25x auf den Grundpreis.

Standardmäßig lebt der Cache fünf Minuten, und jeder Treffer verlängert ihn kostenlos. Es gibt auch eine Ein-Stunden-Option, doch das Schreiben dorthin kostet das Doppelte.

Die Lebensdauer macht viel aus. Im März 2026 soll Claude Code vom Ein-Stunden-Cache auf den Fünf-Minuten-Cache umgestellt haben. Ein Entwickler ging seine eigenen API-Rechnungen durch und eröffnete ein GitHub-Issue. Mit dem Ein-Stunden-Cache entfiel etwa 1 % der Ausgaben auf das Neuschreiben des Caches. Nach der Umstellung lag der Anteil zwischen 15 % und 53 %.

Ein zweiter Entwickler modellierte eine Opus-Session mit 200K Tokens. Wer länger als fünf Minuten weg ist, muss bei der Rückkehr den gesamten Kontext neu schreiben lassen, jedes Mal etwa $1.25. Über einen ganzen Tag wurden manche Sessions bei identischer Arbeit 30 % bis 60 % teurer. Der einzige Unterschied war das Cachefenster.

Zurück innerhalb von fünf Minuten, und Sie zahlen ein Zehntel. Fenster verpasst, und Sie zahlen das 1,25-Fache.

Es gibt einen Haken: Die Übereinstimmung muss exakt sein. Jede Änderung am System-Prompt, jedes hinzugefügte oder entfernte Tool oder ein Modellwechsel mitten in der Session löscht den Cache. Laut Anthropics Dokumentation macht schon die Änderung einer einzigen Tool-Definition den gesamten Cache ungültig. Wie tolerant der Abgleich unter hoher Last ist, bleibt unklar, denn ausgelastete Sessions verhalten sich mitunter weniger vorhersehbar, als die Spezifikation nahelegt. Das Nutzungs-Dashboard ist ein verlässlicherer Maßstab als Kopfrechnen.

Praktisch heißt das: zuerst das Modell wählen, den System-Prompt stabil halten und keine Tools mittendrin hinzufügen. Wer über die API arbeitet und regelmäßig mehr als fünf Minuten zwischen den Runden pausiert, fährt mit dem Ein-Stunden-Cache womöglich günstiger.

MCP-Server sind nicht kostenlos

Jedes verbundene Tool fügt dem Prompt sein Schema hinzu: Name, Beschreibung und sämtliche Parameter. Diese Kosten fallen in jeder Runde an, solange das Tool geladen ist, ob es genutzt wird oder nicht.

Der Blogpost eines Entwicklers brachte viele dazu, das zu prüfen. Beim Start einer Claude-Code-Session mit mehreren MCP-Servern verbrauchten allein die Tools über 66.000 Tokens, bevor auch nur ein Wort getippt war. Das ist ein Drittel eines 200K-Fensters. /doctor zeigte, dass der echte Wert eher bei 82.000 lag, und ein einziger Suchserver mit 20 Tools machte rund 14.000 Tokens aus.

Es geht noch schlimmer. In einem GitHub-Issue vom November 2025 belegte ein Docker-MCP-Server mit 135 Tools allein etwa 126.000 Tokens, und der Melder bekam bei jedem Befehl eine "context low"-Warnung (Kontext knapp).

MCP lohnt sich, wenn strukturierter, wiederholter Zugriff auf einen Dienst gebraucht wird. Nicht aber, wenn es ungenutzt im Kontext herumliegt.

Neue Verbesserung. Im Januar 2026 kam Tool Search zu Claude Code. Würden MCP-Beschreibungen mehr als ein Zehntel des Kontexts belegen, bleiben ihre vollständigen Schemas aus dem Prompt heraus. Stattdessen gibt es ein schlankes Suchwerkzeug, und eine Definition wird erst dann geladen, wenn sie tatsächlich gebraucht wird. Anthropic nennt eine Senkung des Tool-Token-Overheads um rund 85 %.

Die laufende Gebühr ist geschrumpft, aber nicht verschwunden. Setups unterhalb der Schwelle laden weiterhin alle Schemas vorab. Andere Clients verzögern womöglich gar nichts. Und viele Tools schaden der Genauigkeit, selbst wenn sie billig sind. /context zeigt, wofür Sie tatsächlich bezahlen.

Kommandozeilen-Tools umgehen das ganze Problem. Das Modell kennt git, curl und die GitHub CLI bereits oder kann --help ausführen. Kein Schema, keine Dauerkosten. Für alles, was nur gelegentlich gebraucht wird, gewinnt die CLI.

Codesuche verbrennt mehr als gedacht

Grep sieht Code als reinen Text. Die Suche danach, wo User definiert ist, liefert jede Erwähnung: Klassen, Variablen, Kommentare, Importe, Stylesheet-Selektoren und Datenbankspalten.

Ein Bericht über ein echtes Projekt nannte 847 Treffer in 203 Dateien für genau diese Art von Suche, und das Modell las anschließend jeden davon, um die echte Definition zu finden. Laut Logs dauerte das Greppen bis zu einer Minute, während ein Language Server in etwa 50 ms antwortete.

Im kleineren Maßstab zeigt sich dasselbe Muster. In einem Repo mit 30K Zeilen lieferte grep für das Umbenennen einer Funktion 733 Treffer, von denen nur 501 relevant waren. Jeder überflüssige Treffer wird trotzdem gelesen und bezahlt. Wer das Modell auf einen LSP verweist, landet direkt bei den 501, was bei dieser einen Suche rund 13K Tokens sparte. Ob das Verhältnis anderswo hält, ist offen, bei beiden gemessenen Repos hielt es.

Langjährige Nutzer geben zwei Hinweise:

• Claude greift standardmäßig zu grep, selbst wenn LSP aktiviert ist. Ein Entwickler stellte fest, dass der LSP nur in etwa 1 % der Fälle zum Einsatz kam, bis ausdrückliche Anweisungen in CLAUDE.md standen.
• Grep hat weiterhin seinen Platz. Für Logs, Konfigurationen, String-Literale und alles, was kein Code-Symbol ist, ist es das richtige Werkzeug.

Grep liefert jeden Texttreffer, ein LSP liefert genau das angefragte Symbol.

Funktioniert der „Rede wie ein Höhlenmensch“-Trick?

Ein viel geteilter GitHub-Skill verspricht bis zu 65 % weniger Output-Tokens durch abgehackte, ungrammatische Antworten und hat Zehntausende Sterne gesammelt. Normale Chat-Tests zeigten Gewinne um die 10 %, bei Coding- und Agentenarbeit änderte sich kaum etwas, weil sich Quellcode nicht wie Prosa zusammenstauchen lässt.

Ein kontrollierter Vergleich von JetBrains lieferte konkrete Zahlen: beworben wurden 65 %, bei echten Agentenaufgaben waren es 8,5 %. Selbst dieser Wert entstand mit erzwungen aktiviertem Skill, was das Team als Obergrenze bezeichnete, nicht als typisches Ergebnis.

Das Repository räumt das inzwischen ein. Der Skill verkürzt nur den Output. Input- und Reasoning-Tokens bleiben unberührt, und der Skill selbst fügt allein durch seine Existenz pro Runde etwa 1.000 bis 1.500 Input-Tokens hinzu. Die Episode sagt mehr darüber aus, wie Token-Ersparnisse vermarktet werden, als darüber, was tatsächlich spart. Ein sechszeiliger Prompt mit der Bitte um knappe Antworten bringt fast denselben Effekt.

Modellwechsel mitten in der Session kostet doppelt

Von allen Punkten erwischt dieser die meisten kalt. Mittendrin auf ein günstigeres Modell zu wechseln klingt sparsam, ist es aber selten. Der gespeicherte Prompt gehört zum vorherigen Modell, also muss das neue alles noch einmal verarbeiten und den Schreibaufschlag zahlen.

Wählen Sie das Modell vor dem Start. Wer Routing ohne Wechselkosten möchte, nimmt einen Router, der das Modell auswählt, bevor die Anfrage rausgeht, und umgeht das Problem damit vollständig.

Die Gewohnheit mit der größten Wirkung: Präzision

Sagen Sie genau, welches Format, welche Felder und welche Länge Sie wollen, und das Modell hört auf, Dinge zu produzieren, nach denen niemand gefragt hat. Vergleichen Sie diesen Prompt:

Return a JSON object with keys: "title", "price", "inStock".
No extra commentary.

mit "gib mir die Produktinfos". Der zweite ist nicht nur bequem. Vagheit verleitet zu übervollen Antworten. Präzision zieht sich durch fast jede gute Prompting-Technik und hängt direkt damit zusammen, wie viel man dem Modell auf einmal abverlangt.

Was unterm Strich bleibt

Es geht nicht darum, ein billigeres Modell zu wählen. Es geht darum, was ins Modell hineingeht und wie oft es sich selbst neu lesen muss. Die Checkliste ist kurz:

• den System-Prompt stabil halten
• bei einem Modell bleiben
• /context ausführen und ungenutzte Tools entfernen
• LSP aktivieren und in den Anweisungen festhalten, dass er bevorzugt wird
• die gewünschte Form der Ausgabe genau beschreiben

Das deckt den Großteil des Gewinns ab und kostet nichts, wenn Sie morgen damit anfangen.

Kurze Antworten

Kosten Output-Tokens wirklich mehr als Input-Tokens? Ja, bei Claude-Modellen etwa fünfmal so viel pro Token. In einem langen Gespräch dominiert trotzdem der Input, weil der gesamte Verlauf in jeder Runde neu gesendet wird.

Erhöht ein Modellwechsel mitten im Gespräch immer die Kosten? Der Wechsel an sich nicht. Weh tut der zerstörte Cache: Die nächste Anfrage wird zum Schreibtarif statt zum vergünstigten Lesetarif abgerechnet. Wer das Modell vorher festlegt, vermeidet das.

Sind zusätzliche MCP-Tools immer ein Token-Problem? Nein. Sie ergeben Sinn, wenn ein Dienst strukturierten, wiederholten Zugriff braucht, und Claude Code verschiebt das Laden der Schemas, sobald sie groß werden. Probleme gibt es bei kleinen Konfigurationen, bei Clients ohne verzögertes Laden und bei der Genauigkeit, wenn das Modell zu viele Optionen hat.