Das Kontextfenster ist die Kostenstelle

Ein Agent arbeitet seit dem Vormittag an einer Aufgabe. Er liest, er prüft, er schreibt. Niemand hat etwas an ihm verändert.

Trotzdem wird jeder Schritt am Nachmittag teurer als am Morgen.

Der Grund steht nicht im Ergebnis, sondern in der Anfrage. Jeder neue Schritt schickt alles mit, was vorher war.

Seit dem 14. September 2026 lässt sich bei Claude genau steuern, wann dieser Ballast zusammengefasst wird. Das ist eine technische Neuerung. Für den Betrieb ist es vor allem eine Frage der Zuständigkeit.

Warum lange Agentenläufe teurer werden, ohne dass jemand etwas ändert

Wer über die Programmierschnittstelle von Anthropic, die Messages API, mit Claude arbeitet, schickt den Gesprächsverlauf mit jeder Anfrage mit. Das Modell sieht immer den ganzen bisherigen Verlauf.

Abgerechnet wird nach Token, den kleinen Texteinheiten, in die ein Modell Sprache zerlegt. Was in der Anfrage steht, zählt als Eingabe.

Die Dokumentation beschreibt den Effekt beim Zählen sehr nüchtern: Nach jedem Schritt kommen Ein- und Ausgabe der letzten Antwort hinzu, "because the next request sends the reply too".

Bei einem kurzen Dialog fällt das nicht auf. Bei einem Agenten, der über Stunden Werkzeuge aufruft, Dateien liest und Zwischenergebnisse sammelt, wächst die Anfrage mit jedem Schritt.

Dazu kommt ein zweiter Effekt, der nichts mit Geld zu tun hat. Anthropic schreibt in der Übersicht zur Kompaktierung: "response quality degrades as a conversation grows".

Ein langer Verlauf kostet also doppelt. Er macht jeden Schritt teurer, und er macht die Antworten nicht besser.

Deshalb ist das Kontextfenster, also die Menge an Text, die ein Modell in einer Anfrage verarbeiten kann, in langen Agentenläufen die eigentliche Kostenstelle.

Drei Wege, und wer jeweils entscheidet

Gegen das Wachstum gibt es ein bewährtes Mittel: ältere Teile des Verlaufs durch eine Zusammenfassung ersetzen. Anthropic nennt das Kompaktierung (Compaction).

Die Dokumentation unterscheidet drei Wege. Der wichtigste Unterschied zwischen ihnen ist nicht die Technik, sondern die Frage, wer den Zeitpunkt bestimmt.

	Kompaktierung auf Zuruf	Kompaktierung ab einer Schwelle	Eigene Zusammenfassung
Wer entscheidet, wann	Ihre Anwendung, per Anfrage	die API, sobald die Eingabe die gesetzte Schwelle erreicht	Ihre Anwendung
Läuft im Hintergrund	ja	nein, innerhalb der Anfrage, die die Schwelle erreicht	ja, im eigenen Code
Letzte Schritte bleiben wörtlich	ja	ja, über Pausieren und erneutes Einfügen	ja
Verfügbar seit	14.09.2026, Beta	05.02.2026, Beta	ohne Beta, im eigenen Code

Die Schwellen-Variante gibt es seit Februar. Dabei legen Sie eine Grenze für die Eingabe fest, standardmäßig 150.000 Token, mindestens 50.000. Wird sie erreicht, fasst die API selbst zusammen.

Das ist bequem. Es heißt aber auch: Der Zeitpunkt ergibt sich aus einer Zahl, nicht aus dem Arbeitsstand des Agenten.

Was die Kompaktierung auf Zuruf anders macht

Die neue Variante dreht das um. Ihre Anwendung entscheidet, wann zusammengefasst wird.

Die Ankündigung in den Release Notes vom 14. September 2026 fasst es in einem Satz zusammen: "You choose when to compact, the request can run in the background, and you can keep recent turns word for word after the summary."

Technisch läuft das so: Ihre Anwendung schickt den bisherigen Verlauf mit dem Parameter compaction und dem Beta-Kennzeichen compact-2026-09-04. Zurück kommt keine Antwort, sondern ein Block mit der Zusammenfassung.

Diesen Block stellt die Anwendung an den Anfang des Verlaufs. Die zusammengefassten Nachrichten fliegen raus. Ab dann wird mit dem kurzen Verlauf weitergearbeitet.

Drei Eigenschaften sind für den Betrieb wichtig.

Erstens lässt sich ein Schnittpunkt wählen. Was davor liegt, wird zusammengefasst. Was danach liegt, bleibt wörtlich erhalten. So verliert der Agent nicht ausgerechnet die letzten Schritte, an denen er gerade arbeitet.

