NSIG_

Jede Runde zahlt die ganze Vorgeschichte

Vom Themen KI · Modelle

Ein Gespräch läuft gut an. Nach zwanzig Runden antwortet dasselbe Modell auf dieselbe Art Frage schlechter, vergisst, was in Runde drei stand, und die Abrechnung ist deutlich höher, obwohl die Fragen nicht länger geworden sind.

Das sieht nach zwei Problemen aus und ist eines. Es liegt nicht am Modell und nicht an der Frage, sondern an dem, was mit jeder Runde mitgeschickt wird.

Es gibt kein Gedächtnis, es gibt eine Anlage

Die Dokumentation von Anthropic nennt das Kontextfenster einen Arbeitsspeicher: alles, was das Modell beim Erzeugen einer Antwort heranziehen kann, samt der Antwort selbst. Google beschreibt dieselbe Sache über eine Entsprechung, nämlich das Kurzzeitgedächtnis, in dem nur eine begrenzte Menge Platz hat.

Der entscheidende Satz steht bei Anthropic direkt daneben, und er ist der Grund für die Rechnung: Alles in der Anfrage zählt gegen das Fenster. Die Doku zählt auf, was gemeint ist: der System-Prompt, jede Nachricht in messages einschließlich Werkzeug-Ergebnissen, Bildern und Dokumenten, und die Werkzeug-Definitionen. Die erzeugte Ausgabe zählt ebenfalls, das Nachdenken eingeschlossen.

Eine Unterhaltung hat also keinen Zustand, den der Anbieter für dich aufbewahrt. Sie hat eine Eingabe, die bei jeder Runde die ganze Vorgeschichte enthält. Die Doku beschreibt das als fortlaufende Anhäufung: Mit jedem Zug sammeln sich Nachricht und Antwort im Fenster an, und frühere Züge bleiben vollständig erhalten. Die Eingabephase jedes Zuges enthält den kompletten bisherigen Gesprächsverlauf plus die neue Nachricht.

Daraus folgt die Kostenkurve, und sie ist keine Gerade. Was du in Runde 1 einmal bezahlt hast, bezahlst du in Runde 20 zum zwanzigsten Mal. Nicht weil etwas teurer geworden wäre, sondern weil es zwanzigmal geschickt wurde. Das ist eine Rechnung aus dem, was oben steht, und keine Angabe der Doku.

Wie groß das Fenster ist

Die Doku nennt elf Modelle mit einem Fenster von 1 Million Token, und das ist die ganze Liste: Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 5, Claude Sonnet 4.6 und Claude Mythos Preview. Eine einzelne Anfrage an eines davon kann bis zu 128k Ausgabe-Token erzeugen. Die übrigen Claude-Modelle, Claude Sonnet 4.5 ausdrücklich eingeschlossen, haben ein Fenster von 200k Token.

Zwei Angaben daneben sind beim Rechnen nützlich. Bei jedem Modell mit 1-Millionen-Fenster ist 1 Million der Standard: keine Beta-Kopfzeile nötig, und Anfragen mit langem Kontext werden zum normalen Preis abgerechnet. Und es gibt eine zweite Obergrenze neben den Token: bis zu 600 Bilder oder PDF-Seiten je Anfrage, bei den Modellen mit 200k-Fenster 100. Wer viele Bilder oder große Dokumente schickt, stößt laut Doku womöglich an Größengrenzen der Anfrage, bevor die Token-Grenze erreicht ist.

Warum es schwächer wird, und warum das kein Ausrutscher ist

Die Doku benennt den Effekt und gibt ihm einen Namen: Mit wachsender Token-Zahl nehmen Genauigkeit und Erinnerungsvermögen ab, ein Phänomen, das dort context rot heißt. Der Satz, der daraus folgt, steht im selben Absatz: Was im Kontext steht zu kuratieren ist genauso wichtig wie der Platz, der zur Verfügung steht.

Warum das so ist, steht ausführlicher in einem Text des Applied-AI-Teams von Anthropic vom 29.09.2025. Er ist die älteste Quelle dieser Notiz, und sein Alter zählt hier: Die Modellnamen darin sind überholt, die Begründung ist strukturell. Drei Gründe nennt er, und sie hängen zusammen:

  • Ein Aufmerksamkeitsbudget. Wie Menschen mit begrenztem Arbeitsgedächtnis hätten Sprachmodelle ein Budget, aus dem sie beim Verarbeiten großer Kontextmengen schöpfen. Jedes neue Token zehrt daran
  • Die Bauform. Transformer erlauben jedem Token, sich auf jedes andere zu beziehen. Das ergibt n² paarweise Beziehungen bei n Token, und mit wachsender Länge wird die Fähigkeit, diese Beziehungen zu erfassen, dünn
  • Die Trainingsverteilung. Modelle entwickeln ihre Aufmerksamkeitsmuster aus Daten, in denen kürzere Folgen häufiger sind. Sie haben also weniger Erfahrung mit Abhängigkeiten über den ganzen Kontext hinweg

