"Es hat ein Millionen-Token-Kontext-Fenster" wird herumgeworfen, als ob das alles löst. Tut es nicht. Ich habe das auf die langsame Art gelernt, indem ich eine ganze Codebase in einen einzigen Claude-Aufruf gesteckt und zugesehen habe, wie der Agent schlechter wurde, nicht besser. Mehr Kontext ist nicht kostenlos und ist nicht immer besser. Lassen Sie mich erklären, was ein Kontext-Fenster tatsächlich ist und wann die große Zahl Ihnen hilft versus schadet.
Was das Fenster eigentlich ist
Das Kontext-Fenster ist die maximale Anzahl von Tokens, die das Modell in einer Anfrage berücksichtigen kann – alles, was Sie senden (System-Prompt, Tools, vollständige Nachrichtenhistorie, Dateien) plus alles, was es generiert. Bei aktuellen Claude-Modellen ist das Input-Fenster groß: Opus 4.6, 4.7 und 4.8 laufen alle mit einem 1-Millionen-Token-Kontext, Sonnet 4.6 ist ebenfalls 1 Million, und Haiku 4.5 ist 200K. Die Ausgabe ist separat begrenzt – bis zu 128K Tokens bei den Opus-Modellen, 64K bei Sonnet und Haiku.
Beachten Sie, dass das zwei verschiedene Limits sind. Das Input-Limit treffen und Sie bekommen stop_reason: "model_context_window_exceeded". Das angeforderte Output-Limit treffen und Sie bekommen stop_reason: "max_tokens". Sie bedeuten verschiedene Dinge und brauchen verschiedene Fixes, also behandeln Sie beide Zweige. Menschen verwechseln sie ständig und fragen sich dann, warum das Erhöhen von max_tokens nicht geholfen hat – weil das Problem auf der Input-Seite lag.
Warum ein Token kein Wort ist
Kurze Mechanismus-Prüfung, weil sie für die Budgetierung wichtig ist. Das Modell sieht keine Wörter; es sieht Tokens, das sind Sub-Wort-Chunks, die von einem Tokenizer produziert werden. Englischer Text läuft bei ungefähr einem Token pro drei Viertel eines Wortes. Code tokenisiert dichter. Nicht-englischer Text, noch dichter.
Das bedeutet, Sie können Claude-Token-Anzahlen nicht mit tiktoken schätzen – das ist OpenAIs Tokenizer, und er zählt Claude bei einfachem Text um 15–20 % zu wenig und bei Code weit mehr. Wenn Sie eine echte Zahl brauchen, rufen Sie den count_tokens-Endpoint mit derselben Modell-ID auf, mit der Sie Inferenz durchführen. Tokenizer sind modellspezifisch. Opus 4.8 und Fable 5 teilen einen; ältere Modelle zählen anders. Verwenden Sie kein Budget wieder, das auf dem falschen Modell gemessen wurde.
Der Teil, vor dem niemand warnt: Das Fenster füllen verschlechtert die Qualität
Hier ist das Kontraintuitive. Nur weil Sie eine Million Tokens hineinstecken können, bedeutet das nicht, dass Sie es sollten. Modelle beachten Informationen, die in der Mitte eines sehr langen Kontexts vergraben sind, weniger zuverlässig, und ein verrauschter Kontext verwässert das Signal, das das Modell für den aktuellen Schritt braucht. Ich habe einen Agenten mit einem sauberen 20K-Token-Kontext den gleichen Agenten bei 400K-Tokens in derselben identischen Aufgabe übertreffen sehen, weil bei 400K 95 % von dem, worauf er achtete, veraltete Tool-Ausgabe von zwölf Schritten zuvor war.
Das Ziel ist also nicht, zu maximieren, wie viel man hineinpackt. Es geht darum, den Kontext relevant zu halten. Das Einstöckige-Millionen-Token-Limit ist ein Sicherheitsspielraum für wirklich große Einzeleingaben – ein ganzes Repo, das auf einmal analysiert werden muss, ein langes Dokument, eine tiefe Forschungsspur. Es ist keine Lizenz, niemals aufzuräumen.
Drei Tools, um Kontext relevant zu halten
Diese lösen unterschiedliche Probleme; wählen Sie nach dem, was falsch läuft.
Kontext-Bearbeitung beschneidet. Sie löscht veraltete Tool-Ergebnisse und Denk-Blöcke aus dem Transkript basierend auf Schwellenwerten, die Sie festlegen. Der gelöschte Inhalt wird entfernt, nicht ersetzt. Greifen Sie darauf zurück, wenn alte Tool-Ausgaben totes Gewicht sind und Sie ein schlankes Transkript ohne Verlust der Gesprächsstruktur wünschen. Es ist die richtige Wahl, um die Genauigkeit von Tool-Calls in langen Schleifen hoch zu halten.
Komprimierung fasst zusammen. Wenn sich ein Gespräch dem Fenster-Limit nähert, kondensiert die API die frühere Geschichte in einen Zusammenfassungs-Block serverseitig. Verwenden Sie es, wenn Sie wirklich an die Grenze stoßen werden und weitermachen müssen. Ein kritisches Gotcha: Sie müssen den vollen response.content jedes Turn an Ihre Nachrichten anhängen – die Komprimierungs-Blöcke leben darin, und wenn Sie nur den Text extrahieren und anhängen, verlieren Sie den Komprimierungs-Zustand still und alles bricht.
Gedächtnis persistiert über Sessions hinweg. Die anderen beiden operieren innerhalb eines Gesprächs; Gedächtnis sind Dateien, die der Agent liest und schreibt, die einen Prozess-Neustart überstehen. Wenn der Zustand eine Session überleben muss – Präferenzen, angesammelte Erkenntnisse, ein laufendes Notizbuch – das ist Gedächtnis, nicht Kontext. Und ehrlich gesagt arbeiten Modelle wie Opus 4.8 merklich besser, wenn Sie ihnen einen Platz geben, Dinge aufzuschreiben, und ihnen sagen, beim nächsten Mal nachzuschauen.
Viele lang laufende Agenten verwenden alle drei. Bearbeitung beschneidet die toten Turns, Komprimierung fängt Sie in der Nähe der Grenze auf, Gedächtnis hält das zwischen Runs fest, was wichtig ist.
Eine Budgetierungs-Heuristik, die mir gute Dienste geleistet hat
Stellen Sie sich vor, Ihr Kontext hat drei Zonen. Das eingefrorene Präfix (System-Prompt, Tools) – halten Sie es stabil, es ändert sich nie, und als Bonus wird es gecached. Der Arbeitssatz – die jüngsten Turns, die das Modell tatsächlich für den aktuellen Schritt braucht. Und der Schwanz – die aktuelle Frage oder das aktuelle Tool-Ergebnis. Wenn der Arbeitssatz beginnt, sich mit Dingen zu füllen, auf die das Modell in vielen Turns nicht verwiesen hat, ist das Ihr Signal zu bearbeiten oder zu komprimieren. Nicht wenn Sie eine bestimmte Token-Zahl treffen. Wenn die Relevanz abnimmt.
Noch eine praktische Anmerkung: große Ausgaben. Wenn Sie etwas in der Nähe des 128K-Output-Limits bei einem Opus-Modell anfordern, müssen Sie die Anfrage streamen. Nicht-Streaming-Aufrufe treffen SDK-HTTP-Timeouts bei hohem max_tokens – die Anfrage stirbt einfach beim Warten. Verwenden Sie den Streaming-Helper und holen Sie die finale Nachricht daraus.
Das Millionen-Token-Fenster ist eine echte Fähigkeit und manchmal genau das, was Sie brauchen. Aber die Fähigkeit besteht nicht darin, es zu füllen. Die Fähigkeit besteht darin zu wissen, wann ein enger, relevanter 30K-Kontext einen aufgeblähten 600K-Kontext schlagen wird – was meiner Erfahrung nach beim Bauen von Agenten die meiste Zeit der Fall ist.