Context Rot

Was ist Context Rot?

Context Rot ist die allmähliche Verschlechterung der Output-Qualität eines Sprachmodells, während sich sein Context Window über eine lange Sitzung hinweg mit veralteter, widersprüchlicher oder irrelevanter Information füllt. Das Modell beginnt, alte Anweisungen mit aktuellen zu verwechseln, verworfene Ansätze zu wiederholen und den Überblick darüber zu verlieren, was tatsächlich zählt, obwohl sich am Modell selbst nichts geändert hat.

Die wichtigsten Punkte

• Context Rot ist eine Eigenschaft der Sitzung, nicht des Modells. Dasselbe Modell, das bei Runde fünf gut performte, kann bei Runde achtzig mit verschmutztem Kontext inkompetent wirken.
• Die Hauptursachen sind angehäufte Sackgassen, zu unterschiedlichen Zeitpunkten gegebene widersprüchliche Anweisungen und große Tool-Outputs, die das Signal begraben.
• Größere Context Windows verzögern Rot, verhindern ihn aber nicht. Modelle achten über lange Kontexte hinweg ungleichmäßig, sodass Müll in der Mitte die Ergebnisse trotzdem verschlechtert. Beim NoLiMa-Long-Context-Benchmark von 2025 fielen 11 von 13 getesteten Modellen bei 32K Tokens unter 50 % ihrer starken Short-Context-Baselines, wobei GPT-4o von 99,3 % auf 69,7 % fiel [1].
• Die Fixes sind operativ: die Sitzung komprimieren oder zusammenfassen, mit einem destillierten Briefing frisch starten, und bewusstes Context Engineering praktizieren, statt Verlauf sich auftürmen zu lassen.

So funktioniert es

Jede Nachricht, jedes Tool-Ergebnis und jeder Datei-Dump in einer Sitzung bleibt im Context Window und konkurriert um die Aufmerksamkeit des Modells. Früh in einer Sitzung ist dieser Verlauf größtenteils nützlich. Mit der Zeit häuft er gescheiterte Versuche, überholte Pläne, Fehlerlogs von bereits behobenen Problemen und Anweisungen an, die die nutzende Person später zurückgenommen hat. Das Modell hat keinen eingebauten Mechanismus, um irgendetwas davon als obsolet zu markieren. Es sieht ein langes Transkript und gewichtet alles davon.

Zwei Effekte verstärken das Problem. Erstens achten Modelle über lange Inputs hinweg ungleichmäßig, sodass relevante, mitten im Kontext vergrabene Details weniger Gewicht bekommen als Material nahe Anfang oder Ende. Chromas Bericht vom Juli 2025, der das Phänomen benannte, evaluierte 18 Modelle, darunter GPT-4.1, Claude 4 und Gemini 2.5, und fand, dass sich die Leistung mit wachsender Input-Länge konsistent verschlechtert, wobei schon ein einzelner Störfaktor im Kontext die Genauigkeit gegenüber der Baseline senkt [2]. Zweitens häufen sich Widersprüche an: Wenn die nutzende Person bei Runde zehn "nutze REST" sagte und bei Runde vierzig "wechsle zu GraphQL", sitzen beide Anweisungen im Kontext, und unter Druck fällt das Modell manchmal auf die frühere zurück. Das praktische Symptom ist ein Agent, der einen Ansatz erneut vorschlägt, den Sie vor einer Stunde abgelehnt haben, oder eine Datei anhand einer Version bearbeitet, die nicht mehr existiert.

Deshalb liefern agentische Coding-Tools Compaction-Features aus, die eine Sitzung zusammenfassen und das rohe Transkript verwerfen, und deshalb behandeln erfahrene Praktiker die Sitzungslänge als Budget. Agent-Memory-Systeme existieren teilweise, um dauerhafte Fakten aus dem Transkript in einen Speicher zu verschieben, der sauber abgerufen wird, statt den gesamten Verlauf mitzuschleppen.

Beispiel

Ein Ingenieur verbringt drei Stunden in einer Sitzung mit einem KI-Coding-Agenten, um einen Zahlungsservice zu migrieren. Früh erkundete der Agent einen Migrationspfad über einen Kompatibilitäts-Shim, den der Ingenieur ablehnte. Fünfzig Runden später, gebeten, das finale Cutover-Skript zu schreiben, führt der Agent den Shim still wieder ein, weil die Erkundung noch immer im Kontext sitzt und sich wie bereits geprüfter Ansatz liest. Der Ingenieur bemerkt es, beendet die Sitzung und startet eine neue mit einem fünfzeiligen Briefing: aktueller Zustand, gewählter Ansatz, betroffene Dateien, Einschränkungen, nächste Aufgabe. Der frische Agent produziert das korrekte Skript beim ersten Versuch. Dasselbe Modell, dieselbe Aufgabe, sauberer Kontext.

Häufige Missverständnisse

Der häufige Fehler ist anzunehmen, das Modell sei mitten in der Sitzung schlechter geworden, und dann das Modell zu wechseln oder einen Bug zu melden. Verschlechterung in langen Sitzungen liegt fast immer am Kontext, nicht an den Gewichten. Der Test ist billig: die Aufgabe in einer frischen Sitzung mit nur den relevanten Fakten neu formulieren. Wenn die Qualität zurückschnellt, haben Sie gegen Context Rot gekämpft, und der Fix ist Sitzungshygiene statt ein anderes Modell.

FAQ

Wie erkenne ich, dass eine Sitzung verrottet ist? Achten Sie auf die klassischen Anzeichen: Der Agent lässt abgelehnte Ansätze wiederauferstehen, widerspricht seinen eigenen jüngsten Aussagen, fragt nach bereits Geklärtem, oder bearbeitet Dateien anhand veralteter Versionen. Jedes davon bedeutet, dass das Transkript gegen Sie arbeitet.

Behebt Compaction Context Rot? Größtenteils. Die Sitzung zusammenzufassen und den rohen Verlauf zu verwerfen entfernt Sackgassen und veralteten Tool-Output, wo der meiste Rot lebt. Der Kompromiss ist, dass eine schlechte Zusammenfassung ein tragendes Detail verlieren kann, weshalb kritische Einschränkungen in eine CLAUDE.md-artige stehende Datei gehören, nicht nur ins Transkript.

Ist Context Rot dasselbe wie ein volles Context Window? Nein. Das Erreichen des Fenster-Limits ist ein harter Kapazitätsfehler. Context Rot verschlechtert die Qualität lange vor dem Limit, oft wenn das Fenster erst zur Hälfte voll ist, weil das Problem der Inhalt des Kontexts ist, nicht seine Größe.

Quellen

1. Modarressi et al., arXiv (NoLiMa). "11 von 13 Modellen fielen bei 32K Tokens unter 50 % der Short-Context-Baselines; GPT-4o fiel von 99,3 % auf 69,7 %." https://arxiv.org/abs/2502.05167. Abgerufen im August 2026.
2. Chroma Research. "Context-Rot-Bericht: 18 Modelle evaluiert; Leistung verschlechtert sich mit wachsender Input-Länge, ein einzelner Störfaktor senkt die Genauigkeit." https://www.trychroma.com/research/context-rot. Abgerufen im August 2026.