Zwei Einordnungen aus derselben Quelle gehören dazu, weil sie in beide Richtungen vor Übertreibung schützen. Erstens: Manche Modelle bauen sanfter ab als andere, aber die Eigenschaft trete bei allen Modellen auf. Das ist die Aussage der Quelle, nicht meine Verallgemeinerung. Zweitens: Es handle sich um ein Leistungsgefälle und nicht um eine Klippe. Modelle blieben bei längerem Kontext sehr leistungsfähig und zeigten lediglich verringerte Genauigkeit beim Abrufen von Informationen und beim Schließen über weite Strecken.

Google beschreibt dasselbe von der Messseite her. In den Tests nach dem Muster „Nadel im Heuhaufen“ erreichten die Gemini-Modelle hohe Werte, aber diese Tests betrachteten den einfachsten Aufbau mit einer einzigen Nadel. Bei mehreren gesuchten Informationsstücken arbeite das Modell nicht mit derselben Genauigkeit, und die Leistung könne je nach Kontext stark schwanken. Die Zahl, die dort steht: ungefähr 99 Prozent bei einer einzelnen Abfrage. Um 100 Informationsstücke mit dieser Güte zu bekommen, müsse man wahrscheinlich 100 Anfragen schicken.

Was beim Überlauf passiert, und es sind drei verschiedene Dinge

Hier wird es praktisch, denn die drei Fälle sehen von außen ähnlich aus und verlangen verschiedene Antworten.

Erstens: Die Eingabe allein ist größer als das Fenster. Dann gibt die Schnittstelle laut Doku auf jedem Modell einen 400er zurück, invalid_request_error mit dem Text „prompt is too long“. Das ist ein Fehler, keine Antwort, und es gibt nichts zu bezahlen und nichts zu retten.

Zweitens: Eingabe plus max_tokens ist größer als das Fenster. Auf den Modellen ab Claude 4.5 nimmt die Schnittstelle die Anfrage trotzdem an. Stößt die Erzeugung dann an die Grenze, bricht sie nicht mit einem Fehler ab, sondern hört mit stop_reason: "model_context_window_exceeded" auf. Die Antwort ist gültig und abgeschnitten, und die Doku sagt beides so. Auf früheren Modellen kommt stattdessen ein Validierungsfehler; wer dieses Verhalten dort haben will, setzt die Beta-Kopfzeile model-context-window-exceeded-2025-08-26.

Eine Voraussetzung steht auf der Seite zu den Abbruchgründen und nirgends sonst: Dieser Wert ist derzeit nur im Beta-Namensraum der SDKs typisiert. Die Beispiele der Doku rufen deshalb client.beta.messages auf und benutzen die Typen mit Beta-Vorsatz. Wer mit dem normalen Namensraum arbeitet, hat Modell, Nachricht und Aufbau richtig und bekommt den Fall trotzdem nicht sauber in die Hand.

Ein Detail, das die Quellen selbst verschieden schreiben und das man deshalb nicht glätten sollte: Die Seite zum Kontextfenster sagt „On Claude 4.5 models and newer“, die Seite zu den Abbruchgründen sagt „On Sonnet 4.5 and newer models“. Wer auf etwas Älterem als Claude Sonnet 4.5 baut, setzt die Kopfzeile besser, statt sich auf die weitere der beiden Formulierungen zu verlassen.

Drittens: Die Ausgabe stößt an max_tokens. Das ist eine andere Grenze mit einem anderen Abbruchgrund, und sie steht samt der Falle, die daran hängt, in der Notiz über die Temperatur. Die Kurzform: max_tokens ist eine harte Decke über Nachdenken plus Antworttext, und eine höhere Decke verschiebt das Problem nur an die Fenstergrenze.

Die Schnellreferenz der Doku führt sieben Werte für stop_reason auf: end_turn, max_tokens, stop_sequence, tool_use, pause_turn, refusal und model_context_window_exceeded. Das ist die Liste dieser Seite und nicht die aller Werte, die vorkommen können. Wer das Zusammenfassen weiter unten einschaltet und dabei pause_after_compaction benutzt, bekommt einen achten Wert, den die Schnellreferenz nicht führt: compaction. Eine Fallunterscheidung, die nach der Schnellreferenz gebaut und später um das Zusammenfassen ergänzt wird, schickt diesen Fall in ihren else-Zweig.

Der Rat der Doku ist schlicht: immer nachsehen. Und bei einer abgeschnittenen Antwort einen Hinweis anhängen, damit der Leser merkt, dass die Ausgabe unvollständig ist.

Der Cache verschiebt den Preis, nicht die Zahl

Das ist der Satz, an dem die meisten Kostenschätzungen scheitern, und die Doku schreibt ihn so hin: Zwischengespeicherte Anfrage-Anfänge belegen weiterhin das Kontextfenster. Prompt-Caching ändert, was man für diese Token bezahlt, nicht, ob sie zählen.

Dazu passt eine zweite Stelle, an der man sich leicht selbst betrügt. Im usage-Feld der Antwort ist input_tokens nicht die Eingabe, sondern nur der Teil nach dem letzten Cache-Haltepunkt. Die Doku gibt die Rechnung mit:

total_input_tokens = cache_read_input_tokens
                   + cache_creation_input_tokens
                   + input_tokens

