Context Engineering beginnt mit einer Inventur: Ein Kontextfenster, das du nicht auflisten kannst, kannst du nicht budgetieren

Context Engineering hat einen kanonischen Text. Anthropic hat ihn im September 2025 veröffentlicht, und seine Definition ist bis heute die, die zitiert wird:

Context engineering refers to the set of strategies for curating and
maintaining the optimal set of tokens (information) during LLM inference,
including all the other information that may land there outside of the prompts.

Lies den letzten Halbsatz noch einmal. Informationen, die dort landen können. Die Definition sagt nebenbei, dass ein guter Teil des Fensters nicht von dir hineingelegt wird. Der Leitfaden weiß das genau. Er hat ganze Abschnitte über Agenten, die sich ihre Daten selbst holen, und über Verläufe, die von allein wachsen. Was er als Antwort darauf lehrt, ist das Auswählen.

Leitfäden zu Context Engineering lehren, das Fenster zu kuratieren, nicht es zu sehen

Die Praktiken sind durchweg Verben des Auswählens. Halte die Systemanweisungen auf dem minimalen Satz an Informationen, der das gewünschte Verhalten vollständig beschreibt. Kuratiere ein minimal tragfähiges Set an Tools mit wenig Überschneidung. Nimm ein paar kanonische Beispiele statt eines Haufens von Randfällen. Rufe just in time ab und halte Pfade und Links vor, nicht die Dokumente, auf die sie zeigen. Bei langer Arbeit verdichte den Verlauf, lass den Agenten Notizen außerhalb des Fensters führen und gib klar umrissene Aufgaben an Sub-Agenten, die frisch starten. Zwei Formulierungen aus dem Leitfaden tragen den Rahmen unter alldem:

a finite resource with diminishing marginal returns
the smallest possible set of high-signal tokens

Ich stimme jeder einzelnen dieser Praktiken zu. Mein Einwand gilt der Reihenfolge. Jede davon ist ein Eingriff, und ein Eingriff hat ein Objekt. Was genau kürzen? Und wessen Text steckt in dem Verlauf, den du verdichtest? Der Leitfaden verlangt, den gesamten Zustand zu betrachten, der dem Modell in einem bestimmten Moment zur Verfügung steht, und er kennt keinen Schritt, der dir diesen Zustand vor Augen führt. Es ist ein Leitfaden zum Kuratieren ohne einen Arbeitsablauf fürs Hinsehen, und in einem Agenten-Harness ist der Teil des Fensters, den du als deinen wiedererkennen würdest, klein.

Was ein Kontextfenster von Claude Code enthält, bevor du tippst

Wie klein, zeigt die Dokumentation von Claude Code klarer als alles, was ich sonst kenne. Der Walkthrough einer Session dort listet auf, was vor dem ersten Prompt lädt: die Systemanweisungen des Harness selbst, der Index des Auto-Memory, Umgebungsinformationen, die Namen der MCP-Tools, einzeilige Beschreibungen der Skills, deine CLAUDE.md auf Benutzerebene und die CLAUDE.md des Projekts. Jeder dieser Punkte ist als im Terminal unsichtbar markiert. Die Token-Zahlen im Walkthrough sind als illustrativ gekennzeichnet, aber es geht um das Verhältnis: Die Startblöcke summieren sich auf rund 7.850 Tokens, und der Prompt, den der Nutzer danach tippt, hat 45. Der Walkthrough zieht den Schluss selbst:

Your prompt is tiny compared to what's already loaded.

Das setzt sich fort, sobald die Arbeit beginnt. Eine gelesene Datei erscheint im Terminal als einzeilige Meldung, während die 2.400 Tokens Dateiinhalt nur ans Modell gehen. Eine pfadgebundene Regel lädt, weil der Agent eine passende Datei angefasst hat, und du siehst, dass sie geladen wurde, nicht was drinsteht. Ein Formatierungs-Hook meldet sich über ein Feld zurück, das in den Kontext gelangt und nie auf dem Bildschirm auftaucht. Nichts davon ist geheim. Es steht alles in der Doku. Du hast nur nichts davon in dem Moment gewählt, in dem es ankam.

