20 Prozent mehr Inferenzkosten: Das teure Missverständnis um AGENTS.md

Fast jedes moderne Software-Repository besitzt inzwischen eine Kontextdatei wie AGENTS.md oder CLAUDE.md. Die Annahme dahinter klingt einleuchtend: Je mehr Architektur-Zusammenfassungen und Ordnerstrukturen ein Sprachmodell vorab liest, desto präziser löst es komplexe Tickets. Die Realität liefert das exakte Gegenteil. Die Bereitstellung solcher Repository-Übersichten treibt die Inferenzkosten um über 20 Prozent nach oben, ohne die Erfolgsquote bei echten Programmieraufgaben auch nur um einen Prozentpunkt zu steigern.

Key Takeaways (TL;DR)

• Redundanz radikal streichen: Beschränke Kontextdateien auf nicht-standardisierte Projektregeln und halte allgemeine Code-Übersichten strikt aus dem System-Prompt fern.
• Inferenzkosten aktiv auditieren: Überwache den Token-Verbrauch deiner agentischen Workflows vor und nach dem Hinzufügen globaler Instruktionsdateien.
• Agenten selbst navigieren lassen: Vertraue auf die werkzeuggestützte Code-Erkundung des Modells, anstatt statische Verzeichnisbäume im Vorfeld zu füttern.
• Regeln maschinell verifizieren: Nutze deterministische Linter und CI-Schritte, statt Verhaltensweisen rein über Prompt-Prosa erzwingen zu wollen.

Basiert auf “Context Files in Coding Agents” der ETH Zürich und Logicstar.ai sowie der Analyse von Noëlle Bölling auf t3n. Das Original findest du hier: https://arxiv.org/pdf/2602.11988

Kontextdateien gelten in der Entwickler-Community als Best Practice. Modellanbieter preisen sie an, Agenten-Frameworks legen sie beim Initialisieren automatisch an, und Teams investieren Stunden in die Pflege akribischer Projektbeschreibungen. Ein Forschungsteam der ETH Zürich und des Schweizer Startups Logicstar.ai hat diese Praxis nun erstmals systematisch unter realen Bedingungen überprüft.

Vier Spitzenmodelle im Härtetest: SWE-Bench trifft auf reale Nischenprojekte

Für ihre Untersuchung bewerteten die Wissenschaftler vier etablierte Programmieragenten in Kombination mit aktuellen Frontier-Modellen: Claude Code von Anthropic mit Sonnet-4.5, Codex von OpenAI mit GPT-5.2 und GPT-5.1 Mini sowie Qwen Code von Alibaba mit Qwen3-30B-Coder.

Das Test-Setup ging dabei über künstliche Laborbedingungen hinaus. Neben dem etablierten SWE-Bench, der auf großen und prominenten Open-Source-Repositories basiert, entwickelten die Forscher den neuen Benchmark CTXbench. Dieser umfasst 138 reale GitHub-Probleme aus zwölf kleineren Nischenprojekten, die bereits von ihren Maintainern mit handgeschriebenen Kontextdateien ausgestattet worden waren.

Jede einzelne Aufgabe durchlief drei Testreihen:

1. Vollständig ohne Kontextdatei.
2. Mit einer vom jeweiligen Agenten im Vorfeld automatisiert generierten Kontextdatei.
3. Mit der originalen Kontextdatei der menschlichen Repository-Maintainer.

Automatisierte Testsuiten prüften anschließend binär, ob der erzeugte Patch das Problem tatsächlich löste. Das Ergebnis bricht mit der gängigen Intuition: Weder die handgeschriebenen noch die generierten Kontextdateien konnten die Erfolgsrate der Agenten messbar anheben. Was hingegen verlässlich stieg, waren Rechenzeit und Token-Verbrauch. Die Inferenzkosten kletterten im Schnitt um mehr als 20 Prozent.

Mehr Tests und Reviews führen nicht automatisch zu besseren Lösungen

