Claude Code und der Kontext: Was wirklich zählt (und was nur so wirkt)

Wer Claude Code über Wochen im Alltag einsetzt, kennt das Gefühl: Irgendwann “fühlt” sich die Sitzung träge an, ein Skill scheint plötzlich nicht mehr zu greifen, und die monatliche Rechnung fällt höher aus als erwartet. Die naheliegende Erklärung — “ich habe zu viele Skills installiert” — ist dabei fast immer nur die halbe Wahrheit. Ich habe mir die offizielle Dokumentation genauer angesehen, um zu verstehen, was den Kontext von Claude Code tatsächlich belastet. Das Ergebnis überrascht an mehreren Stellen.

Skills verdrängen den Kontext nicht — sie verlieren nur ihre Beschreibung

Die Skill-Liste, die Claude bei jeder Anfrage mitgegeben wird, hat ein festes Budget: 1 % des Kontextfensters des jeweiligen Modells. Egal ob zehn oder hundert Skills installiert sind — dieses eine Prozent wächst nicht mit. Was tatsächlich passiert, wenn mehr Skills hinzukommen, ist subtiler: Sobald die Liste das Budget sprengt, kürzt Claude Code zuerst die Beschreibungen der Skills, die am seltensten aufgerufen wurden. Übrig bleibt nur noch der Name — und ein Skill ohne Beschreibung kann von Claude nicht mehr mit einer Nutzeranfrage verknüpft werden.

Das Tückische daran: Es gibt keine Fehlermeldung. Nichts wird spürbar langsamer. Der Skill wird einfach irgendwann nicht mehr automatisch ausgewählt — obwohl er weiterhin existiert und über /skill-name direkt aufgerufen werden kann.

Für die eigene Konfiguration heißt das konkret:

• Jede Skill-Beschreibung ist zusätzlich auf 1.536 Zeichen gedeckelt (Beschreibung plus Trigger-Hinweise zusammen). Wer die wichtigsten Anwendungsfälle nach vorn schreibt, riskiert weniger, dass genau der entscheidende Teil abgeschnitten wird.
• Reicht das Standardbudget nicht, lässt es sich über die Einstellung skillListingBudgetFraction anheben (z. B. 0.02 für 2 %).
• Wer nur gelegentlich gebrauchte Skills nicht verlieren will, kann sie über /skills als name-only markieren, um bewusst Platz für andere freizugeben.

Messen statt raten: drei Befehle mit unterschiedlicher Aufgabe

Bevor man irgendetwas kürzt, lohnt sich ein Blick auf die tatsächlichen Zahlen. Claude Code bringt dafür drei Werkzeuge mit, die sich ergänzen statt zu überschneiden:

/context zeigt, was aktuell im Kontextfenster liegt. Wichtig: Die Skills-Zeile meldet die Größe nach Anwendung des Budgets — also exakt das, was das Modell tatsächlich sieht. Vor Version 2.1.196 war das anders: Damals zählte die Anzeige die volle Zeichenlänge aller Beschreibungen und konnte einen Wert zeigen, der weit über dem eingestellten Budget lag. Wer sich noch an “Skills fressen massiv Kontext” erinnert, hat möglicherweise genau diese veraltete Anzeige im Kopf.

/usage zeigt, was der bisherige Verbrauch tatsächlich gekostet hat — inklusive einer eigenen Zeile zum Prompt-Cache (dazu gleich mehr) sowie einer Aufschlüsselung nach Skill, Subagent und MCP-Server. Verhaltensweisen, die 10 % oder mehr des jüngsten Verbrauchs ausmachen, werden dabei explizit markiert.

/skill-doctor schließlich zeigt Kosten und Aufrufhäufigkeit pro Skill und markiert die nie genutzten. Ein paar Einschränkungen sind dabei zu kennen: Das Tool berücksichtigt nur selbst hinzugefügte Skills (keine mitgelieferten oder von der Organisation verteilten), läuft in einer interaktiven Sitzung im Stats-Tab des Plugin-Managers und lässt sich nicht per Fernsteuerung vom Smartphone oder Browser aus starten.

