Steuern, welchen Kontext ein Coding-Agent in eine Aufgabe mitnimmt

Warum Kontext doppelt kostet

Die Kostendokumentation von Claude Code hält fest, dass die Tokenkosten mit der Größe des Kontexts steigen und dass eine Sitzung bei jeder Anfrage die gesamte Konversation mitschickt. Prompt Caching macht den wiederholten Teil günstiger, nicht kostenlos, und die erste Nachricht nach Ablauf des Caches verarbeitet den ganzen Kontext neu.

Die zweite Kostenart ist Qualität. Anthropics Artikel zu Context Engineering beschreibt Context Rot: Mit wachsender Zahl an Tokens sinkt die Fähigkeit eines Modells, Informationen aus diesem Kontext abzurufen. Empfohlen wird die kleinste Menge aussagekräftiger Tokens, die das gewünschte Ergebnis wahrscheinlich macht. Mehr Anweisungen können also bedeuten, dass die wichtigen schlechter befolgt werden.

Wissen, was vor dem ersten Prompt geladen wird

Beginnen Sie mit einer Bestandsaufnahme pro Tool. In Claude Code werden CLAUDE.md-Dateien, Auto Memory, MCP-Tool-Namen und Skill-Beschreibungen geladen, bevor Sie etwas eingeben, und /context zeigt eine aktuelle Aufschlüsselung. MCP-Tool-Definitionen werden standardmäßig verzögert geladen, sodass bis zur Nutzung eines Tools nur Namen und Server-Anweisungen in den Kontext kommen. In Cursor stehen immer angewendete Regeln am Anfang des Kontexts, eine CLAUDE.md wird immer angewendet, und eine in einer Regel mit @ referenzierte Datei wird erst bei Bedarf gelesen, nicht eingefügt.

Jede Anweisung einer Ebene zuordnen

• Immer geladen: Vorgaben, die in jeder Sitzung gelten und die der Agent nicht aus dem Code ableiten kann, etwa Build- und Testbefehle, Pfade, die er nie ändern darf, und Sicherheitsregeln. Diese Ebene bleibt kurz.
• Pfadbezogen: Konventionen für ein Paket oder einen Dateityp, in verschachtelten Anweisungsdateien oder Regeln mit Pfaden oder Globs, die laden, wenn der Agent passende Dateien anfasst.
• Bei Bedarf: Abläufe wie das Schreiben einer Migration oder die Vorbereitung eines Releases, als Skills, die nur geladen werden, wenn sie aufgerufen oder als relevant eingeschätzt werden.
• Nirgends: alles, was der Agent aus dem Code selbst lesen kann, und alles, was ein Linter oder die CI bereits durchsetzt.

Eine Vorgabe, die unabhängig vom Kontext gelten muss, gehört zusätzlich in Berechtigungen, Hooks oder die CI. Claude Code behandelt Anweisungsdateien als Kontext, nicht als Konfiguration. Eine Kürzung, die eine Regel aus dem Kontext entfernt, darf also nie das Einzige sein, was zwischen dem Agenten und einem geschützten Pfad steht.

Die Falle in langen Sitzungen

Wer Anweisungen in Bereiche verschiebt, die bei Bedarf laden, ändert, wann sie vorhanden sind. Die Claude-Code-Dokumentation beschreibt, was bei der Komprimierung passiert: Die CLAUDE.md im Projektwurzelverzeichnis und Regeln ohne Pfad werden von der Festplatte neu eingefügt, pfadbezogene Regeln und verschachtelte CLAUDE.md-Dateien dagegen werden mit zusammengefasst und kommen erst zurück, wenn wieder eine passende Datei gelesen wird. Aufgerufene Skills kehren gekürzt auf 5.000 Tokens pro Skill und 25.000 insgesamt zurück, wobei der Anfang jeder Datei erhalten bleibt.

Eine Regel, die eine ganze Sitzung lang gelten muss, sollte also nicht pfadbezogen sein, und die wichtigsten Zeilen eines Skills gehören nach oben. Die Dokumentation sagt dasselbe: Muss eine Regel die Komprimierung überstehen, entfernen Sie die Pfade oder verschieben Sie sie in die Datei im Wurzelverzeichnis.

Hebel jenseits der Anweisungsdateien

• Tool-Ausgaben filtern, bevor der Agent sie sieht. Die Claude-Code-Dokumentation zeigt einen Hook, der Testausgaben auf Fehlschläge reduziert.
• Umfangreiche Arbeit wie Log-Analysen an einen Subagenten geben, der eine Zusammenfassung zurückliefert. Seine eigenen Anfragen zählen trotzdem zur Nutzung, das verkleinert also den Hauptkontext, senkt aber nicht unbedingt die Rechnung.
• MCP-Server abschalten, die niemand nutzt, und eine CLI bevorzugen, wo es sie gibt, was die Dokumentation als kontexteffizienter beschreibt.
• Die Sitzung zwischen unabhängigen Aufgaben leeren, da alte Konversation mit jeder Nachricht erneut gesendet wird.

Die Kürzung an denselben Aufgaben messen

Ein hypothetischer Check für ein Repository: Spielen Sie 20 gemergte Aufgaben mit dem aktuellen und dem gekürzten Setup nach, jeweils dreimal. Jeder Lauf beginnt in einer isolierten Kopie, deren Historie vor der Änderung endet, ohne spätere Refs, Remotes, Caches, Memory oder Dateien aus früheren Durchläufen und ohne Netzwerkweg zur gemergten Lösung. Der Agent sieht die vorhandenen Tests; die mit jeder Änderung hinzugefügten Akzeptanztests werden für die Bewertung zurückgehalten. Erfassen Sie die Kosten pro bestandener Aufgabe, die Erfolgsquote auf den zurückgehaltenen Tests und eine per Skript gezählte Zahl an Verstößen gegen Vorgaben, etwa Änderungen an generierten Pfaden. Übernehmen Sie das gekürzte Setup, wenn die Verstöße nicht steigen und die Erfolgsquote innerhalb einer vorher vereinbarten Schwelle bleibt. Ist die Stichprobe zu klein für eine Aussage, ist das Ergebnis nicht eindeutig, und das aktuelle Setup bleibt.

LLM-KostenoptimierungClaude-Code-Anweisungen im Team aktuell halten