Wohin die Tokens verschwinden: den Kontext von KI-Modellen steuern

In der Arbeit mit KI-Agenten ist die Kontrolle über den Kontext eine Schlüsselkompetenz. Von ihr hängt ab, wie gut das Ergebnis wird und wie viel Zeit und Tokens, also Lizenz-Limits, Sie eine Aufgabe kostet.

Grob gesagt liest ein modernes Sprachmodell innerhalb einer Sitzung jedes Mal den gesamten bisher geschriebenen Text: den Dialog, den System- und den Nutzer-Prompt, die geladenen Werkzeuge und so weiter. Das Kontextfenster ist die maximale Textmenge, die das Modell lesen kann. Gemessen wird sie in Tokens. Ein Token entspricht etwa 0,75 Wörtern im Englischen und rund 0,5 Wörtern im Deutschen, weil Umlaute und längere Wortformen vom Tokenizer in mehr Teile zerlegt werden als reine lateinische Buchstaben.

Bei kostenlosen Modellen liegt der Kontext teils noch bei 32K, in Coding-Agenten ist er größer: 200K bei Claude Sonnet 4.6, 1M bei Claude Opus 4.8, 400K bei GPT-5.5 in Codex. Man könnte meinen, in eine Million passt eine ordentliche Codebasis, also kein Grund zur Sorge. Je mehr Tokens im Fenster liegen, desto schwerer fällt dem Modell aber der Umgang damit. Die Argumentation wird schwächer, Antworten kommen langsamer, und jeder Zug verbraucht mehr Tokens und Limits. Deshalb lohnt es sich, den Kontext sichtbar zu machen, seine Arbeitszone zu kennen und die Aufgabe genau dort hineinzulegen.

Was den Kontext schon vor der ersten Frage füllt

Der Befehl /context in Claude Code zeigt den Stand. Schon im leeren Zustand, ohne eine einzige Nachricht, sind 15.000 bis 30.000 Tokens für Systeminternes belegt. Auf dem 200K-Fenster von Sonnet sind das rund 10 Prozent, plus etwa 16,5 Prozent, die für die Autokompaktierung reserviert sind. Auf dem 1M-Fenster von Opus 4.8 belegen dieselben Systemteile weniger als 3 Prozent.

Die Hauptkategorien in /context:

• System-Prompt und Tools: der Systemprompt der Entwickler und die Beschreibung der Werkzeuge. Eine Startsteuer, an der nichts vorbeiführt.
• MCP: hat früher viel Kontext gekostet, ist nach einer Optimierung von Anthropic aber besser geworden. Die Beschreibungen werden bei Bedarf geladen, nicht alle auf einmal beim Start. Belegt MCP auf dem Startbildschirm schon einen merklichen Anteil, prüfen Sie, ob ein schwerer Server angebunden ist, den Sie längst nicht mehr nutzen.
• Memory: die CLAUDE.md des aktuellen Projekts plus die ersten 200 Zeilen Ihrer MEMORY.md. Wächst mit der Auto-Memory; wird es zu viel, lohnt ein Blick, was sich auslagern oder kürzen lässt.
• Skills: nur Namen und Beschreibungen. Die eigentliche Anweisung wird erst beim Aufruf geladen und bleibt im Kontext, solange die zugehörige Arbeit läuft.
• Messages: der Verlauf, also Ihre Nachrichten, Claudes Antworten, Werkzeug-Ergebnisse und der Inhalt gelesener Dateien. Wächst schneller als alle anderen Kategorien zusammen, und genau hier steckt der Hauptverbrauch.
• Free space: das noch Freie. Es ergibt sich aus dem Fenster minus alles Belegte minus dem Puffer für die Autokompaktierung.

Den Startsatz haben die Entwickler in den letzten Monaten gut optimiert, deshalb rate ich Einsteigern nicht, dort zusätzlich etwas auszulagern. Den Verbrauch senken Sie an anderer Stelle.