Ihr Beispiel ist deutlich genug, um es sich zu merken: 100.000 Token aus dem Cache gelesen, 0 neu geschrieben, 50 Token in der Nachricht des Benutzers. Dann steht input_tokens: 50 in der Antwort, und verarbeitet wurden 100.050.

Bezahlt wird nach drei Sätzen, und die Doku nennt die Faktoren: Schreiben in den Cache kostet beim 5-Minuten-Fenster das 1,25-fache des Grundpreises für Eingabe-Token, beim 1-Stunden-Fenster das Doppelte, Lesen das 0,1-fache. Claude Fable 5.1 und Claude Mythos 5.1 fallen aus dem letzten Wert heraus, dort ist es das 0,025-fache. Die Preistabelle daneben führt 17 Modelle auf.

Für Claude Opus 5 stehen dort 5 Dollar je Million Eingabe-Token und 0,50 Dollar je Million gelesener Cache-Token. Die 100.000 gelesenen Token aus dem Beispiel kosten damit 5 Cent statt 50. Das ist meine Multiplikation aus zwei belegten Preisen, keine Angabe der Doku, und sie zeigt genau das, was der Satz oben sagt: Der Posten wird kleiner, die Token bleiben im Fenster.

Wo der Cache still versagt

Drei Dinge in dieser Reihenfolge, weil sie in dieser Reihenfolge auffallen.

Zu kurz. Die Doku nennt Mindestlängen je Modell, sechs Zeilen über 18 Modelle, von 512 Token bei Fable 5.1, Mythos 5.1, Opus 5, Fable 5 und Mythos 5 bis 4.096 bei Opus 4.6, Opus 4.5 und Haiku 4.5. Wichtiger als die Zahlen ist, was bei Unterschreitung passiert: Die Anfrage wird ohne Caching verarbeitet, und es kommt kein Fehler zurück. Nachsehen kann man es nur an den Zahlen. Stehen cache_creation_input_tokens und cache_read_input_tokens beide auf 0, wurde nichts zwischengespeichert.

Zu spät. Die Lebensdauer beträgt standardmäßig fünf Minuten. Sie wird ab dem Beginn der Anfrage gemessen, die den Eintrag schreibt oder liest, nicht ab dem Ende der Antwort. Die Doku rechnet das Beispiel vor: Braucht eine Antwort vier Minuten, muss die nächste Anfrage ungefähr eine Minute nach ihrem Ende beginnen. Das klingt strenger, als es in einem laufenden Gespräch ist, denn die Uhr fängt bei jeder Nutzung von vorn an: Der Cache wird jedes Mal ohne zusätzliche Kosten aufgefrischt, wenn der zwischengespeicherte Inhalt benutzt wird. Eng wird es bei Pausen, nicht bei Betrieb. Für Fälle, in denen fünf Minuten trotzdem zu knapp sind, gibt es ein Fenster von einer Stunde gegen Aufpreis.

Ein Sonderfall steht daneben, der beim Auffächern Geld kostet: Ein Cache-Eintrag wird erst verfügbar, nachdem die erste Antwort begonnen hat. Wer Anfragen parallel losschickt, bezahlt in jeder einen Schreibvorgang. Die Doku rät, die erste Antwort abzuwarten, wenn man Treffer braucht.

Zu beweglich. Die Tabelle darüber, was den Cache ungültig macht, hat zehn Zeilen, und hier stehen sieben davon, die man aus Versehen auslöst:

Was sich ändert Wirkung laut Doku
Werkzeug-Definitionen (Namen, Beschreibungen, Parameter) macht den gesamten Cache ungültig
Websuche an- oder abschalten ändert den System-Prompt, System- und Nachrichten-Cache fallen
Zitate an- oder abschalten dasselbe
tool_choice nur die Nachrichtenblöcke
Bilder irgendwo hinzufügen oder entfernen nur die Nachrichtenblöcke
Denk-Einstellung: Modus oder budget_tokens immer die Nachrichtenblöcke, bei Werkzeug- und System-Cache je nach Modell
output_config.effort dasselbe

Die Hierarchie dahinter ist einfach und lohnt sich zu merken: Der Cache folgt der Reihenfolge tools, system, messages, und eine Änderung auf einer Ebene macht diese und alle folgenden ungültig.

Die letzten beiden Zeilen gehören zusammen, und die Seite zum Nachdenken fasst sie in einem Satz, der als Faustregel taugt: Jede Änderung am Nachdenken oder an der Aufwandsstufe oben an der Anfrage ist so zu behandeln, als fange der Cache von vorn an. Der Grund ist derselbe wie bei effort: Die Denk-Einstellung und die aufgelöste Stufe werden in den Prompt selbst geschrieben. Das trifft den Umschalten zwischen adaptive, enabled und disabled genauso wie eine Änderung an budget_tokens. Wer also Platz im Fenster sparen will, indem er das Denkbudget senkt, bezahlt jede solche Änderung mit einem neuen Cache-Anfang. Die Doku sagt dazu auch die Gegenrichtung: Ein Wert, der ausdrücklich auf den Standard des Modells gesetzt wird, ist dasselbe wie ihn wegzulassen und macht nichts ungültig.