Das Fenster hat also mehrere Arten von Autoren, bevor die Session eine Minute alt ist. Du hast den Prompt geschrieben und, vor einiger Zeit, die Instruktionsdateien. Der Hersteller hat die Systemanweisungen geschrieben. Wer auch immer einen MCP-Server oder einen Skill veröffentlicht hat, hat dessen Beschreibung geschrieben. Wer zuletzt ins Repository committet hat, hat die Dateien geschrieben, die gelesen werden, und ich habe schon früher argumentiert, dass eine Datei, die ein Fremder bearbeiten kann, eine andere Vertrauensstufe ist als eine Regel, die nur du schreiben kannst. Ein früherer Lauf des Modells hat den Memory-Index geschrieben.

/context in Claude Code ist schon die halbe Kontext-Inventur

Der naheliegende Einwand lautet, dass es die Auflistung gibt. Es gibt sie, und sie ist besser, als die Leitfäden erkennen lassen. /context gibt eine Aufschlüsselung des Fensters nach Kategorie mit Token-Zahlen aus, und /context all klappt sie pro Eintrag auf. Unter v2.1.296, ausgeführt als claude -p '/context', hat der Bericht eine Tabelle pro Art von Konfiguration. Schematisch, links der Name des Abschnitts, rechts seine Spaltenköpfe:

Estimated usage by category    Category   | Tokens | Percentage
MCP Tools                      Tool       | Server | Tokens
Custom Agents                  Agent Type | Source | Tokens
Memory Files                   Type       | Path   | Tokens
Skills                         Skill      | Source | Tokens

Das ist eine echte Inventur der Konfiguration. In demselben Essay vom August habe ich gesagt, dass ein geschichtetes Setup lesbar bleibt, solange sich eine enge Frage beantworten lässt: welche Anweisung welchen Agenten erreicht, und wer sie dort ablegen durfte. Dieser Bericht beantwortet die erste Hälfte für die Dateien auf der Platte. Er hat eine Kostenspalte. Seine Spalten Source, Server und Path sind Hinweise auf die Herkunft: Diese Spalten sagen, von wo ein Block geladen wurde, aus einem Plugin oder deinem eigenen Verzeichnis, aus dieser Datei oder jener. Wer ihn ändern kann, sagen sie nicht, und das ist die Hälfte der Frage, die für Vertrauen zählt, aber mit ihnen würdest du anfangen. Es ist auch das Werkzeug, um in deiner eigenen Session die Zahl nachzuprüfen, auf die ich mich gestützt habe, als ich Tool-Definitionen ein Budget nannte.

Die Auflistung ist selbst Software mit einer Geschichte. Vor v2.1.196 zählte die Skills-Zeile den vollen Text jeder Skill-Beschreibung und konnte eine Zahl zeigen, die um ein Mehrfaches über dem lag, was das Modell erhielt. Vor v2.1.280 lag eine AGENTS.md, die Claude Code direkt las, im Fenster und fehlte in der Liste. Das ist die Lücke, die ich beschrieben habe, als die Unterstützung für AGENTS.md kam. Beides ist inzwischen behoben. Ich erwähne es, weil eine Auflistung eine Behauptung über das Fenster ist, aufgestellt von Code, der sich irren kann, und ein Abschnitt, der in der Liste fehlte, hat deshalb noch nie im Kontext gefehlt.

Die Messages-Zeile von /context in Claude Code ist die Stelle, an der die Inventur aufhört

Der zweite Punkt an dem Bericht betrifft seine Struktur. Die Unterhaltung selbst ist in derselben Ausgabe eine Zeile der Kategorientabelle:

Messages

Eine Zeile und eine Zahl. Darin stecken deine eigenen Turns, die Antworten des Modells, jede Datei, die es gelesen hat, jede Befehlsausgabe, jedes Tool-Ergebnis von jedem Server, alles, was ein Hook eingespeist hat, die pfadgebundenen Regeln, die unterwegs geladen wurden, und nach einer Compaction eine vom Modell geschriebene Zusammenfassung von alldem. Der aufgeschlüsselte Teil des Berichts deckt Dinge ab, die auf der Platte liegen und die du ohnehin hättest öffnen können. Der summierte Teil ist der, in dem die Herkunft gemischt ist: Eine abgerufene Seite und eine Zeile, die du getippt hast, sind Tokens in derselben Zeile, und sie sollten nicht denselben Rang haben.