Zweitens kann die Zusammenfassung im Hintergrund entstehen. Der Agent arbeitet auf dem vollen Verlauf weiter, und der Block wird eingesetzt, sobald er da ist.

Drittens bleibt bei Modellen mit erhaltenem Denkprozess dieser Denkprozess in den behaltenen Schritten gültig. Das gilt nur unter Bedingungen, die die Dokumentation einzeln aufführt: Unter anderem dürfen sich Systemanweisung und Werkzeugliste nicht ändern.

Die Variante passt laut Dokumentation, wenn Ihre Anwendung den Zeitpunkt selbst steuern muss, nicht pausieren kann, während eine Zusammenfassung entsteht, oder die letzten Schritte samt Denkprozess behalten muss.

Die Zusammenfassung ist lesbar, aber nicht veränderbar

Für die Governance ist ein Detail interessanter als die Kostenfrage.

Der zurückgegebene Block enthält zwei Teile: den Text der Zusammenfassung und eine Signatur. Der Text ist für Menschen lesbar. Die Signatur ist ein signierter Nachweis, den die API bei jeder späteren Anfrage prüft.

Wird der Block nachträglich verändert, lehnt die API ihn ab. Die Dokumentation nennt dafür eigene Fehler, compaction_signature_invalid und compaction_content_mismatch, mit der Anweisung: "Send block exactly as returned."

Meine Lesart: Damit ist die Zusammenfassung so etwas wie das Gedächtnis des Agenten, und dieses Gedächtnis lässt sich lesen, aber nicht still umschreiben.

Was hineinkommt, lässt sich dagegen sehr wohl steuern. Der Parameter erlaubt eigene Anweisungen für die Zusammenfassung, bis zu 16.384 Zeichen. Sie ersetzen die Standardanweisung.

Das ist die eigentliche Entscheidung. Welche Festlegungen, Kennungen und offenen Punkte müssen eine Zusammenfassung überleben? Wer das nicht festlegt, überlässt es der Standardanweisung.

Am 5. September habe ich einem Agenten einen Programmierauftrag in Kurzform mitgegeben. Keine Kompaktierung der API, sondern meine eigene Verkürzung.

Aus einer Bedingung mit zwei Teilen wurde dabei eine mit einem Teil. Die Korrektur, um die es ging, wäre damit wirkungslos gewesen.

Aufgefallen ist es nur, weil im Auftrag ein Satz stand: bei Widerspruch melden statt umdeuten.

Eine Verkürzung verliert nicht das Unwichtige. Sie verliert das, was niemand ausdrücklich als wichtig markiert hat.

Was beim Zusammenfassen verloren geht

Eine Zusammenfassung ist kürzer als das Original. Das ist ihr Zweck. Die Dokumentation sagt aber klar, was dabei nicht mitkommt.

Wörtlich: "Images, documents, container_upload blocks, and fetched URLs inside the summarized messages are gone once the block replaces them."

Bilder, Dokumente, hochgeladene Dateien und abgerufene Webseiten sind nach dem Austausch also weg. Was davon später noch gebraucht wird, muss die Anwendung selbst wieder bereitstellen.

Zwei Fehler beim Austausch melden sich gar nicht. Bleiben zusammengefasste Nachrichten hinter dem Block stehen, schickt die API sie erneut an das Modell. Fehlt der Block in einer späteren Anfrage, bekommt das Modell keine Zusammenfassung.

Beides läuft ohne Fehlermeldung durch. Im ersten Fall zahlen Sie doppelt, im zweiten arbeitet der Agent ohne seine Vorgeschichte weiter.

Im Betrieb fällt das nicht auf. Es fällt auf, wenn jemand fragt, warum ein Agent eine Entscheidung vom Vormittag am Nachmittag nicht mehr kennt.

Auch der Zeitpunkt kann etwas verlieren. Am Ende meiner Arbeitssitzungen mit Agenten entsteht automatisch eine Zusammenfassung mit den Befunden.

Am 30. September startete sie, bevor die Sitzung zu Ende war. Festgehalten wurde eine Architekturentscheidung im Zwischenstand. Die Auflösung stand erst in einem zweiten Lauf.

Ein Filter gegen doppelte Zusammenfassungen hätte genau diese Auflösung verworfen.

Der Zeitpunkt einer Zusammenfassung ist keine Formsache. Er entscheidet, welcher Stand als Gedächtnis weiterlebt.

Die Kosten verschwinden nicht, sie werden sichtbar

Kompaktierung spart nicht automatisch Geld. Die Zusammenfassung selbst ist eine Anfrage.

Die Dokumentation formuliert das ausdrücklich: "The summarization call is billed and rate-limited like any other request."