Von den drei Zeilen, die hier fehlen, ist eine für lange Gespräche wichtig: Auf früheren Opus- und Sonnet-Modellen und allen Haiku-Modellen werden alle zuvor zwischengespeicherten Denk-Blöcke aus dem Kontext entfernt, sobald Benutzer-Inhalt kommt, der kein Werkzeug-Ergebnis ist, und die Nachrichten dahinter fallen aus dem Cache. Dort entwertet also eine ganz gewöhnliche Nachricht den Cache, ohne dass jemand an einer Einstellung gedreht hätte.

Zwei Wege daran vorbei

Die Doku macht an zwei Stellen eine Ausnahme, und beide hängen an derselben Bauform: Statt das Feld system oben an der Anfrage zu ändern, hängt man eine Nachricht mit der Rolle system hinten an messages an. Der zwischengespeicherte Anfang bleibt dann unverändert.

  • Eine Anweisung nachschieben. Auf sechs Modellen, und das ist die ganze Liste: Claude Fable 5.1, Claude Mythos 5.1, Claude Fable 5, Claude Mythos 5, Claude Opus 4.8 und Claude Opus 5. Die Doku sagt ausdrücklich dazu, dass es auf Claude Sonnet 5 nicht zur Verfügung steht; dort bleibt nur das Feld oben
  • Die Aufwandsstufe ändern. Auf Modellen, die eine Stufe je Nachricht können, lässt eine in einer system-Nachricht getragene Änderung den zwischengespeicherten Anfang ebenfalls unangetastet. Welche Modelle das sind und welche Beta-Kopfzeile dazugehört, steht in der Notiz über die Temperatur

Die zwei Listen sind nicht dieselbe, und man kann sie nicht füreinander nehmen.

Der teuerste Fehler steht als eigener Kasten daneben, und er kostet bei jeder Anfrage: ein Haltepunkt auf einem Block, der sich jedes Mal ändert. Liegt im letzten Block ein Zeitstempel oder die eingehende Nachricht, unterscheidet sich der Hash bei jeder Anfrage. Das Rückblick-Verfahren läuft dann durch die Blöcke davor, findet aber nichts, weil an diesen Stellen nie geschrieben wurde: Geschrieben wird nur am Haltepunkt. Das Ergebnis ist ein bezahlter Cache-Schreibvorgang je Anfrage und nie ein Lesevorgang. Die Doku sagt dazu einen Satz, der die ganze Regel enthält: Das Rückblick-Verfahren sucht keine stabilen Inhalte, es sucht Einträge, die frühere Anfragen geschrieben haben.

Das Rückblick-Fenster umfasst 20 Blöcke. Wächst ein Gespräch so, dass der Haltepunkt 20 oder mehr Blöcke hinter den letzten Schreibvorgang rutscht, findet das Verfahren ihn nicht mehr. Bis zu vier Haltepunkte sind erlaubt, und genau dafür sind sie da.

Wer Werkzeuge parallel aufruft, ist davon weniger betroffen, als die Zahl 20 vermuten lässt. Auf der Claude-Schnittstelle zählt eine Folge aufeinander folgender tool_use-Blöcke als eine Position, und dasselbe gilt für eine Folge von tool_result-Blöcken. Ein Zug mit vielen parallelen Aufrufen schiebt den Eintrag der vorigen Anfrage also nicht von allein aus dem Fenster.

Die Schrauben, die tatsächlich am Fenster drehen

Drei Techniken nennt der Text des Applied-AI-Teams für Aufgaben, deren Token-Zahl das Fenster übersteigt, und das ist die ganze Liste: Compaction, strukturiertes Notieren und Architekturen mit Unteragenten. Sie stehen dort nebeneinander, jede mit eigenem Anwendungsfall, und die Quelle gibt eine Auswahlregel mit:

  • Compaction halte den Gesprächsfluss bei Aufgaben, die viel Hin und Her brauchen
  • Notieren eigne sich für schrittweise Entwicklung mit klaren Meilensteinen
  • Unteragenten seien für komplexe Recherche und Analyse da, wo sich paralleles Erkunden auszahlt

Wie diese drei auf die Einstellungen der Schnittstelle abzubilden sind, ist meine Zuordnung und nicht die der Quelle. Sie selbst rechnet das Räumen von Werkzeug-Ergebnissen der Compaction zu und nennt es eine ihrer sanftesten Formen; für das Notieren gibt es ein eigenes Werkzeug, siehe unten.

Compaction: Zusammenfassen auf dem Server

Server-seitige Compaction fasst ältere Teile des Gesprächs zusammen, sobald eine Schwelle erreicht ist, und ersetzt sie durch einen Compaction-Block. Die Doku nennt sie die empfohlene Vorgehensweise für lange Läufe.

Bevor das irgendetwas nützt, müssen drei Voraussetzungen stimmen, und keine davon steht dort, wo man die Einstellung konfiguriert.