Das Rohmaterial ist nicht weg. Das Session-Transkript auf der Platte behält jede Nachricht, jeden Tool-Aufruf und jedes Tool-Ergebnis. Der Transkript-Viewer zeigt die Tool-Aktivität im Detail. Ein InstructionsLoaded-Hook kann jede Instruktionsdatei samt dem Grund protokollieren, aus dem sie geladen wurde. Was keines davon tut: sich als Inventur des aktuellen Fensters lesen lassen, also dieser Abschnitt, so viele Tokens, geschrieben von dieser Partei, hier bis zu jenem Ereignis. Du kannst es rekonstruieren. Niemand reicht es dir. Und ein Abschnitt lässt sich aus dem Fenster überhaupt nicht rekonstruieren. Eine Compaction-Zusammenfassung schreibt alles neu, was sie berührt, sodass die Herkunft, die als ein Dutzend beschrifteter Ergebnisse hineinging, als ein einziger Block in der Stimme des Modells herauskommt. Um genau diesen Fall ging es im Argument über den Autor eines Abschnitts: ein Etikett, das beim Einlass vergeben wird und im Fenster überleben müsste, es aber nicht tut.

Eine Inventur des Kontextfensters braucht eine Spalte für die Lebensdauer, nicht nur eine Token-Zahl

Die andere fehlende Spalte ist die Zeit. Eine Token-Zahl sagt, wie viel Platz ein Abschnitt jetzt einnimmt. Sie sagt nicht, was ihn beenden wird, und Abschnitte in derselben Session enden auf sehr unterschiedliche Weise.

Claude Code dokumentiert das sorgfältiger als jeder Leitfaden zu Context Engineering, in einer Tabelle dazu, was mit jedem Mechanismus bei der Compaction geschieht. Die CLAUDE.md im Projektstamm und das Auto-Memory werden von der Platte neu eingespeist. Pfadgebundene Regeln und verschachtelte CLAUDE.md-Dateien wurden in den Nachrichtenverlauf geladen, also werden sie mit ihm zusammengefasst und laden erst wieder, wenn erneut eine passende Datei angefasst wird. Kontext, den ein Hook früher hinzugefügt hat, wird mit dem Rest zusammengefasst. Die Texte aufgerufener Skills kommen zurück, gedeckelt auf 5.000 Tokens pro Skill und 25.000 insgesamt, die ältesten fallen zuerst weg, und der Walkthrough ergänzt, dass die Startliste der Skill-Beschreibungen nach einer Compaction nicht neu eingespeist wird. Bis zu fünf der Dateien, die der Agent gelesen oder bearbeitet hat, werden erneut gelesen, und eine mit mehr als 5.000 Tokens kommt als Pfad ohne Inhalt zurück. Der Troubleshooting-Hinweis zu einer verschwundenen Anweisung liest sich wie eine ausformulierte Lebensdauer-Spalte:

If an instruction disappeared after compaction, it was given only in
conversation, lives in a nested CLAUDE.md that hasn't reloaded yet, or is
a path-scoped rule that hasn't matched a file since.

Drei Regeln mit identischem Wortlaut und identischen Token-Kosten können an drei dieser Orte liegen. Die erste wird jedes Mal von der Platte neu geladen. Die zweite kommt erst zurück, wenn wieder eine passende Datei geöffnet wird. Die dritte übersteht eine Compaction nur, wenn die Zusammenfassung sie zufällig behält, und ob sie das tut oder nicht, die Session sieht danach genauso aus wie vorher. Nichts in einer Token-Tabelle unterscheidet sie.

Lebensdauer gilt auch quer, von Fenster zu Fenster. Ein frischer Sub-Agent, einer, der kein Fork der Unterhaltung ist, startet mit einem eigenen Fenster. Die CLAUDE.md-Dateien laden dort erneut, es sei denn, der Agent ist einer der eingebauten Recherche-Agenten oder so konfiguriert, dass er sie weglässt, und das Auto-Memory der Haupt-Session lädt nicht. Eine Regel, die du als immer vorhanden zählst, ist pro Fenster vorhanden. Das ist ein Grund mehr, warum ein geschriebenes Briefing, bei dem du jede Zeile gewählt hast, leichter nachzuhalten ist als ein geerbtes Transkript.