Erstens verbraucht Opus 4.8 mehr Tokens als Sonnet 4.6. Das gleicht das größere Fenster aus, aber der Tokenverbrauch ist eben auch die API-Rechnung oder das schmelzende Lizenz-Limit. Hinzu kommt, dass die gesamte Argumentation des Modells in den Kontext wandert. Je höher deren Stufe, desto höher der Verbrauch. Im Tarif Max x5 nutze ich fast immer Opus 4.8 auf „xhigh”. Bei Pro empfehle ich, mit Sonnet 4.6 auf „high” zu beginnen und erst auf höhere Stufen oder Opus zu wechseln, wenn Sie wissen, was Sie vom Modell wollen. In Codex bleibe ich auf der aktuellen Version (GPT-5.5) und mittlerer oder hoher Argumentationsstufe; für den Einstieg oder einfache Aufgaben reicht GPT-5.4 Mini.

Ein universelles Rezept gibt es nicht. Ein Modell auf „high” verbraucht weniger Tokens als auf „max”. Löst es die Aufgabe aber erst im zweiten oder dritten Anlauf, während die höhere Stufe sie sofort schafft, verbraucht am Ende die höhere Stufe weniger.

/context lohnt sich an vier Punkten:

1. Direkt nach dem Start einer neuen Sitzung, um die Startsteuer Ihrer Konfiguration zu sehen, also wie stark MCP und Memory belegt sind.
2. Vor einer großen Aufgabe, um zu prüfen, ob sowohl die Aufgabe als auch die anschließende Diskussion mit Korrekturen ins Restfenster passen.
3. Nach einem missratenen Schritt, um zu entscheiden, ob /clear oder /rewind fällig ist, bevor das Modell im Müll versinkt.
4. Wenn Sie lange arbeiten oder abgelenkt waren. Das Gefühl, intuitiv zu wissen, wie viel Kontext bleibt, trügt; die zehn Sekunden für die genaue Zahl sind gut investiert.

Context Rot und die echte Arbeitszone

Bei jeder Anfrage liest das Modell den gesamten Text. Mit wachsendem Umfang beginnt ein Problem, das Forscher Context Rot nennen, das Verrotten des Kontexts. Das menschliche Gedächtnis hebt sofort das Wichtige hervor und wirft Nebensächliches weg, manchmal so gründlich, dass wir nicht mehr wissen, worüber wir vor fünf Minuten gesprochen haben. Beim Modell liegt das Problem umgekehrt: Es behält alles und beginnt auf langen Kontexten zu verwechseln, was wichtig ist und was nicht. Besonders dann, wenn schon mehrere verschiedene Aufgaben, fehlerhafte Ergebnisse und Zwischenfragen im Kontext liegen.

Die Intuition „eine Million Kontext, also arbeitet das Modell bis an dessen Grenze gut” stimmt also nicht. Welche Größe man im Alltag nicht überschreiten sollte, dazu gibt es verschiedene Meinungen. Ich halte mich an diese Werte. Bei Sonnet 4.6 (200K) bleibe ich unter etwa 120K bis 140K. Bei GPT-5.5 in Codex (400K, eine Grenze von Codex selbst, im API hat das Modell eine Million) bleibe ich bei rund 200K, weil ich keine belastbaren Empfehlungen gefunden habe. Bei Opus 4.8 (1M) hielt der Vorgänger Opus 4.7 den Kontext gut bis etwa 400K; bei 4.8 dürfte die Zahl etwas steigen.

Das Fenster lässt sich über die Umgebungsvariable CLAUDE_CODE_AUTO_COMPACT_WINDOW begrenzen. Setzen Sie etwa 140000 oder 400000, dann behandelt der Client diesen Wert als effektives Fenster und startet die Autokompaktierung näher an dieser Schwelle. Ich beobachte aber lieber von Hand, denn nach 140K oder 400K wird das Modell nicht schlagartig schlechter. Mir ist es lieber, eine große Aufgabe läuft kurz über das Limit, als dass mitten darin die Autokompaktierung startet.

Neben der Qualität trifft ein langer Kontext zwei weitere Punkte. Erstens steigt mit dem Füllstand der Prefill, also die Zeit von der Anfrage bis zum Beginn der Antwort. Nahe an der Million dauert das bei Opus 4.7 zwei Minuten und mehr; selbst ein kurzes „präzisiere bitte” startet dann mit langer Pause. Zweitens schießt der Token- und Limit-Verbrauch auf langen Kontexten in die Höhe, weil der Agent den ganzen Verlauf liest, und das löst auch das Caching von Prompts nicht vollständig.

