Komprimierung im Hintergrund

Die „background compaction“ (Hintergrund-Komprimierung), oft auch „async compaction“ (asynchrone Komprimierung) genannt, ändert zwei Dinge in der Komprimierungsschleife: Die Komprimierungsanfrage läuft, während die Konversation auf ihrem vollständigen Verlauf weitergeht, und der Austausch wartet, bis der Block eintrifft. Ab der Zusammenfassung fortfahren und Fehlende Zusammenfassung oder Fehler behandeln gelten unverändert.

Wie der Austausch funktioniert, während die Arbeit weitergeht

Die Komprimierungsanfrage und der Block, den sie zurückgibt, sind dieselben wie in der Schleife. Dein Verlauf wächst zwischen dem Senden der Anfrage und der Verwendung ihres Ergebnisses, und der Austausch muss diesen Zuwachs unverändert lassen.

1. Sende die Komprimierungsanfrage mit deinem Verlauf in seinem aktuellen Zustand und notiere, wie viele Nachrichten er enthielt.
2. Während diese Anfrage läuft, führe die Konversation auf dem vollständigen Verlauf weiter. Hänge jeden neuen Turn an, bearbeite nichts, was bereits im Verlauf steht, und starte keine weitere Komprimierungsanfrage, bis diese eingetauscht wurde oder fehlgeschlagen ist.
3. Wenn die Antwort mit stop_reason "compaction" eintrifft, entferne genau die Nachrichten, die du gesendet hast, vom Anfang deines Verlaufs und setze die zurückgegebene Nachricht an ihre Stelle. Jeder seit Schritt 1 angehängte Turn bleibt dahinter erhalten.
4. Sende den ausgetauschten Verlauf mit der ersten Anfrage nach dem Eintreffen des Blocks, damit das Thinking, das während des Schreibens der Zusammenfassung entstanden ist, gültig bleibt.

Wenn die Komprimierungsanfrage zum Beispiel die Nachrichten 1 bis 5 enthielt und die Konversation während ihrer Laufzeit die Nachrichten 6 bis 8 hinzugewonnen hat, besteht dein Verlauf nach dem Austausch aus dem Block, gefolgt von den Nachrichten 6 bis 8.

Wenn die Antwort einen anderen stop_reason hat, wurde keine Zusammenfassung erstellt, was in Schritt 2 als Fehlschlag gilt. Behalte den vollständigen Verlauf; Fehlende Zusammenfassung oder Fehler behandeln listet die Ursachen auf und was jeweils zu tun ist.

Die Zusammenfassung im Hintergrund anfordern

Die Komprimierungsanfrage wird wie jede andere Anfrage auf deine „rate limits“ (Ratenlimits) angerechnet, und während sie läuft, hat deine Anwendung zwei Anfragen gleichzeitig offen. Die Konversation wächst bis zum Austausch auf ihrem vollständigen Verlauf weiter, also starte die Komprimierungsanfrage, solange das „context window“ (Kontextfenster) noch Platz für die Turns hat, die in der Zwischenzeit eintreffen.

Das folgende Programm ist die Schleife aus In einer Schleife komprimieren, wobei die Komprimierungsanfrage aus dem Pfad der Konversation herausgenommen wurde. Es gibt keine PHP-Version, da das Beispiel darauf angewiesen ist, zwei Anfragen gleichzeitig auszuführen. Die hervorgehobenen Zeilen zeigen, wo es sich von der Schleife unterscheidet, und die folgende Liste behandelt sie in der Reihenfolge, in der das Programm sie ausführt.

from concurrent.futures import Future, ThreadPoolExecutor

import anthropic
from anthropic.types.beta import BetaMessage, BetaMessageParam

client = anthropic.Anthropic()
executor = ThreadPoolExecutor(max_workers=1)

# Setze dies nahe an dein echtes Input-Budget. Hier ist es niedrig, damit ein kurzes Gespräch kompaktiert wird.
COMPACT_AT_TOKENS = 2500
SYSTEM = "You help design a recipe app's data model. Keep answers short."

