Inhaltsverzeichnis

„Zu viele Skills verdrängen den Kontext“ — das hört man ständig. Zur Hälfte stimmt es, zur Hälfte nicht.

Laut offizieller Dokumentation steht der Skill-Liste ein festes Budget von 1 % des Kontextfensters des Modells zu, und egal wie viele Skills dazukommen, dort ist Schluss. Sie wächst nicht weiter. Stattdessen passiert etwas anderes: Die Skills werden nicht mehr aufgerufen. Läuft die Liste über das Budget hinaus, streicht Claude Code die Beschreibungen zuerst bei den am seltensten aufgerufenen Skills und behält nur deren Namen. Ein Skill ohne Beschreibung lässt sich nicht mehr mit dem verknüpfen, worum Sie gebeten haben.

Es gibt keine Fehlermeldung. Nichts wird langsamer. Der Skill wird einfach still nicht mehr benutzt. Dieser Artikel zeigt, wie Sie sehen, was den Kontext gerade tatsächlich belegt — mit Zahlen statt mit Vermutungen — und was Sie danach zuerst kürzen.

Was passiert, wenn Skills dazukommen

Das Budget der Liste liegt fest bei 1 % des Kontextfensters. Was überläuft, kostet Beschreibungen, nicht Tokens

INNERHALB DES BUDGETS
Alle behalten ihre Beschreibung

Name und Beschreibung werden vollständig geladen. Auch wenn die Formulierung etwas danebenliegt, greifen die Stichwörter

KNAPP ÜBER DER GRENZE
Beschreibungen fallen nach Nutzung

Häufig genutzte Skills behalten den vollen Text. Die selten gebrauchten verlieren ihre Beschreibung zuerst

NUR NOCH DER NAME
Vorhanden, aber nie gewählt

Der Eintrag bleibt in der Liste. Aber nichts sagt, wofür er da ist, also findet er keine Anfrage

Quelle: Claude Code Dokumentation, „Skills“

1. Skills wachsen nicht unbegrenzt — bei 1 % Budget ist Schluss

Damit Claude weiß, welche Skills verfügbar sind, lädt Claude Code eine Liste mit Skill-Namen und Beschreibungen in den Kontext. Genau hier wird das Budget wichtig. Die Dokumentation hält fest, dass die Liste immer alle Skill-Namen enthält, Claude Code die Beschreibungen bei vielen Skills aber so weit kürzt, dass sie in das Zeichenbudget der Liste passen, und beziffert dieses Budget mit 1 % des Kontextfensters des Modells.

Mit Zahlen wird es greifbar. Bei einem Modell mit einer Million Tokens Kontextfenster bekommt die Skill-Liste 1 % davon. Die übrigen 99 % stehen für Gespräch, Dateien und Tool-Ergebnisse bereit. Ob Sie 50 oder 100 Skills installieren: Dieses 1 % bewegt sich nicht.

Wohin geht dann das Mehr? In gekürzte Beschreibungen. Die Dokumentation nennt sogar die Reihenfolge des Kürzens: Läuft die Liste über, streicht Claude Code die Beschreibungen zuerst bei den am seltensten aufgerufenen Skills, damit die häufig genutzten ihren vollen Text behalten.

Das ist in der Praxis der unangenehmste Teil. Getroffen werden die Skills, die man nur gelegentlich braucht, und das sind meist genau jene, die man wieder braucht, wenn man sie längst vergessen hat. Ein Migrationsablauf einmal im Quartal, ein Release-Prozess ein paar Mal im Jahr — ausgerechnet die verlieren ihre Beschreibung zuerst.

Das Budget lässt sich ändern. Tragen Sie in skillListingBudgetFraction einen Anteil des Kontextfensters ein (etwa 0.02 für 2 %), und die Liste bekommt mehr Raum. Auch pro Skill gibt es eine Obergrenze: standardmäßig 1.536 Zeichen für Beschreibung und Auslösebedingungen zusammen (änderbar über skillListingMaxDescChars). Dass die Dokumentation empfiehlt, die wichtigsten Einsatzzwecke nach vorn zu schreiben, liegt genau an dieser Grenze: Abgeschnitten wird hinten.

2. Drei Werkzeuge zum Messen — mit je eigener Aufgabe

Drei Werkzeuge ersetzen das Raten durch Zahlen. /context gibt es schon länger, doch die Prompt-Cache-Zeile in /usage kam mit v2.1.251 (28. August 2026) und /skill-doctor mit v2.1.252 (31. August). Sie erfüllen unterschiedliche Aufgaben, deshalb lohnt es sich, alle drei zu kennen.