Aufgaben, die das volle Fenster brauchen

Es gibt Fälle, in denen die volle Million sinnvoll ist.

Der erste ist ein Dokument, das sich nicht zerschneiden lässt: ein Vertrag, ein wissenschaftlicher Bericht, das vollständige Transkript eines Interviews. Wenn die Schlüsse aus dem Ganzen kommen müssen, etwa um Formulierungen am Anfang und Ende abzugleichen oder Namen über den Text hinweg zu verbinden, bedeutet das Zerteilen, den Zusammenhang zu verlieren.

Der zweite ist eine einmalige, punktgenaue Frage an eine große Basis. Sie legen die gesamte Dokumentation, ein altes Repository oder eine lange Sammlung in die Sitzung und fragen, wo eine Funktion erwähnt wird oder ob eine bestimmte Bedingung vorkommt. Diese Suche nach der Nadel im Heuhaufen über Schlüsselwörter funktioniert auf langen Fenstern brauchbar und reicht für eine einmalige Aufgabe meist aus.

Der dritte ist eine fortlaufende Sitzung mit einem großen Ziel, bei der das Zerlegen in Subagenten oder das Neustarten teurer wäre als der Qualitätsverlust zur Mitte des Fensters hin. Meist sind das tief fachliche Aufgaben. Ein gutes Beispiel sind aber auch die allerersten Sitzungen mit Claude Code, in denen es einfacher ist, die ganze Aufgabe durch einen Dialog laufen zu lassen, als sofort in Befehle und Subagenten einzutauchen.

Wie Sie die Aufgabe in den Arbeitsbereich legen

Die meisten Aufgaben, auch große, passen problemlos in 400K oder sogar 140K.

Das erste Mittel ist, große Dateien in Stücke zu schneiden. Einen achthundertseitigen Bericht oder ein Repository aus Hunderten Dateien liest man nicht in einem Zug, sondern Abschnitt für Abschnitt, und legt nach jedem eine Zwischen-Zusammenfassung in ein eigenes Dokument oder in die Memory. Die Hauptsitzung hält dann nicht den ganzen Text, sondern den Auszug.

Das zweite Mittel sind punktgenaue Anfragen statt „lies alles”. In einer Codebasis suchen Sie über Grep und Glob, nach Funktionsname, nach Zeichenkette, nach Pfad. Das Modell sieht nur die nötigen Stücke statt des ganzen Projekts.

Das dritte Mittel sind Subagenten. Ein Subagent ist eine eigene Claude-Instanz mit eigenem Kontextfenster, die eine Aufgabe erledigt und nur das Ergebnis in Ihre Sitzung zurückgibt. Die Fleißarbeit, Suchlisten und seitenlange Diffs landen nicht in Ihrem Hauptkontext. Claude Code startet Subagenten manchmal selbst; wollen Sie es ausdrücklich anstoßen, schreiben Sie in den Chat etwas wie „gib den Faktencheck an einen Subagenten”. Subagenten beschleunigen die Arbeit zusätzlich: Findet Claude etwa fünf Fehler in einem Text und ist an einer Stelle unsicher, kann die Hauptinstanz die Korrekturen einarbeiten, während ein Subagent parallel die Tiefensuche übernimmt.

Das vierte Mittel ist, dauerhaftes Wissen in die Memory zu legen statt in den Kontext. Feste Regeln, Absprachen und Vorlieben leben an zwei Orten. Erstens in den CLAUDE.md-Dateien: die projektbezogene CLAUDE.md im Wurzelverzeichnis (über Git mit dem Team geteilt) oder die globale ~/.claude/CLAUDE.md (gilt für alle Ihre Projekte). Zweitens in der Auto-Memory, also den Notizen, die Claude selbst führt; sie liegen unter ~/.claude/projects/<projekt>/memory/ und sind an das jeweilige Repository gebunden. In den Startkontext jeder Sitzung laden alle CLAUDE.md vollständig und die ersten 200 Zeilen des MEMORY.md-Index, den Rest holt Claude bei Bedarf. Die Regel ist einfach: Erklären Sie dasselbe ein zweites oder drittes Mal, wandert es in die Memory, und der Kontext wird sofort frei.