Die qualitative Auswertung der Agenten-Logs liefert die Erklärung für diesen Widerspruch. Die Modelle ignorieren die Dateien keineswegs. Sie folgen den hinterlegten Anweisungen sehr genau. Sie führen mehr Zwischentests aus, starten zusätzliche Code-Inspektionen und formulieren ausführlichere Begründungen für ihre Änderungen.

Das Problem liegt nicht im Befolgen von Regeln, sondern im fehlenden Hebel von Architektur-Zusammenfassungen. Eine statische Zusammenfassung von Ordnerstrukturen oder Modul-Abhängigkeiten hilft einem Modell nicht dabei, die subtile Ursache einer Race Condition in Zeile 400 zu beheben.

“Konkret stellen wir fest, dass die Anweisungen in den Kontextdateien zwar von den Programmieragenten gut befolgt werden, Repository-Übersichten aber, obwohl sie beliebt sind und von Modellanbietern empfohlen werden, nicht hilfreich sind.”

Entwickler investieren wertvolle Arbeitszeit in handgeschriebene Kontextdateien, damit Agenten 20 Prozent mehr Budget verbrennen, um am Ende exakt dieselben Fehlerbilder zu produzieren. Das deckt sich mit den Beobachtungen zu explodierenden Tokenkosten: Nicht anspruchsvollere Aufgaben treiben die Rechnung, sondern ungebremster Kontextballast.

Spezifische Randbedingungen nützen, allgemeine Erklärungen schaden

Bedeutet dieser Befund, dass Entwickler sämtliche Konfigurationsdateien sofort aus ihren Repositories löschen sollten? Nicht zwingend. Hier greift eine wesentliche Unterscheidung zwischen zwei Arten von Informationen:

Auf der einen Seite stehen nicht-standardisierte Projekt-Spezifika. Wenn eine Codebasis unübliche Build-Befehle, proprietäre Test-Runner oder strikte interne Namenskonventionen erfordert, spart eine kurze Notiz dem Modell zeitraubendes Raten. Auf der anderen Seite stehen Architektur-Überblicke, Code-Zusammenfassungen und Ordner-Erklärungen. Genau dieser zweite Teil erweist sich als reiner Ballast.

Moderne Coding-Agenten navigieren Codebasen heute über Werkzeuge wie Ripgrep, Tree-Sitter und AST-Suchen. Sie erfassen den relevanten Code-Kontext dynamisch im Moment der Bearbeitung. Ein statischer Textblock im System-Prompt verbraucht nicht nur permanent teure Input-Tokens bei jedem einzelnen Iterationsschritt, sondern verwässert auch die Aufmerksamkeit des Modells auf die eigentliche Problemstellung.

Wer die Architektur seines Agenten-Harness optimieren will, muss deshalb radikal ausmisten. Das Ziel lautet nicht maximale Dokumentation im Prompt, sondern minimale, hochgradig spezifische Randbedingungen.

4 Schritte zur Umsetzung

1. Globale Repository-Übersichten löschen: Entferne alle Verzeichnisbäume, Modul-Erklärungen und Standard-Architekturmuster aus Dateien wie AGENTS.md oder CLAUDE.md.
2. Ausschließlich Ausnahmen dokumentieren: Beschränke Kontextdateien auf proprietäre Befehle, ungewöhnliche Environment-Variablen und projektspezifische Tooling-Besonderheiten.
3. Konventionen deterministisch erzwingen: Nutze Linter, Prettier und statische Typisierung in der CI-Pipeline, anstatt Code-Formatierungsregeln als Fließtext im Prompt zu beschreiben.
4. Token-Ausgaben vorab messen: Vergleiche die Erfolgsquote und den Token-Verbrauch deiner Agenten bei zehn realen Aufgaben mit und ohne Kontextdatei, bevor du globale Regeln für das gesamte Team festlegst.

Wer sein Kontextfenster mit Erklärungen flutet, kauft keine höhere Code-Qualität, sondern lediglich eine teurere Stromrechnung für den Modellanbieter.