Antworten strömen: wann und wie

TL;DR

Ab etwa 16.000 Ausgabe-Token laufen nicht-gestromte Anfragen in HTTP-Zeitüberschreitungen — das SDK weist solche Anfragen teilweise aktiv ab. Der Umbau kostet drei Zeilen, und Sie brauchen die einzelnen Ereignisse nicht zu behandeln, wenn Sie sie nicht wollen.

Der Umbau

# Vorher
antwort = client.messages.create(
    model="claude-opus-5", max_tokens=64000, messages=[...],
)

# Nachher
with client.messages.stream(
    model="claude-opus-5", max_tokens=64000, messages=[...],
) as stream:
    antwort = stream.get_final_message()

get_final_message() liefert dieselbe Nachricht wie zuvor. Der einzige Unterschied ist, dass die Verbindung während der Erzeugung nicht leerläuft.

Wenn Sie den Text unterwegs anzeigen wollen:

with client.messages.stream(
    model="claude-opus-5", max_tokens=64000, messages=[...],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

    antwort = stream.get_final_message()

flush=True ist nötig, sonst puffert die Ausgabe und der Effekt ist weg.

Wann Sie strömen müssen

Ab etwa 16.000 Ausgabe-Token. Darunter ist es Geschmackssache, darüber wird es zur Notwendigkeit — die Verbindung läuft sonst leer und wird abgebaut.

Und beachten Sie: Die aktuellen Modelle erlauben bis zu 128.000 Ausgabe-Token (Claude Haiku 4.5: 64.000). Diese Größenordnung ist ohne Strömen praktisch nicht erreichbar.

Der Punkt, der beim Modellwechsel überrascht: max_tokens begrenzt Denken und Antworttext gemeinsam. Bei Claude Opus 5 und Sonnet 5 ist der Denkmodus standardmäßig aktiv — eine Anfrage, die bisher ohne Strömen auskam, kann jetzt deutlich länger laufen, ohne dass sich am sichtbaren Ergebnis etwas ändert.

Bei den hohen Aufwandsstufen xhigh und max gilt das verstärkt: Dort sollte max_tokens großzügig bemessen sein, und dann ist Strömen ohnehin gesetzt.

Denkinhalte anzeigen

Bei aktivem Denkmodus kommen zwei Arten von Inhalt. Wer beide unterscheiden will, geht über die Ereignisse:

with client.messages.stream(
    model="claude-opus-5",
    max_tokens=64000,
    thinking={"type": "adaptive", "display": "summarized"},
    messages=[...],
) as stream:
    for ereignis in stream:
        if ereignis.type == "content_block_start":
            if ereignis.content_block.type == "thinking":
                print("\n[Denkt nach…]")
            elif ereignis.content_block.type == "text":
                print("\n[Antwort:]")

        elif ereignis.type == "content_block_delta":
            if ereignis.delta.type == "thinking_delta":
                print(ereignis.delta.thinking, end="", flush=True)
            elif ereignis.delta.type == "text_delta":
                print(ereignis.delta.text, end="", flush=True)

display: "summarized" ist hier entscheidend. Voreingestellt ist "omitted" — die Denkblöcke kommen dann zwar, ihr Textfeld ist aber leer. In einer strömenden Oberfläche äußert sich das als lange Pause vor der ersten sichtbaren Ausgabe, und Nutzer halten das für einen Ausfall.

Wenn Sie Denkfortschritt anzeigen wollen, müssen Sie die Einstellung ausdrücklich setzen.

Die Ereignistypen

Der Verbrauch steht in message_delta, nicht in message_start — wer die Token-Zahl während des Strömens mitschreiben will, muss dort hinschauen.

Strömen mit Werkzeugen

Der Tool Runner unterstützt Strömen: Übergeben Sie stream=True, und jede Runde liefert einen Strom, den Sie ereignisweise verarbeiten, mit get_final_message() je Runde.

Ohne Runner in der eigenen Schleife:

with client.messages.stream(
    model="claude-opus-5", max_tokens=64000,
    tools=werkzeuge, messages=messages,
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

    antwort = stream.get_final_message()

if antwort.stop_reason == "tool_use":
    ...   # Werkzeuge ausführen, Ergebnisse zurückgeben, weiter

Zwei Dinge, die beim Strömen anders sind

Ablehnungen können mitten im Strom auftreten. Dann ist bereits Ausgegebenes gesendet — und wird regulär berechnet. Behandeln Sie die Teilausgabe als unbrauchbar, statt sie für eine vollständige Antwort zu halten. Die Einordnung steht im Beitrag zu Ablehnungen.

Ausgabeprüfungen greifen nur eingeschränkt. Wenn Sie eine Guardrail-Kette hinter dem Modell haben, ist ein Teil der Antwort beim Nutzer, bevor die vollständige Prüfung möglich ist. Praktikabel ist entweder, für geprüfte Wege nicht zu strömen, oder abschnittsweise zu prüfen und bei einem Treffer abzubrechen — beides verschlechtert die wahrgenommene Geschwindigkeit. Die Systematik steht im Beitrag zur Guardrail-Kette.

Fehler beim Strömen

try:
    with client.messages.stream(...) as stream:
        for text in stream.text_stream:
            print(text, end="", flush=True)
except anthropic.APIConnectionError:
    print("\nVerbindung verloren.")
except anthropic.RateLimitError:
    print("\nKontingent erschöpft.")

Ein abgebrochener Strom hinterlässt eine unvollständige Antwort. Wenn Sie das Ergebnis weiterverarbeiten, prüfen Sie, ob get_final_message() überhaupt erreicht wurde — sonst schreiben Sie einen halben Datensatz fort.

Häufig gestellte Fragen

Ab wann muss ich Antworten strömen?

Ab etwa 16.000 Ausgabe-Token. Darunter ist es optional, darüber laufen nicht-gestromte Anfragen in HTTP-Zeitüberschreitungen, weil die Verbindung während der Erzeugung leerläuft. Das SDK weist Anfragen, die es als zu lang einschätzt, teilweise aktiv ab.

Muss ich beim Strömen einzelne Ereignisse behandeln?

Nein. Mit stream.get_final_message() bekommen Sie dieselbe vollständige Nachricht wie bei einem regulären Aufruf — der Umbau kostet drei Zeilen. Die Ereignisse brauchen Sie nur, wenn Sie Text unterwegs anzeigen oder Denkinhalte von der Antwort trennen wollen.

Warum sehe ich beim Strömen erst eine lange Pause?

Weil der Denkmodus läuft und die Denkinhalte standardmäßig leer sind. thinking.display ist auf "omitted" voreingestellt — die Blöcke kommen, ihr Textfeld ist leer. Setzen Sie display: "summarized", wenn Sie Denkfortschritt anzeigen wollen.

Wo finde ich den Token-Verbrauch beim Strömen?

Im Ereignis message_delta, nicht in message_start. Alternativ liefert get_final_message() am Ende die vollständige Nachricht samt Verbrauchsangaben — das ist der einfachere Weg, wenn Sie den Wert nicht während der Erzeugung brauchen.

Funktionieren Ausgabeprüfungen beim Strömen?

Nur eingeschränkt. Wenn Sie Token für Token ausliefern, ist ein Teil der Antwort beim Nutzer, bevor die vollständige Prüfung möglich ist. Praktikabel ist, für geprüfte Wege nicht zu strömen oder abschnittsweise zu prüfen und bei einem Treffer abzubrechen — beides auf Kosten der wahrgenommenen Geschwindigkeit.

Der nächste Schritt

Prüfen Sie Ihre Aufrufe auf max_tokens über 16.000 ohne Strömen. Und rechnen Sie beim Modellwechsel damit, dass der jetzt standardmäßig aktive Denkmodus Anfragen verlängert, die vorher unauffällig durchliefen. Wir schauen gern mit drauf.