Die sinnvolle Reihenfolge ist damit klar: erst /context für den Überblick, dann /usage für die tatsächlichen Kosten, zuletzt /skill-doctor für konkrete Streichkandidaten. Und ein wichtiger Vorbehalt beim Lesen der Ergebnisse: “nie aufgerufen” bedeutet nicht automatisch “überflüssig”. Es kann genauso gut bedeuten, dass die Beschreibung bereits dem Budget zum Opfer gefallen ist. Ein Skill, der beim expliziten Aufruf per Namen einwandfrei funktioniert, aber nie automatisch gewählt wird, braucht eher eine überarbeitete Beschreibung als eine Löschung.

Der Prompt-Cache entscheidet mehr über die Rechnung als die reine Größe

Zwei Sitzungen mit identischer Kontextgröße können völlig unterschiedlich teuer sein — je nachdem, ob der Prompt-Cache greift. Seit Version 2.1.251 zeigt /usage dazu eine eigene Zeile, etwa in dieser Form:

Prompt cache (main):   14 requests · 91% of input tokens from cache ·
2 misses (last 6m 10s ago, 310.2k tokens re-cached) ·
1 expected rebuild (compaction or tool-result clearing) ·
warm (1h TTL, last activity 40s ago)

Drei Begriffe sind dabei entscheidend:

• Miss: Eine Anfrage zählt als Cache-Miss, wenn sie mehr als 5 % und mindestens 2.000 Tokens neu verarbeiten musste, die eigentlich aus dem Cache hätten kommen können.
• Expected rebuild: Schreibt Claude Code die Konversation selbst um — etwa durch Kompaktierung oder das Entfernen alter Tool-Ergebnisse — zählt das separat als erwarteter Neuaufbau, nicht als “echter” Miss.
• Warm / cold: Ob der zwischengespeicherte Anfang der Konversation noch innerhalb seiner Lebensdauer liegt.

Und genau diese Lebensdauer ist ein Punkt, den viele nicht auf dem Schirm haben: Sie beträgt eine Stunde im Abo-Modell, sinkt aber auf fünf Minuten, sobald man ins Zusatzkontingent (Usage Credits) rutscht oder über API-Schlüssel bzw. Cloud-Anbieter arbeitet. Das bedeutet: Der Moment, in dem man sein reguläres Limit überschreitet, ändert nicht nur den Preis pro Einheit, sondern lässt den Cache auch deutlich schneller auskühlen — mit spürbaren Folgen für die nächste Anfrage nach einer kurzen Pause. Wer das vermeiden will, kann die Cache-Lebensdauer selbst konfigurieren.

MCP-Server sind heute schlanker, CLIs bleiben trotzdem im Vorteil

Auch die Sorge “zu viele MCP-Server verstopfen den Kontext” trifft heute weniger zu als früher: MCP-Tool-Definitionen werden standardmäßig verzögert geladen (deferred). Bis Claude ein bestimmtes Tool tatsächlich benutzt, gelangen nur die Tool-Namen und die Serverbeschreibung in den Kontext — nicht die vollständigen Definitionen.

Trotzdem bleiben klassische CLI-Werkzeuge wie gh, aws, gcloud oder sentry-cli kontexteffizienter. Der Grund ist simpel: Ein CLI fügt gar keine Tool-Liste hinzu, weil Claude den Befehl direkt ausführen kann. Die praktische Konsequenz: Erledigt ein CLI dieselbe Aufgabe wie ein MCP-Server, sollte man bewusst abwägen, ob der MCP-Server wirklich gebraucht wird (zentrale Authentifizierung, strukturierte Antworten, Rechteverwaltung) — oder ob er nur “praktisch aussah”. Ungenutzte Server lassen sich jederzeit über /mcp deaktivieren.

Was garantiert in jeder Anfrage mitreist

Zwei Dinge werden — anders als Skills und MCP-Tools — nicht bedingt geladen, sondern fahren bei jeder einzelnen Anfrage mit:

