Kontextlänge überschritten
Drei Erscheinungsformen – die letzte ist am schwersten zu erkennen
Wird das Kontextfenster überschritten, zeigt sich das auf drei Arten: als explizites 400, als stilles Abschneiden oder als äußeres 200 mit leerem Stream – Letzteres wird am häufigsten fälschlich für etwas anderes gehalten.
Aktualisiert 2026-08-27
Vier wichtige Fakten
Expliziter Fehler (am leichtesten zu erkennen)
Der Fehler-Body enthält wörtlich context_length_exceeded oder maximum context length – die Ursache ist offensichtlich.
Ein Teil Ihrer Eingabe wird unbemerkt abgeschnitten
Manche Clients/Gateways verwerfen beim Erreichen des Limits automatisch die ältesten Nachrichten, statt einen Fehler auszugeben – das Modell sieht weniger Kontext, als Sie denken, und die Ausgabe wirkt, als hätte es etwas „vergessen“.
Die Variante, die am schwersten zu erkennen ist
Der HTTP-Status ist ein sauberes 200, aber die Streaming-Verbindung endet sofort ohne ein einziges Token – leicht mit einem Netzwerkaussetzer oder einem Client-Fehler zu verwechseln.
Die eigentliche Lösung
Langen Kontext in Abschnitte aufteilen, zusammenfassen oder Retrieval-Augmented Generation (RAG) einsetzen, oder auf ein Modell mit größerem Kontextfenster wechseln – damit beheben Sie alle drei Erscheinungsformen an der Wurzel.
Wie die einzelnen Erscheinungsformen konkret aussehen
Erstens ein explizites 400: Der Response-Body enthält wörtlich context_length_exceeded oder maximum context length, die gesamte Anfrage wird abgelehnt – am leichtesten zu lokalisieren. Zweitens stilles Abschneiden: Manche SDKs, Proxy-Schichten oder Logiken zur Verlaufsverwaltung verwerfen beim Erreichen des Limits automatisch die ältesten Nachrichten, statt einen Fehler auszulösen – das Modell antwortet weiterhin normal, doch weil es den verworfenen Kontext nicht sehen kann, wirkt die Ausgabe, als hätte es frühere Gesprächsrunden „vergessen“, oder sie widerspricht sich selbst. Drittens ein äußeres 200 mit leerem Stream: Auf HTTP-Ebene sieht alles in Ordnung aus, der Status ist 200, doch die Streaming-Verbindung endet unmittelbar nach dem Öffnen ohne ein einziges ausgegebenes Token – dies wird meist fälschlich für Netzwerkschwankungen, einen Timeout oder einen Parsing-Fehler im Client gehalten, obwohl die eigentliche Ursache in der Regel darin liegt, dass die Anfrage das Kontextfenster bereits überschritten hat und serverseitig scheiterte, noch bevor das Streaming begann – nur wurde kein 400-Fehler-Body in das Streaming-Protokoll weitergereicht.
Warum das in letzter Zeit häufiger auftritt
Mit der Verbreitung von Agent- und Sub-Agent-Workflows wird es immer üblicher, eine komplette Codebasis, den gesamten Gesprächsverlauf und die Ergebnisse mehrerer Runden von Tool-Aufrufen in eine einzige Anfrage zu packen. Das erhöht die Wahrscheinlichkeit deutlich, das Kontextfenster zu überschreiten. Zudem gehen verschiedene Clients und Gateways uneinheitlich mit einem Überlauf um – manche geben einen Fehler aus, manche schneiden still ab, manche liefern einen leeren Stream –, was die Diagnose erschwert.
Zeitachse
context_length_exceeded ist ein seit Langem etablierter Standard-Fehlertyp der großen Modell-APIs – so alt wie das Konzept des Kontextfensters selbst.
Agent- und Sub-Agent-Workflows erhöhen die in einer einzigen Anfrage gebündelte Kontextmenge erheblich, sodass das Limit häufiger erreicht wird.
Die am schwersten zu erkennende Variante „äußeres 200, leerer Stream“ tritt vermehrt in vollständig agentischen Workflows auf und ist der am häufigsten falsch diagnostizierte Fall.
Bestätigt vs. verbreitete Fehldeutung
Bestätigt
Alle drei Erscheinungsformen (explizites 400, stilles Abschneiden, äußeres 200 mit leerem Stream) sind in öffentlichen Entwicklerdiskussionen und verschiedenen SDK-/Gateway-Implementierungen dokumentiert; die Ursache ist stets dieselbe: Der Anfrageinhalt (Verlauf, Ergebnisse von Tool-Aufrufen, System-Prompt) übersteigt das Kontextfenster des Modells.
Verbreitete Fehldeutung
Bei einem leeren Stream vermuten viele zuerst ein Netzwerk- oder Client-Problem und wiederholen die Anfrage immer wieder oder wechseln das Netzwerk – liegt die eigentliche Ursache in einem Kontextüberlauf, hilft das alles nicht und kostet nur Debugging-Zeit.
So erkennen Sie schnell, ob dies die Ursache ist
Zuerst die Anfragegröße prüfen
Ermitteln Sie die tatsächliche Token-Anzahl dieser Anfrage (System-Prompt + Verlauf + Ergebnisse von Tool-Aufrufen + neue Eingabe) und vergleichen Sie sie mit dem angegebenen Kontextfenster des Modells – liegt sie nahe am Limit oder darüber, ist das ein starkes Indiz.
Dann die Form der Antwort prüfen
Ein explizites 400 bestätigt es direkt; stilles Abschneiden zeigt sich darin, dass das Modell etwas „vergisst“; ein äußeres 200 mit leerem Stream zeigt sich darin, dass die Streaming-Verbindung fast sofort ohne ein einziges Token endet, nicht als Timeout.
Schritte zur Eingrenzung und Behebung
Schritt 1: Schätzen Sie die Gesamtzahl der Tokens dieser Anfrage (mit einem offiziellen Tokenizer oder einem Schätzer eines Drittanbieters) und vergleichen Sie sie mit dem Kontextfenster des Modells. Schritt 2: Liegt die Anfrage nahe am Limit oder darüber, ist nicht ein erneuter Versuch die Priorität, sondern das Kürzen der Eingabe: Fassen Sie den Verlauf zusammen bzw. komprimieren Sie ihn, behalten Sie nur die neuesten Gesprächsrunden oder wechseln Sie zu Retrieval-Augmented Generation (RAG), das nur relevante Ausschnitte statt des gesamten Verlaufs einbindet. Schritt 3: Wenn die Aufgabe tatsächlich einen langen Kontext erfordert, erwägen Sie den Wechsel zu einer Modellstufe mit größerem Kontextfenster. Schritt 4: Ergänzen Sie speziell für den Fall „äußeres 200, leerer Stream“ eine eigene Prüfung: Wird die Streaming-Verbindung geöffnet und treffen innerhalb kurzer Zeit keine Tokens ein, behandeln Sie das als Überlauf und nicht als gewöhnlichen Netzwerk-Timeout, der erneut versucht wird.
Was Sie bei QCode tun können
Das Modellangebot von QCode umfasst Familien mit unterschiedlich großen Kontextfenstern; mit demselben Key wechseln Sie je nach Aufgabengröße zu einer Modellstufe mit größerem Kontext, ohne für lange Kontexte etwas Zusätzliches beantragen oder konfigurieren zu müssen.
FAQ
Woran erkenne ich, dass ich dieses Problem habe?
Ermitteln Sie zunächst die Gesamtzahl der Tokens dieser Anfrage und vergleichen Sie sie mit dem angegebenen Kontextfenster des Modells. Liegt sie nahe am Limit oder darüber und die Antwort ist ein expliziter 400-Fehler, widersprüchliche bzw. „vergessliche“ Ausgaben (vermutete Kürzung) oder eine Streaming-Antwort, die mit null Tokens endet, ist das die Bestätigung.
Warum löst stilles Abschneiden keinen Fehler aus?
Es handelt sich um eine Fehlertoleranz-Logik, die manche Clients/Gateways selbst implementieren: Wird ein Überlauf erkannt, verwerfen sie lieber die ältesten Nachrichten, statt die gesamte Anfrage scheitern zu lassen, damit die Unterhaltung scheinbar weiterläuft – um den Preis, dass das Modell den verworfenen Kontext verliert.
Ist ein äußeres 200 mit leerem Stream ein Netzwerkproblem?
In der Regel nicht. Die häufige Ursache ist, dass die Anfrage serverseitig bereits wegen Überlaufs fehlgeschlagen ist, das zugrunde liegende System aber keinen standardmäßigen 400-Fehlerbody in das Streaming-Protokoll übertragen hat, sodass der Client „Verbindung erfolgreich, aber kein Inhalt“ sieht. Wird dieselbe zu große Anfrage erneut gesendet, entsteht höchstwahrscheinlich wieder ein leerer Stream.
Wie schätze ich, wie viele Tokens eine Anfrage tatsächlich verbraucht hat?
Zählen Sie System-Prompt, vollständigen Nachrichtenverlauf, Ergebnisse von Tool-Aufrufen und neue Eingabe zusammen, mit einem offiziellen Tokenizer oder einem Schätzer eines Drittanbieters. In agentischen bzw. Sub-Agent-Szenarien wird der Verbrauch besonders leicht unterschätzt, da die Ergebnisse jeder Tool-Aufruf-Runde in die nächste Anfrage zurückgeschrieben werden.
Löst der Wechsel zu einem Modell mit größerem Kontext das Problem dauerhaft?
Er hilft, ist aber nicht unbegrenzt: Ein größeres Kontextfenster kostet pro Anfrage meist mehr, und selbst das größte Fenster hat eine Obergrenze. Robuster ist es, zugleich die Eingabe zu kürzen (Zusammenfassung, RAG) und die Fenstergröße als Puffer zu betrachten, nicht als einzige Abhängigkeit.
Ist das dieselbe Art von Problem wie 429/529-Fehler?
Nein. 429/529 sind Rate- bzw. Kapazitätsprobleme, die nichts mit der Größe des Anfrageinhalts zu tun haben. context_length_exceeded bedeutet, dass der Anfrageinhalt selbst das übersteigt, was das Modell verarbeiten kann – Verlangsamen oder Abwarten behebt das nicht.
Quellen
Die drei Erscheinungsformen wurden aus öffentlichen Entwicklerdiskussionen und den Standardbeschreibungen der Fehlertypen über Modell-APIs hinweg zusammengestellt. Diese Seite trifft keine Aussagen über die privaten Implementierungsdetails einzelner Anbieter, sondern nur über anbieterübergreifende Muster und wie Sie sie voneinander unterscheiden. Zusammengestellt am 2026-08-27.
Lassen Sie nicht zu, dass ein Kontextüberlauf Ihre Auslieferung ausbremst
Mit einem QCode-Key wechseln Sie je nach Aufgabengröße zu einer Modellstufe mit größerem Kontext.
Weiterführende Artikel
Vier Ursachen, warum ein Stream vor Abschluss geschlossen wird
Ein weiterer häufig falsch diagnostizierter Streaming-Fehler – ein nützlicher Vergleich.
Der vollständige Leitfaden für Coding mit langem Kontext
So verwalten Sie Aufgaben mit langem Kontext systematisch.
Claude 529 vs. 429 vs. Weekly Limit
Eine weitere Gruppe leicht verwechselbarer Fehler, sauber voneinander unterschieden.
Diese Seite enthält eine allgemeine, anbieterübergreifende technische Erläuterung und trifft keine Aussagen über die private Implementierung einzelner Anbieter. Das tatsächliche Verhalten richtet sich nach dem jeweils verwendeten Modell und Client.