Erstens das Modell. Die Kompatibilitätsangabe der Seite führt elf unterstützte Modelle auf, und das ist die ganze Liste: Fable 5 und 5.1, Mythos 5, 5.1 und Preview, Opus 4.6, 4.7, 4.8 und 5, Sonnet 4.6 und 5. Die Seite zum Kontextfenster sagt dasselbe kürzer, nämlich Beta für Claude 4.6 und spätere Modelle sowie Claude Mythos Preview. Claude Opus 4.5, Claude Sonnet 4.5 und die Haiku-Modelle stehen nicht darauf. Das ist der Unterschied zur Kontext-Bearbeitung weiter unten, die laut ihrer eigenen Seite auf allen unterstützten Claude-Modellen verfügbar ist. Beide sind Beta, aber nur eine von beiden ist überall zu haben.

Zweitens die Beta-Kopfzeile compact-2026-01-12.

Drittens etwas, das nach Server-Arbeit aussieht und Client-Arbeit ist: Der Compaction-Block muss bei den folgenden Anfragen zurückgeschickt werden, sonst läuft das Gespräch nicht mit dem verkürzten Prompt weiter. Der einfachste Weg laut Doku ist, den gesamten Antwortinhalt an die eigene Nachrichtenliste anzuhängen. Trifft die Schnittstelle auf einen Compaction-Block, ignoriert sie alle Blöcke davor.

Vier Parameter hat die Einstellung, und das ist die ganze Liste: type (muss compact_20260112 sein), trigger (Standard 150.000 Eingabe-Token, input_tokens ist der einzige unterstützte Typ, und der Wert muss mindestens 50.000 betragen), pause_after_compaction (Standard false) und instructions.

Beim letzten Parameter steht eine Warnung, die man überlesen kann und die teuer ist: Eigene Anweisungen ergänzen die voreingestellte Aufforderung nicht, sie ersetzen sie vollständig. Wer also eine Zeile ergänzen will und nur diese Zeile hinschreibt, hat die gesamte Anleitung zum Zusammenfassen weggenommen.

Was sie kostet, steht nicht dort, wo man zuerst sucht. Compaction braucht einen zusätzlichen Sampling-Schritt, der gegen Rate Limits zählt und abgerechnet wird. In der Antwort taucht er in usage.iterations auf, und die Doku sagt ausdrücklich: Die Werte input_tokens und output_tokens auf oberster Ebene enthalten den Compaction-Durchgang nicht. Ihr Beispiel zeigt einen Compaction-Durchgang mit 180.000 Eingabe- und 3.500 Ausgabe-Token neben einer Nachricht mit 23.000 und 1.000, und oben stehen die 23.000 und die 1.000. Wer für die Kostenrechnung auf die oberste Ebene schaut, sieht den größeren Posten nicht. Summiert werden muss über usage.iterations.

Und sie kostet ein zweites Mal, wenn man nichts dagegen tut. Die Zusammenfassung ist neuer Inhalt und muss in den Cache geschrieben werden. Ohne zusätzlichen Haltepunkt entwertet das auch einen zwischengespeicherten System-Prompt, der dann zusammen mit der Zusammenfassung neu geschrieben werden muss. Das Gegenmittel ist eine Zeile: einen Haltepunkt ans Ende des System-Prompts setzen. Dann bleibt dessen Cache gültig und wird gelesen, und neu geschrieben wird nur die Zusammenfassung. Bei langen System-Prompts trägt das laut Doku über mehrere Zusammenfassungen eines Gesprächs hinweg.

Zwei Grenzen nennt die Doku dazu. Für die Zusammenfassung wird dasselbe Modell benutzt wie für die Anfrage; ein billigeres lässt sich nicht wählen. Und sind Werkzeuge definiert, ruft das Modell gelegentlich im Zusammenfassungsschritt ein Werkzeug auf, statt zu schreiben; dann kommt ein Compaction-Block mit content: null zurück. Der Vorschlag der Doku dagegen ist, in instructions ausdrücklich zu verlangen, dabei keine Werkzeuge aufzurufen.

Und eine vierte Kopfzeile hängt an einem Weg, den man leicht einschlägt. pause_after_compaction gibt es, damit man nach der Zusammenfassung eigene Blöcke einsetzen kann, etwa die jüngsten Nachrichten im Wortlaut. Genau dort warnt die Doku: Auf Claude Fable 5.1 muss man aus jedem wieder eingesetzten Zug die Blöcke thinking und redacted_thinking entfernen, oder thinking.block_binding.prefix_mismatch_behavior: "drop_block" mit der Beta-Kopfzeile thinking-binding-controls-2026-08-01 mitschicken. Diese Blöcke sind entstanden, als der volle Verlauf noch da war, und bestehen die Prüfung des Gesprächsanfangs nicht mehr. Wo sie greift, wird die Anfrage mit einem 400er abgewiesen. Wie breit das trifft, steht auf der Seite zum Nachdenken, und die Regel hat drei Teile: Für Konten, die am 31.08.2026 um 00:00 UTC oder später angelegt wurden, ist die Prüfung die Voreinstellung. Auf älteren Konten greift sie nur bei Anfragen, die thinking.block_binding.prefix_mismatch_behavior selbst setzen. Und der dritte Teil nimmt dem zweiten die Ruhe wieder weg: Spätere Modelle werden sie für alle Konten erzwingen, weshalb die Doku rät, den eigenen Aufbau schon jetzt so zu bauen, dass er nur hinten anfügt. Wer die Zusammenfassung alles erledigen lässt und keine früheren Züge wieder einsetzt, umgeht die Sache ohnehin.