/context
Was gerade geladen ist

Schlüsselt auf, was das Fenster belegt. Die Skills-Zeile meldet die Größe nach Anwendung des Budgets, sie entspricht also dem, was das Modell wirklich bekommt

/usage
Was das verbraucht hat

Tokens und Kosten der Sitzung, dazu den Zustand des Prompt-Cache und die Aufteilung des Verbrauchs nach Skill, Subagent und MCP-Server

/skill-doctor
Welche sich rechnen

Zeigt Kosten und Aufrufhäufigkeit pro Skill und markiert die nie aufgerufenen. Es zeigt auch, wo man schneidet

Dabei gibt es eine Reihenfolge. Mit /context die Aufschlüsselung lesen, mit /usage prüfen, was sie tatsächlich gekostet hat, und mit /skill-doctor die Kandidaten zum Kürzen bestimmen. Wer vom anderen Ende beginnt, löscht ohne jede Grundlage.

Zur Skills-Zeile von /context hält die Dokumentation auch das frühere Verhalten fest: Vor v2.1.196 zählte sie die Zeichenlänge aller Beschreibungen und konnte einen Wert anzeigen, der ein Vielfaches des eingestellten Budgets betrug. Wenn Ihr Eindruck, Skills würden den Kontext auffressen, aus älterer Erinnerung stammt, war womöglich schon diese Zahl größer als die Wirklichkeit.

3. Ungenutzte Skills beim Namen nennen lassen

/skill-doctor steht ab Claude Code v2.1.252 (31. August 2026) zur Verfügung. Die offizielle Beschreibung lautet, man könne Kosten und Aufrufhäufigkeit jedes Skills einsehen und entscheiden, welche man streicht. Vier Dinge zum Verhalten sollte man kennen.

Voraussetzungen von /skill-doctor

  • In einer interaktiven Sitzung öffnet es den Stats-Tab des /plugin-Managers. Im nicht-interaktiven Modus mit -p gibt es stattdessen Text aus
  • Mitgelieferte und über die Organisation verteilte Skills bleiben außen vor. Aufgeführt wird nur, was Sie selbst hinzugefügt haben
  • Nie aufgerufene Skills werden markiert, samt Hinweis, wo man sie herausnimmt
  • Per Fernsteuerung vom Smartphone oder aus dem Browser lässt es sich nicht ausführen, es kommt ein Fehler zurück

Beim Lesen der Ergebnisse genügt ein einziger Vorbehalt, um nicht danebenzugreifen. „Nie aufgerufen“ ist nicht dasselbe wie „überflüssig“. Wie der vorige Abschnitt gezeigt hat, kann der Grund fürs Nichtaufrufen sein, dass die Beschreibung weggekürzt wurde und der Skill deshalb nicht gefunden wird.

Vor dem Streichen ist es sicherer, den Skill einmal namentlich aufzurufen. Läuft er beim Aufruf mit Namen, wird aber automatisch nie gewählt, ist er nicht überflüssig, sondern seine Beschreibung verliert gegen das Budget. Die Lösung heißt dann nicht Löschen, sondern die Beschreibung umschreiben (wichtigste Einsatzzwecke nach vorn) oder das Budget anheben.

4. Cache-Misses wiegen schwerer als die Größe

Ab hier geht es um eine andere Achse als die „Größe“ des Kontexts. Zwei gleich große Gespräche werden völlig unterschiedlich abgerechnet, je nachdem, ob der Cache greift.

Seit Claude Code v2.1.251 (28. August 2026) erscheint im Sitzungsbereich von /usage eine Zeile zum Prompt-Cache. So sieht das Beispiel aus, das die Dokumentation zeigt.

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)

Beim Lesen kommt es auf drei Punkte an.

MISSES
5 % und 2.000 Tokens

Als Miss zählt eine Anfrage, die mehr als diese Menge an Inhalten neu liest, die der Cache hätte liefern können. Ein kleiner Austausch reicht dafür nicht

EXPECTED REBUILD
Selbst verursachter Anteil

Schreibt Claude Code das Gespräch selbst um, durch Kompaktierung oder das Löschen alter Tool-Ergebnisse, zählt das gesondert als erwarteter Neuaufbau und nicht als Miss

WARM / COLD
Innerhalb der Lebensdauer oder darüber

Ob der zwischengespeicherte vordere Teil noch lebt. Ist er kalt, zeigt die Zeile, wie lange nichts passiert ist