Befehle zur Sitzungssteuerung

• /resume: in eine alte Sitzung zurückkehren. Anders als bei ChatGPT sind die zentralen Einheiten in Claude Code die Projektordner, nicht die Chats. Über /resume erreichen Sie den Verlauf trotzdem, etwa wenn Sie mitten in der Arbeit abbrechen mussten und beim nächsten Mal nicht alles neu erklären wollen.
• /clear (auch /new und /reset): alles leeren. Startet einen komplett neuen Chat, passend, wenn Sie auf eine unabhängige Aufgabe wechseln. Die alte Sitzung bleibt über /resume erreichbar und lässt sich mit /export in eine Datei oder die Zwischenablage ausgeben.
• /rewind (auch doppeltes Esc): setzt die Sitzung um einen oder mehrere Schritte zurück und entfernt sie vollständig aus dem Kontext. Sie sehen die Liste der Schritte und können nur das Gespräch zurücksetzen, nur die Dateien, beides, oder „ab hier zusammenfassen”, also ein gezieltes /compact ab einem gewählten Punkt.
• /compact: den Verlauf in eine kurze Zusammenfassung verdichten. Sie behalten den Faden, verlieren aber Details wie wörtliche Formulierungen und Zwischenstände. Mit Argument lässt sich priorisieren, etwa /compact behalte die API-Auszeichnung und die Testergebnisse. Drücken Sie nicht selbst, startet Claude Code an der Standardschwelle (rund 95 Prozent des Fensters) die Kompaktierung allein, das ist die Autokompaktierung.
• /btw <Frage>: eine schnelle Rückfrage stellen, ohne sie in das Hauptgespräch aufzunehmen. Frage und Antwort bleiben außerhalb des Sitzungskontexts, praktisch für eine Kleinigkeit wie „wie schreibt sich das Flag dieses Befehls”.
• /branch [Name]: eine Abzweigung vom aktuellen Gespräch. Der Kontext bis zur Abzweigung bleibt erhalten, danach läuft alles getrennt weiter. Im Grunde ein Git-Branch für den Dialog, wenn Sie einen anderen Ansatz probieren wollen, ohne die laufende Arbeit zu verlieren.

Die Kompaktierung führe ich am besten dann aus, wenn die Aufgabe einen Zwischenstand erreicht hat. Deshalb warte ich nicht auf die Autokompaktierung; sie kommt im ungünstigsten Moment und kann wichtige Details verlieren.

Zurück zu /rewind. Hat das Modell etwas falsch gemacht, wähle ich aus drei Optionen. Ist das Ergebnis schwach und ohne Nutzen, setze ich mit /rewind zurück, stelle die Aufgabe anders, erhöhe die Argumentationsstufe und versuche es ohne Müll im Kopf des Modells erneut. Will ich, dass das Modell ein mittelmäßiges Ergebnis verbessert, oder es bewusst als schlechtes Beispiel zeigen, lasse ich den Kontext stehen. Geht es um eine allgemeine Vorgabe, gehört sie in CLAUDE.md oder die Auto-Memory, etwa „schreibe auf Deutsch, ohne Gedankenstriche”, „nutze Bibliothek X nicht, wir sind auf Y umgestiegen” oder „fass Ordner Z nie an”. Ertappen Sie sich dabei, dieselbe Vorgabe drei- oder viermal zu tippen, gehört sie in CLAUDE.md.

Zum Schluss

Am besten lässt sich das in einem Bild zusammenfassen: Ein KI-Agent ist ein fleißiger Junior, den man führen muss. Eine große Aufgabe nimmt er an, schafft sie aber nicht am Stück, also teilen Sie sie. Aus Erschöpfung fällt er im falschen Moment um, indem er die Autokompaktierung auslöst, also behalten Sie die Sitzung im Blick und steuern sie selbst. Um Hilfe bittet er mal, mal traut er sich nicht, also starten Sie bei Bedarf Subagenten. Wer den Kontext im Griff hat, holt aus demselben Modell deutlich verlässlichere Arbeit heraus, bei geringeren Kosten.