Kontext-Bearbeitung: gezielt wegräumen

Die andere Einstellung räumt weg statt zusammenzufassen, und sie hat zwei Strategien: clear_tool_uses_20250919 für Werkzeug-Ergebnisse und clear_thinking_20251015 für Denk-Blöcke. Die Beta-Kopfzeile ist hier eine andere, nämlich context-management-2025-06-27.

Beim Wegräumen von Werkzeug-Ergebnissen nennt die Doku fünf Einstellmöglichkeiten, und das ist die ganze Liste: trigger (Standard 100.000 Eingabe-Token), keep (Standard: die letzten 3 Werkzeug-Aufrufe), clear_at_least, exclude_tools und clear_tool_inputs (Standard false, räumt also nur die Ergebnisse weg und lässt die Aufrufe stehen). Geräumt wird vom ältesten an, und an die Stelle des Ergebnisses kommt ein Platzhalter, der dem Modell sagt, dass hier etwas entfernt wurde.

Der Haken hängt am Cache, und clear_at_least ist die Antwort darauf: Das Räumen von Werkzeug-Ergebnissen macht zwischengespeicherte Anfrage-Anfänge ungültig. Die Doku rät deshalb, genug Token zu räumen, damit sich die Entwertung lohnt, und clear_at_least sorgt dafür, dass die Strategie gar nicht erst greift, wenn weniger zusammenkommt.

Der zweite Haken ist der Verlust selbst, und dagegen gibt es ein Gegenstück. Was geräumt ist, ist weg. Die Doku sieht dafür das Gedächtnis-Werkzeug vor, {"type": "memory_20250818", "name": "memory"}, und beschreibt die Kombination als eigenen Fall: Nähert sich der Kontext der eingestellten Räum-Schwelle, bekommt Claude automatisch einen Hinweis, Wichtiges zu sichern, und kann Werkzeug-Ergebnisse in seine Gedächtnisdateien schreiben, bevor sie geräumt werden. Später lässt sich dort nachschlagen, statt alles im Fenster zu halten. Wer räumt, ohne das einzuschalten, wirft weg, was er vielleicht noch braucht.

Beim Räumen von Denk-Blöcken ist es andersherum wichtig: Bleiben sie stehen, bleibt der Cache erhalten. Werden sie geräumt, wird er an der Stelle ungültig, an der geräumt wird. Und wer beide Strategien zusammen benutzt, muss clear_thinking_20251015 zuerst im edits-Feld aufführen.

Die Voreinstellung dafür, ob frühere Denk-Blöcke überhaupt im Fenster bleiben, hängt am Modell. Die Doku unterscheidet zwei Regime: alle früheren Züge behalten bei Claude Opus 4.5 und späteren Opus-Modellen, Claude Sonnet 4.6 und späteren Sonnet-Modellen sowie Fable 5.1, Mythos 5.1, Fable 5, Mythos 5 und Mythos Preview, nur den letzten Zug behalten bei früheren Opus- und Sonnet-Modellen und allen Haiku-Modellen bis Claude Haiku 4.5. Der Rat, der daraus folgt, steht dort im Klartext: Auf den Modellen der ersten Gruppe budgetiert man das Nachdenken wie gewöhnlichen Gesprächsverlauf, weil es genau das ist. Die Doku empfiehlt außerdem, keep ausdrücklich zu setzen, wenn derselbe Code über mehrere Modellklassen läuft, statt sich auf die Voreinstellung zu verlassen.

Eine Erleichterung gehört dazu: Die Kontext-Bearbeitung passiert auf dem Server, bevor die Anfrage beim Modell ankommt. Die eigene Anwendung führt weiter den vollständigen, unveränderten Verlauf und muss nichts abgleichen.

Prüfen, bevor man schickt

Beides lässt sich vorher ausrechnen. Der Endpunkt zum Token-Zählen unterstützt die Kontext-Bearbeitung und gibt zwei Zahlen zurück: input_tokens nach dem Räumen und original_input_tokens davor. Das Beispiel der Doku zeigt 25.000 gegen 70.000. Bei Compaction wendet derselbe Endpunkt vorhandene Compaction-Blöcke an, löst aber keine neuen aus.

Notieren und Unteragenten

Strukturiertes Notieren heißt, dass der Agent Notizen außerhalb des Fensters ablegt und später zurückholt. Das ist dieselbe Sache wie das Gedächtnis-Werkzeug oben, nur von der anderen Seite beschrieben: Der Text des Applied-AI-Teams nennt es eine Ablage über Dateien, mit der sich Wissen über die Zeit aufbauen und der Projektstand über Sitzungen hinweg halten lässt.

Unteragenten sind die dritte Technik und nicht eine Spielart der zweiten. Die Rechnung dahinter ist die einzige Stelle, an der die Quelle Zahlen nennt: Ein Unteragent kann ausgiebig erkunden und dabei zehntausende Token oder mehr verbrauchen, gibt aber nur eine verdichtete Zusammenfassung zurück, nach Angabe der Quelle oft 1.000 bis 2.000 Token. Der ausführliche Teil bleibt damit in einem Fenster, das danach weggeworfen wird.