Ab v2.1.260 nennt die Zeile auch die vermutete Ursache, wenn sich ein jüngster Miss erklären lässt (etwa likely cause: tool definitions changed). Ein MCP-Server kommt hinzu, ein Skill wird ausgetauscht — solche Änderungen schreiben etwas nahe am Anfang des Gesprächs um und machen damit den Cache für alles Nachfolgende ungültig. Deshalb ist es günstig, die Konfiguration vor Arbeitsbeginn anzufassen.

Eine Einschränkung gibt es. Diese Zeile betrachtet nur das Hauptgespräch, Subagenten sind nicht enthalten. Wer schwere Verarbeitung an Subagenten abgibt, sieht hier nicht das Gesamtbild. Wie viel jede Sitzung einschließlich ihrer Subagenten verbraucht hat, lässt sich stattdessen aus den Gesprächsprotokollen zusammenzählen (Claude Code: Verbrauch pro Sitzung messen).

5. Der Cache lebt nicht immer eine Stunde

Dieser Punkt schlägt direkt auf die Rechnung durch und ist trotzdem wenig bekannt. Die Lebensdauer des Prompt-Cache hängt von Vertragsform und Situation ab.

Abonnement
1 Stunde

Auch nach der Mittagspause lebt der Cache noch, wenn Sie zurückkommen

Nach Beginn des Zusatzkontingents oder über API-Schlüssel und Cloud
5 Minuten

Kurz weg vom Platz, und er ist kalt. Die nächste einzelne Nachricht liest den ganzen Kontext neu

Quelle: Claude Code Dokumentation, „Manage costs effectively“ (die Regeln zur Cache-Lebensdauer)

Die Dokumentation schreibt, die Lebensdauer betrage im Abonnement eine Stunde und sinke auf fünf Minuten, sobald das Zusatzkontingent (usage credits) angebrochen wird; über einen API-Schlüssel oder einen Cloud-Anbieter liege sie standardmäßig bei fünf Minuten. In dem Moment, in dem Sie das Limit erreichen und ins Zusatzkontingent rutschen, schrumpft die Lebensdauer des Cache auf ein Zwölftel — „nach dem Limit“ ändert also nicht nur den Preis pro Einheit, sondern auch, wie gut der Cache noch greift. Als Weg, im Zusatzkontingent trotzdem eine Stunde zu behalten, verweist die Dokumentation darauf, die TTL selbst festzulegen.

6. MCP lädt standardmäßig verzögert. Warum CLIs trotzdem leichter sind

Auch „MCP-Server fressen den Kontext“ steht heute auf anderen Voraussetzungen. Laut Dokumentation werden MCP-Tool-Definitionen standardmäßig verzögert geladen, und bis Claude ein bestimmtes Tool benutzt, gelangen nur die Tool-Namen und die Serverbeschreibung in den Kontext.

Trotzdem hält die Dokumentation fest, dass CLI-Werkzeuge wie gh, aws, gcloud und sentry-cli nach wie vor kontexteffizienter sind. Der Grund ist einfach: Ein CLI fügt überhaupt keine Tool-Liste hinzu. Claude kann den Befehl direkt ausführen, es müssen also nicht einmal die Namen geladen werden.

Daraus folgt der praktische Schluss. Wenn ein CLI dieselbe Aufgabe erledigt, sollte der Grund für MCP außerhalb des Kontextbudgets liegen (zentrale Authentifizierung, strukturierte Ergebnisse, Rechtesteuerung). Ein Server, den man installiert hat, weil er praktisch aussah, ist ein Kandidat zum Abschalten — die Liste zeigt /mcp.

7. Was in jedem Zug mitfährt — CLAUDE.md und das Gespräch selbst

Skills und MCP werden bedingt geladen, aber zwei Dinge fahren bedingungslos jedes Mal mit.

Das eine ist CLAUDE.md. Es wird beim Start der Sitzung in den Kontext geladen, weshalb die dort notierten Workflow-Schritte auch dann im Fenster sitzen bleiben, während Sie an etwas völlig anderem arbeiten. Als Gegenmittel empfiehlt die Dokumentation, ausführliche Anweisungen für bestimmte Workflows in Skills auszulagern, und nennt sogar ein konkretes Ziel: CLAUDE.md unter 200 Zeilen halten und auf das Wesentliche beschränken. Die Logik dahinter: Ein Skill wird nur geladen, wenn er aufgerufen wird, derselbe Inhalt belastet also nicht mehr dauerhaft.