QUESTIONS = [
    "What are the main entities in the data model?",
    "Which fields should Recipe have?",
    "Which fields should Ingredient have?",
    "Which fields should RecipeIngredient have?",
    "Which fields should Step have?",
    "Which indexes should these tables have?",
    "Which fields should be required?",
    "Which fields should have default values?",
]


def swap_in(history: list[BetaMessageParam], summary: BetaMessage, sent: int) -> None:
    if summary.stop_reason == "compaction":
        # Ersetze genau die Nachrichten, die die Kompaktierungsanfrage enthielt.
        # Spätere Turns bleiben nach dem Block erhalten.
        history[:sent] = [{"role": "assistant", "content": summary.content}]
        print(f"Swapped {sent} messages")


history: list[BetaMessageParam] = []
pending: Future[BetaMessage] | None = None
sent = 0
for turn, question in enumerate(QUESTIONS, start=1):
    if pending is not None and pending.done():
        swap_in(history, pending.result(), sent)
        pending = None

    history.append({"role": "user", "content": question})
    response = client.beta.messages.create(
        model="claude-opus-5-5",
        max_tokens=8192,
        system=SYSTEM,
        betas=["compact-2026-09-04"],
        messages=history,
    )
    history.append({"role": "assistant", "content": response.content})

    # Die nächste Anfrage sendet diese Antwort mit, also zähle sie mit.
    conversation_tokens = response.usage.input_tokens + response.usage.output_tokens
    if (
        conversation_tokens > COMPACT_AT_TOKENS
        and turn < len(QUESTIONS)
        and pending is None
    ):
        sent = len(history)
        pending = executor.submit(
            client.beta.messages.create,
            model="claude-opus-5-5",
            max_tokens=4096,
            system=SYSTEM,
            betas=["compact-2026-09-04"],
            messages=history.copy(),
            compaction={"type": "summarize"},
        )

# Setze eine noch ausstehende Zusammenfassung ein, bevor du speicherst
# oder das Gespräch fortsetzt.
if pending is not None:
    swap_in(history, pending.result(), sent)
executor.shutdown()

• Entscheiden, wann komprimiert wird: Die Größenprüfung setzt zusätzlich voraus, dass keine Komprimierungsanfrage aussteht.
• Die Anfrage starten: Wo die Schleife auf die Komprimierungsantwort wartet, notiert diese Version, wie viele Nachrichten der Verlauf enthält, startet die Anfrage auf einer Kopie des Verlaufs mit dem jeweiligen Nebenläufigkeitswerkzeug der Sprache und fährt ohne Warten mit dem nächsten Turn fort.
• Auf das Ergebnis prüfen: Zu Beginn jedes Turns prüft das Programm, ob die ausstehende Anfrage abgeschlossen ist. Falls ja, führt das Programm den Austausch durch, bevor es die Anfrage dieses Turns sendet.
• Den Austausch durchführen: Wo die Schleife den gesamten Verlauf durch die zurückgegebene Nachricht ersetzt, ersetzt die Austauschfunktion dieser Version nur die Nachrichten, die die Anfrage enthielt, vom Anfang an gezählt, und behält alles bei, was seitdem angehängt wurde.
• Die Schleife beenden: Wenn die Komprimierungsanfrage beim Ende der Schleife noch aussteht, wartet das Programm auf sie und führt den Austausch durch, damit eine Zusammenfassung, die noch unterwegs ist, nicht verloren geht, bevor du die Konversation speicherst oder fortsetzt.

Die Prüfung von stop_reason ist gegenüber der Schleife unverändert: Eine Antwort ohne Block lässt den Verlauf so, wie er war. Da dann nichts mehr aussteht, kann das Programm anschließend eine neue Komprimierungsanfrage starten.

Thinking gültig halten, während die Zusammenfassung erstellt wird

Turns, die eintreffen, während die Zusammenfassung geschrieben wird, sind beibehaltene Turns. Wenn du Thinking-Blöcke bei einem Modell mit „preserved thinking“ (beibehaltenem Denken) zurücksendest, bleibt das Thinking in diesen Turns nur gültig, solange die Bedingungen für beibehaltenes Thinking erfüllt sind.

Compatibility