Was eine Million Token zusagt

Jetzt zur Zahl auf dem Datenblatt. Zwei Anbieter, zwei Schlüsse aus demselben Wert, und beide stehen ausgeschrieben da.

Google liest sie als Einladung. Die begrenzteren Fenster anderer Modelle verlangten Strategien wie das willkürliche Verwerfen alter Nachrichten, das Zusammenfassen von Inhalten, RAG mit Vektordatenbanken oder das Filtern von Anfragen. Diese Techniken blieben in bestimmten Fällen wertvoll, aber das große Fenster lade zu einem direkteren Vorgehen ein: alle einschlägigen Informationen vorne hineinzugeben. Was eine Million Token praktisch bedeutet, macht die Seite an vier Beispielen fest, und das sind alle vier: 50.000 Zeilen Code bei 80 Zeichen je Zeile, alle Textnachrichten der letzten fünf Jahre, acht englische Romane mittlerer Länge, Transkripte von über 200 Podcast-Folgen mittlerer Länge.

Das dazugehörige Beispiel gehört zur Argumentation: Nur mit Lehrmaterial im Kontext, nämlich einer 500-seitigen Referenzgrammatik, einem Wörterbuch und ungefähr 400 Satzpaaren, habe Gemini gelernt, aus dem Englischen nach Kalamang zu übersetzen, eine Papuasprache mit weniger als 200 Sprechern, in einer Qualität ähnlich der eines Menschen mit demselben Material.

Anthropic liest sie als Platz mit Warnschild. Auf derselben Seite, die die 1 Million als Standard ohne Beta-Kopfzeile zusagt, steht der Satz, dass mehr Kontext nicht automatisch besser ist, und direkt daneben das Wort context rot.

Der Widerspruch ist kleiner, als er aussieht, und die Auflösung steht in Googles eigener Frageliste am Seitenende. Auf die Frage, ob man Leistung verliert, wenn man mehr Token in eine Anfrage gibt, lautet die Antwort dort: Wenn Token nicht übergeben werden müssen, vermeide man es besser. Und auf die Frage nach der Latenz: Jede Anfrage habe eine feste Grundlatenz, längere aber generell eine höhere Zeit bis zum ersten Token. Dazu die Empfehlung, die eigene Frage ans Ende der Eingabe zu stellen, hinter den ganzen Kontext, besonders wenn der Kontext lang ist.

Zusammengenommen sagt die Zahl also genau eine Sache zu: Platz. Sie sagt nichts über Genauigkeit, nichts über Preis, nichts über Geschwindigkeit.

Auch beim Zwischenspeichern gehen die zwei Anbieter verschieden vor, und das ist ein Unterschied, der Arbeit kostet oder spart. Bei Gemini ist implizites Caching für alle Modelle ab 2.5 von Haus aus an, die Ersparnis wird bei einem Treffer automatisch weitergegeben, und es gibt nichts einzuschalten. Die Mindestlängen stehen in einer Tabelle mit sieben Modellen, 4.096 Token bei den fünf Gemini-3er-Modellen der Liste und 2.048 bei Gemini 2.5 Flash und Gemini 2.5 Pro. Wie viele Token aus dem Cache kamen, steht im Antwortobjekt unter usage.total_cached_tokens, laut Doku in Python und JavaScript.

Nichts einschalten heißt aber nicht, dass es nichts zu tun gäbe. Zwei Handgriffe nennt dieselbe Seite, um die Trefferwahrscheinlichkeit zu erhöhen, und das sind beide: große und gemeinsame Inhalte an den Anfang der Eingabe stellen, und Anfragen mit ähnlichem Anfang in kurzem Abstand schicken. Der erste ist derselbe Rat, den Anthropic für die eigenen Haltepunkte gibt, nämlich statische Inhalte an den Anfang des Prompts zu legen. An dieser Stelle sind sich die beiden Anbieter einig, auch wenn die Mechanik verschieden ist.

Bei Anthropic setzt man Haltepunkte, entweder von Hand auf einzelnen Blöcken oder über ein Feld an der Anfrage, das den Haltepunkt automatisch auf den letzten cachefähigen Block legt und mit dem Gespräch nach vorn schiebt. Für Gespräche über mehrere Runden, in denen der wachsende Verlauf automatisch zwischengespeichert werden soll, nennt die Doku das die beste Wahl, und in einem wachsenden Gespräch trägt der letzte Block laut derselben Seite, solange jeder Zug weniger als 20 Blöcke hinzufügt.

Zwei Fälle laufen trotzdem daneben, und beide stehen schon weiter oben. Der erste ist die Falle: Wechselt der letzte Block bei jeder Anfrage, weil ein Zeitstempel oder die eingehende Nachricht darin steht, setzt das automatische Verfahren den Haltepunkt dorthin und läuft in dasselbe Muster wie ein falsch gesetzter Haltepunkt von Hand. Für diesen Aufbau rät die Doku zum ausdrücklichen Haltepunkt am Ende des unveränderlichen Teils. Der zweite ist das Rückblick-Fenster: Wächst ein Zug um 20 Blöcke oder mehr, findet der Rückblick den letzten Schreibvorgang nicht, und dagegen hilft nur ein zweiter Haltepunkt näher an dieser Stelle, von Anfang an gesetzt.