Das andere ist das Gespräch selbst. Die Dokumentation formuliert es präzise: Claude Code sendet mit jeder Anfrage das gesamte Gespräch, und jedes Mal, wenn Claude ein Tool benutzt, geht eine weitere Anfrage mit diesem Tool-Ergebnis hinaus. Deshalb löst auch eine einzeilige Frage in einer den ganzen Tag offenen Sitzung Verbrauch in Höhe des kompletten Gesprächs aus. Der Cache drückt den Preis pro Einheit, aber nicht auf null.

Genau hier entscheidet sich die Wahl zwischen /clear und /compact. Die Dokumentation schreibt: /compact liest das Gespräch, das es zusammenfasst, weshalb das Kompaktieren eines großen Kontexts selbst eine große Anfrage ist; wer keinen Anschluss, sondern einen Neustart will, fährt mit /clear kostenlos. „Einfach mal kompaktieren“ ist nicht gratis. Wann der richtige Moment dafür ist, behandelt Sollte man /compact in Claude Code regelmäßig ausführen? im Detail.

8. Der Verbrauch steigt, obwohl man nichts tut

„Ich war nur kurz weg, und der Verbrauch ist trotzdem gestiegen“ — dafür gibt es konkrete Gründe, und die Dokumentation zählt sie auf. Alle haben dieselbe Form: Auch im Leerlauf beginnt ein neuer Zug, der den vollen Kontext sendet.

Was den Verbrauch im Leerlauf vorantreibt

  • Geplante Aufgaben — sie feuern in ihrem Intervall, auch wenn die Sitzung nichts tut, und senden dabei jedes Mal den vollen Kontext
  • Nachrichten aus anderen Sitzungen — sie werden im Leerlauf als neuer Zug zugestellt. Mit crossSessionInbound auf hold lassen sie sich zurückhalten
  • Fortschrittsprüfungen von Zielen — während Hintergrundarbeit läuft, entsteht ein Prüfzug, zwischen zwei Prompts bis zu dreimal
  • Jedes Mitglied eines Agent-Teams — sie verbrauchen Tokens, bis sie fertig sind
  • Ablauf des Cache — die erste Nachricht nach der Pause liest den ganzen Kontext neu

Für Agent-Teams gibt es sogar einen konkreten Faktor. Die Dokumentation schreibt, ein Agent-Team verbrauche rund das 7-Fache der Tokens einer normalen Sitzung, wenn seine Mitglieder im Planungsmodus laufen. Jedes Mitglied hat ein eigenes Kontextfenster, es skaliert also ungefähr mit der Kopfzahl. Die offizielle Empfehlung ist ebenso klar: für Mitglieder Sonnet nehmen, das Team klein halten und es nach getaner Arbeit beenden.

Als Anhaltspunkt beziffert die Dokumentation den Durchschnitt bei Unternehmenseinführungen auf rund 13 $ pro Person und Arbeitstag beziehungsweise 150 bis 250 $ im Monat und schreibt, 90 % der Nutzenden blieben unter 30 $ pro Arbeitstag. Wer mit seinen eigenen Zahlen deutlich außerhalb dieses Bandes liegt, hat vermutlich einen der obigen Punkte im Spiel.

9. Nach dem Messen: Was zuerst gekürzt wird

Mit Zahlen in der Hand beginnt man dort, wo die Wirkung am größten ist. Ordnet man die von der Dokumentation genannten Maßnahmen danach, wie schnell sie greifen, ergibt sich diese Reihe.

SOFORT UND GRATIS
/clear beim Wechsel zu anderer Arbeit

Alter Kontext wird bei jeder weiteren Nachricht mitberechnet. Erst /rename, dann löschen, und Sie kommen später mit /resume zurück

EINMAL DIE KONFIGURATION
CLAUDE.md unter 200 Zeilen bringen

Abläufe für bestimmte Aufgaben in Skills auslagern. Weniger fährt dauerhaft mit, und es wirkt in jeder Sitzung

AUSGABE EINGRENZEN
Hooks und Subagenten

Statt ein Log mit 10.000 Zeilen einzuspeisen, gibt ein Hook nur die passenden Zeilen zurück. Weitschweifige Verarbeitung bleibt im Subagenten

PREIS PRO EINHEIT SENKEN
Modell und Denkaufwand zur Aufgabe passen

Für die meiste Programmierarbeit reicht Sonnet. Bei einfachen Aufgaben den Denkaufwand mit /effort senken