1. CLAUDE.md. Sie wird beim Sitzungsstart in den Kontext geladen und bleibt dort, auch wenn man gerade an etwas völlig anderem arbeitet. Die offizielle Empfehlung: CLAUDE.md unter 200 Zeilen halten und ausführliche, workflow-spezifische Anweisungen stattdessen in Skills auslagern, die nur bei tatsächlichem Bedarf geladen werden.
2. Die Konversation selbst. Claude Code sendet bei jeder Anfrage das gesamte bisherige Gespräch mit — und jedes Mal, wenn ein Tool benutzt wird, geht eine weitere Anfrage mit diesem Tool-Ergebnis hinaus. Selbst eine einzeilige Frage in einer den ganzen Tag offenen Sitzung verursacht damit Verbrauch in Höhe der kompletten Konversation. Der Cache senkt den Preis pro Einheit deutlich, aber eben nicht auf null.

Genau daraus ergibt sich die Faustregel für /clear vs. /compact: /compact muss die Konversation, die es zusammenfasst, erst einmal lesen — bei einem großen Kontext ist das Kompaktieren selbst eine große (und keineswegs kostenlose) Anfrage. Wer keinen inhaltlichen Anschluss braucht, sondern einen echten Neustart will, fährt mit /clear besser: Es kostet nichts.

Verbrauch trotz Leerlauf — woher das kommt

Ein Klassiker: “Ich war kurz weg, trotzdem ist der Verbrauch gestiegen.” Dafür gibt es tatsächlich mehrere dokumentierte Ursachen, und alle haben dieselbe Grundstruktur — auch im Leerlauf startet eine neue Anfrage, die den vollen Kontext mitsendet:

• Geplante Aufgaben, die in ihrem Intervall feuern, unabhängig davon, ob gerade gearbeitet wird
• Nachrichten aus anderen Sitzungen, die als neuer Zug zugestellt werden (lässt sich über die Einstellung crossSessionInbound: hold unterbinden)
• Fortschrittsprüfungen laufender Ziele (Goals) — bis zu dreimal zwischen zwei eigenen Prompts
• Jedes aktive Mitglied eines Agent-Teams, das weiterläuft, bis es fertig ist oder beendet wird
• Ablauf des Caches, wodurch die nächste Nachricht den kompletten Kontext neu verarbeiten muss

Besonders Agent-Teams schlagen hier zu Buche: Laut Dokumentation verbraucht ein Team im Planungsmodus etwa das Siebenfache der Tokens einer gewöhnlichen Sitzung, weil jedes Mitglied ein eigenes Kontextfenster mitbringt. Die Empfehlung ist entsprechend pragmatisch: Sonnet statt Opus für Teammitglieder verwenden, Teams klein halten und sie konsequent beenden, sobald die Arbeit erledigt ist.

Als Richtwert für die eigene Einordnung nennt die Dokumentation durchschnittliche Unternehmenskosten von rund 13 US-Dollar pro Person und Arbeitstag beziehungsweise 150 bis 250 US-Dollar im Monat, wobei 90 % der Nutzenden unter 30 US-Dollar pro Arbeitstag bleiben. Wer deutlich darüber liegt, hat wahrscheinlich einen der oben genannten Punkte im Spiel.

Die Reihenfolge, die sich in der Praxis auszahlt

Zusammengefasst ergibt sich eine klare Priorität, wenn man den eigenen Kontextverbrauch in den Griff bekommen will:

1. Sofort und kostenlos: /clear beim Wechsel zu unabhängiger Arbeit — alter Kontext wird sonst bei jeder weiteren Nachricht mitberechnet.
2. Einmalig konfigurieren: CLAUDE.md unter 200 Zeilen bringen und Workflow-Details in Skills auslagern. Das wirkt danach dauerhaft, in jeder Sitzung.
3. Ausgabe eingrenzen: Hooks so einsetzen, dass etwa Logdateien vorgefiltert werden, bevor sie in den Kontext gelangen, und umfangreiche Verarbeitung an Subagenten delegieren.
4. Preis pro Einheit senken: Modell und Denkaufwand zur Aufgabe passend wählen — für die meiste Programmierarbeit reicht Sonnet, der Denkaufwand lässt sich mit /effort anpassen.

Das Löschen von Skills steht bewusst nicht ganz oben. Wie sich zeigt, ist das selten der größte Hebel — und vorschnelles Löschen kann sogar einen Skill treffen, der eigentlich nur an einer zu kurzen Beschreibung krankt. Der eine Grundsatz, der sich durch alle Punkte zieht: erst mit /context, /usage und /skill-doctor messen, dann gezielt anfassen. Alles andere bleibt Raten.