Warum ein Kontextfenster-Budget aus Token-Zahlen den falschen Abschnitt streicht

Wer aus einer Token-Tabelle budgetiert, streicht, was groß ist. In einer Session mit Claude Code sind die zwei großen Zeilen, an die du herankommst, die Tool-Definitionen und deine eigene Instruktionsdatei. Die erste zu kürzen ist richtig, und dafür habe ich plädiert. Die zweite zu kürzen, indem du Details aus der CLAUDE.md in pfadgebundene Regeln und Skills verschiebst, ist für die Kosten ebenfalls ein guter Rat. Es ist ein Tausch von Lebensdauer gegen Tokens, und die beiden werden selten im selben Satz genannt: Die verschobene Regel lädt jetzt auf einen Auslöser hin, und nach einer Compaction bleibt von ihr, was die Zusammenfassung behalten hat, bis der Auslöser wieder greift.

Der umgekehrte Fehler ist leiser. Ein Abschnitt kann billig sein und trotzdem der, der den Lauf entscheidet. Ein paar hundert Tokens Tool-Ergebnis mit einem Satz, der als Anweisung formuliert ist, kosten auf keinem Zähler nennenswert etwas. Ein Budget ordnet nach Größe, und weder Rang noch Beständigkeit hängen mit Größe zusammen.

Die Reihenfolge, für die ich plädiere, ist also: zuerst die Inventur, mit drei Spalten pro Abschnitt, dann das Budget. Autor: wer diesen Text geschrieben haben könnte und wer ihn ohne dich ändern kann, und das ist nicht immer die Partei, die ihn ausgegeben hat. Kosten: wie viele Tokens er belegt, und bei wie vielen Anfragen. Lebensdauer: was ihn beendet, sei es eine Compaction, ein Reset, das Ende eines Sub-Agenten oder nichts außer dir, wenn du eine Datei bearbeitest, und in dieser Zelle darf ruhig „bedingt“ stehen. Budgetieren beantwortet eine Frage zu einem Abschnitt, nämlich ob er seinen Platz wert ist. Die Inventur lässt dich die anderen zwei bei jedem Abschnitt stellen, auch bei den großen, die du selbst geschrieben hast: Auf wessen Wort hin handelt der Agent hier, und gilt das in einer Stunde noch?

Was dir eine Inventur des Kontextfensters nicht sagen kann

Eine Inventur ist eine Momentaufnahme von etwas, das sich bewegt. Sie sagt dir, was im Fenster liegt, nicht was das Modell damit gemacht hat. Ein Abschnitt kann aufgelistet, zugeordnet und datiert sein und trotzdem ignoriert werden, oder gegen einen widersprechenden Abschnitt abgewogen werden und verlieren, und keine Auflistung zeigt das. Sie gilt außerdem pro Fenster, also hat ein System aus mehreren Agenten mehrere Inventuren und keinen Ort, an dem sie sich aufsummieren.

Wenn du direkt auf der API baust, bist du der Harness, und die Inventur ist dein eigener Code, der die Anfrage zusammensetzt. Das ist die leichtere Position. Du kannst die Quelle und die beabsichtigte Lebensdauer jedes Abschnitts in dem Moment festhalten, in dem du ihn hinzufügst, und einen besseren Moment gibt es nicht: Später muss beides erschlossen werden.

Context Engineering wird meist als die Entscheidung beschrieben, was das Modell sehen soll. Diese Entscheidung gibt es wirklich. Sie kommt aber an zweiter Stelle. An erster steht herauszufinden, was das Modell schon sieht, wer es dort hingelegt hat und wie lange es bleibt. Claude Code beantwortet die erste dieser Fragen für die Dateien auf deiner Platte. Für die Unterhaltung, die den größten Teil einer langen Session ausmacht, besteht die angebotene Antwort weiterhin aus einer einzigen Zahl und einem Transkript, das du dir selbst durchlesen kannst.