Die Reihenfolge hat einen Sinn. Der erste Punkt wirkt ab heute und kostet nichts. Den zweiten repariert man einmal, danach wirkt er in jeder Sitzung. Der dritte und der vierte sind eine Frage von Konfiguration und Gewohnheit und brauchen daher etwas Zeit. Dass das Löschen von Skills nicht oben steht, liegt daran, dass es, wie die vorigen Abschnitte gezeigt haben, selten der größte Faktor ist.

Unverrückbar bleibt dagegen der eine Punkt: erst messen, dann anfassen. Das offizielle /usage markiert jedes Verhalten, das 10 % oder mehr des jüngsten Verbrauchs ausmacht (ein zu langer Kontext, Cache-Misses und so weiter). Wer etwas ohne Markierung streicht, wird keinen Unterschied spüren.

FAQ

F1. Wie viele Skills sind noch sicher?
Für die Anzahl gibt es keine Obergrenze. Entscheidend ist, ob sie in das Zeichenbudget der Liste passen, also in 1 % des Kontextfensters. Dieselben zehn Skills laufen mit langen Beschreibungen über und passen mit kurzen hinein. Die Skills-Zeile von /context und /skill-doctor zu lesen, ist genauer als Zählen.

F2. Darf ich einen nie aufgerufenen Skill löschen?
Rufen Sie ihn vor dem Löschen namentlich auf. Läuft er beim Aufruf mit Namen, wird aber automatisch nie gewählt, ist er nicht überflüssig, sondern seine Beschreibung verliert gegen das Budget. Die Lösung heißt dann nicht Löschen, sondern die Beschreibung umschreiben (wichtigste Einsatzzwecke nach vorn) oder das Budget anheben.

F3. Wird es billiger, wenn ich häufig /compact drücke?
Nein. Das Kompaktieren liest das Gespräch, das es zusammenfasst, und ist bei großem Kontext selbst eine große Anfrage. Wo kein Anschluss nötig ist, ist /clear billiger (es kostet nichts) und verlässlicher.

F4. Welche Cache-Trefferquote sollte ich anstreben?
Die Dokumentation nennt keine Bestehensgrenze, also achten Sie auf die Veränderung statt auf den absoluten Wert. Fällt die Quote bei gleicher Arbeitsweise, haben Sie kurz zuvor wahrscheinlich die Konfiguration geändert (MCP, Skills, Tool-Definitionen). Ab v2.1.260 nennt die Zeile ihre Vermutung zur Ursache.

F5. Sollte ich MCP-Server reduzieren?
Tool-Definitionen werden standardmäßig verzögert geladen, die bloße Installation belastet also weniger als früher. Erledigt allerdings ein CLI wie gh dieselbe Aufgabe, ist das CLI leichter (es fügt überhaupt keine Tool-Liste hinzu). Ungenutzte Server lassen sich mit /mcp abschalten.

F6. Sparen Subagenten Kontext?
Ja. Die Dokumentation empfiehlt ebenfalls, weitschweifige Verarbeitung (Tests ausführen, Dokumentation holen, Logs durchgehen) an einen Subagenten zu geben, die Details in dessen Kontext zu lassen und nur eine Zusammenfassung zurückzugeben. Allerdings betrachtet die Cache-Zeile von /usage nur das Hauptgespräch, weshalb diese Zahlen bei subagentenlastiger Arbeitsweise nicht das Gesamtbild zeigen.

F7. /skill-doctor funktioniert bei mir nicht.
Sie brauchen Claude Code ab v2.1.252. Außerdem lässt es sich per Fernsteuerung vom Smartphone oder aus dem Browser nicht ausführen, dort kommt ein Fehler zurück. In einer interaktiven Sitzung öffnet es den Stats-Tab des /plugin-Managers; wenn Sie Textausgabe brauchen, führen Sie es im nicht-interaktiven Modus mit -p aus.

Quellen

  • Claude Code Docs — Skills (Budget der Liste = 1 % des Kontextfensters, Obergrenze von 1.536 Zeichen je Beschreibung, Kürzungsreihenfolge beim Überlauf, Skills-Zeile von /context)
  • Claude Code Docs — Manage costs effectively (Aufschlüsselung von /usage, Prompt-Cache-Zeile, Definition eines Miss, Cache-Lebensdauer, CLAUDE.md mit 200 Zeilen, rund das 7-Fache bei Agent-Teams, Durchschnittskosten in Unternehmen)
  • Claude Code Docs — Slash commands (Verhalten und Voraussetzungen von /skill-doctor)
  • Claude Code Changelog (v2.1.251 Cache-Zeile, v2.1.252 /skill-doctor, v2.1.260 Ursachenvermutung, v2.1.261 Einstellung der Ausgabegrenze)