Wichtig für jedes Kostenreporting ist, wo diese Anfrage auftaucht. Bei einer Kompaktierung auf Zuruf stehen Ein- und Ausgabe in den obersten Feldern der Verbrauchsangabe auf null, weil keine Antwort erzeugt wurde. Der tatsächliche Verbrauch steht in einer eigenen Liste, usage.iterations.

Die Anweisung dazu: "To count what a conversation consumed, sum across usage.iterations, not the top-level fields."

Ein Reporting, das nur die obersten Felder auswertet, zeigt die Kompaktierung also als kostenlos an. Sie ist es nicht.

Bei der Hintergrund-Variante kommt ein zweiter Punkt hinzu. Solange die Zusammenfassung entsteht, sind zwei Anfragen gleichzeitig offen. Das zählt gegen Ihre Anfragelimits.

Wo die Grenzen liegen

Die Funktion ist auf allen Plattformen als Beta gekennzeichnet: in der Claude API, in Claude Platform on AWS, bei Google Cloud und in Microsoft Foundry.

Unterstützt werden laut Dokumentation die aktuellen Modellreihen Opus, Sonnet, Fable und Mythos, bei Opus und Sonnet ab Version 4.6.

Einige Kombinationen sind ausgeschlossen. Die Kompaktierung auf Zuruf lässt sich nicht mit dem Parameter context_management in derselben Anfrage verbinden, über den auch die Schwellen-Variante läuft. Auch Stoppsequenzen, ein festes Ausgabeformat und eine erzwungene Werkzeugwahl sind in der Kompaktierungsanfrage nicht erlaubt.

Und das Beta-Kennzeichen muss nicht nur bei der Kompaktierung selbst mitgeschickt werden, sondern bei jeder späteren Anfrage, die den Block enthält.

Warum das eine Governance-Frage ist

Bisher war die Länge eines Agentenlaufs ein technisches Detail. Mit der Kompaktierung auf Zuruf wird sie zu einer Entscheidung mit drei Teilen.

Wann wird zusammengefasst? Was muss die Zusammenfassung überleben? Und wo wird sichtbar, was sie gekostet hat?

Meine Lesart: Diese drei Fragen gehören in dieselbe Dokumentation wie die Schlüssel und Rollen, mit denen ein Agent arbeitet. Wer festlegt, was ein Agent darf, sollte auch festlegen, was er behalten muss.

Die Zusammenfassung ist dabei ein Vorteil. Sie ist lesbar und gegen stille Änderungen geschützt. Damit lässt sich nachvollziehen, mit welchem Stand ein Agent nach einer Kompaktierung weitergearbeitet hat.

Der Prüfschritt für Montag

Sie brauchen dafür keinen Konsolenzugang. Sie brauchen drei Fragen an die Person, die Ihre Agenten betreibt.

Erstens: Wie lang laufen unsere längsten Agentenläufe, und wie entwickelt sich der Verbrauch über einen solchen Lauf?

Zweitens: Wer hat festgelegt, was bei einer Zusammenfassung erhalten bleiben muss, und wo steht das?

Drittens: Zählt unser Kostenreporting die Zusammenfassungen mit, oder nur die obersten Verbrauchsfelder?

Wenn die zweite Frage mit "das macht das Modell" beantwortet wird, haben Sie das Ergebnis. Nicht als Vorwurf, sondern als offene Festlegung.

Wenn Sie wissen wollen, wo in Ihren Agentenläufen das Kontextfenster zur Kostenstelle wird: schreiben Sie mir. Ich schaue mir die Stelle mit Ihnen an.

Gap-Check per Microsoft Bookings:
https://outlook.office.com/bookwithme/user/99ec6e3094644876b366a1442ad2b8a6@steffen-sander.de/meetingtype/iEHmiDvlq0elhEXDjPnagQ2?anonymous

Fazit

Die Kompaktierung auf Zuruf löst kein neues Problem. Lange Verläufe waren schon immer teuer. Neu ist, dass der Zeitpunkt der Zusammenfassung bei Ihnen liegt und nicht bei einer Schwelle.

Damit liegt auch die Verantwortung bei Ihnen.

Frage	Was die Dokumentation sagt	Was Sie festlegen sollten
Wann wird zusammengefasst?	Ihre Anwendung entscheidet, auch im Hintergrund	einen Zeitpunkt, der zum Arbeitsstand passt
Was bleibt erhalten?	Standardanweisung oder eigene, bis 16.384 Zeichen	welche Festlegungen und Kennungen überleben müssen
Was geht verloren?	Bilder, Dokumente, Uploads, abgerufene Webseiten	was die Anwendung danach wieder bereitstellt
Was kostet es?	wird abgerechnet wie jede Anfrage, steht in `usage.iterations`	ein Reporting, das diese Liste mitzählt
Ist sie manipulierbar?	nein, veränderte Blöcke werden abgelehnt	die Zusammenfassung als nachvollziehbaren Stand ablegen