Eine Einschränkung nennt Google dazu, und sie ist die Sorte Voraussetzung, an der ein fertiger Aufbau scheitert: Die Interactions API unterstützt nur implizites Caching. Wer ausdrückliche Cache-Objekte anlegen und verwalten will, muss dafür auf die generateContent-Schnittstelle wechseln.

Woran man dreht

Die Reihenfolge, wenn ein langes Gespräch teuer oder schlecht wird, von oben:

  1. Nachsehen, was tatsächlich geschickt wird. input_tokens ist nicht die Eingabe, sondern der Rest hinter dem letzten Haltepunkt. Die Summe aus den drei Feldern ist die Zahl, die zählt, und bei eingeschalteter Compaction die Summe über usage.iterations
  2. stop_reason lesen, bevor man den Text benutzt. Die Schnellreferenz führt sieben Werte, das Zusammenfassen bringt einen achten mit. Eine abgeschnittene Antwort sieht ohne diesen Blick aus wie eine fertige
  3. Den Cache-Haltepunkt auf den letzten Block legen, der gleich bleibt. Nicht auf den, der den Zeitstempel oder die neue Nachricht trägt. Das ist der Unterschied zwischen einem Lesevorgang je Anfrage und einem bezahlten Schreibvorgang je Anfrage. In einem wachsenden Gesprächsverlauf nimmt einem das automatische Setzen die Entscheidung ab; daneben greift es in zwei Fällen, nämlich bei einem letzten Block, der sich jedes Mal ändert, und bei Zügen von 20 Blöcken und mehr
  4. Nichts an der Anfrage bewegen, was den Cache entwertet. Werkzeuge, tool_choice, Bilder, Aufwandsstufe und jede Änderung am Nachdenken, Modus wie budget_tokens. Wer diese Werte oben an der Anfrage variiert, zahlt den Anfang jedes Mal neu. Für zwei Änderungen gibt es einen Weg daran vorbei, siehe oben: eine system-Nachricht mitten im Gespräch, je mit eigener Modellliste
  5. Wegräumen oder zusammenfassen, statt das Fenster zu vergrößern. Beides ist Beta und braucht verschiedene Kopfzeilen; das Zusammenfassen gibt es außerdem nicht auf jedem Modell, das Wegräumen schon. Wer Werkzeuge intensiv benutzt, fängt bei den Werkzeug-Ergebnissen an, weil dort am meisten liegt und weil clear_at_least die Cache-Entwertung an eine Bedingung knüpft. Das Gedächtnis-Werkzeug gehört dazu, sonst ist geräumt auch verloren. Und wer zusammenfassen lässt, setzt einen Haltepunkt ans Ende des System-Prompts, sonst zahlt jede Zusammenfassung ihn gleich mit
  6. Was nicht gebraucht wird, gar nicht erst hineingeben. Das ist die Empfehlung beider Anbieter, in verschiedenen Worten, und sie steht vor allem anderen auf dieser Liste. Die Frage gehört ans Ende

Der Satz, der bleibt: Ein Gespräch hat kein Gedächtnis, sondern eine Rechnung, die jede Runde neu aufgemacht wird. Wer am Prompt dreht, weil die Antwort in Runde dreißig schlechter ist als in Runde drei, dreht an dem einzigen Teil, der sich nicht verändert hat.

Quellen

Alle neun primär, abgerufen am 13.09.2026.

Zum Fenster selbst, zu den Größen je Modell und zum Überlauf die Dokumentation von Anthropic unter Context windows. Die sieben Abbruchgründe, der Beta-Namensraum der SDKs und der Rat zur abgeschnittenen Antwort stehen unter Stop reasons and fallback. Preise, Mindestlängen, Lebensdauer, das Rückblick-Fenster über 20 Blöcke und die Tabelle zur Entwertung stehen unter Prompt caching, die Parameter, die unterstützten Modelle, die Abrechnung des Zusammenfassens und die vierte Beta-Kopfzeile unter Compaction, die zwei Räum-Strategien und das Gedächtnis-Werkzeug unter Context editing. Wie Denk-Blöcke gegen das Fenster zählen, wie sie den Cache entwerten und ab wann die Prüfung des Gesprächsanfangs voreingestellt ist, steht unter Thinking.

Die Begründung für context rot, das Aufmerksamkeitsbudget, die n² paarweisen Beziehungen und die drei Techniken stammen aus Effective context engineering for AI agents vom 29.09.2025, geschrieben vom Applied-AI-Team von Anthropic. Es ist die älteste Quelle hier, und die Modellnamen darin sind überholt.

Zur zweiten Lesart derselben Zahl die Dokumentation von Google: Long context, zuletzt am 22.06.2026 aktualisiert, und Context caching, zuletzt am 02.09.2026 aktualisiert. Die Angaben zu Kalamang, zu den vier Beispielen für eine Million Token und zu den ungefähr 99 Prozent stammen von dort.

← Alle Notizen