Claude Message Threads in der Messages API: Ein Thread spart den Upload, nur der Cache spart das Prefill

Am 2. November hat Anthropic Message Threads als Beta in die Messages API gebracht, aktivierbar über den Header message-threads-2026-08-12. Der erste Request schickt die ganze Konversation mit "thread": {"type": "create"}. Jeder spätere Request schickt nur die neuen Nachrichten plus die id der vorherigen Antwort; den Rest baut die API auf ihrer Seite wieder zusammen. Das läuft laut Release Notes auf der Claude API, Claude Platform on AWS, Claude in Microsoft Foundry und Claude Models on Google Cloud (von Anthropic betrieben).

Versprochen wird Tempo für lange Agent-Schleifen. Liest man die Doku aber zusammen mit der Seite zum Prompt Caching, zeigt sich: Ein Thread beseitigt einen Kostenblock und überlässt den anderen dem Cache. Prefill ist der größere der beiden, und den rührt ein Thread nicht an.

Was machen Claude Message Threads tatsächlich schneller?

Den Transport, nicht das Lesen. Ohne Thread, so die Doku, wird bei jedem Turn die ganze Konversation neu hochgeladen, und die API validiert und tokenisiert alles noch einmal. Mit Thread betrifft der Großteil dieser Arbeit nur den neuen Turn. Das Modell liest trotzdem alles: Laut Anthropics Ankündigung bleibt der Tokenverbrauch gleich, Preise und Rate Limits ändern sich nicht.

Der Gewinn wächst also mit dem, was du erneut schickst. Ein Coding-Agent mit 800K Tokens Kontext, der ein Tool-Ergebnis von 2K anhängt, hat bisher die vollen 800K verschickt, um 2K Neues zu sagen. Die Ankündigung nennt genau eine gemessene Zahl:

With message threads on by default for most Claude Code users, requests with
500k to 1M tokens see median TTFT drop by about 35%.

Das ist ein Median, gemessen an Claude-Code-Traffic, im obersten Bereich der Kontextgröße. Meine Erklärung, warum er gerade dort auftaucht: Claude Code cacht sein Prompt-Präfix. Ist das Prefill schon billig, macht das Übertragen der Konversation einen großen Teil der verbleibenden Wartezeit aus. Für eine Konversation mit 50K hat niemand eine Zahl veröffentlicht. Da gibt es viel weniger neu zu schicken, also auch weniger zu sparen, aber wie viel weniger, hat niemand gemessen. Das CHANGELOG von Claude Code erwähnt Threads bis Version 2.1.317 überhaupt nicht. „Standardmäßig an“ stammt also aus Anthropics Ankündigung und ist keine Release Note, die du an einer Version festmachen kannst.

Cacht ein Claude Message Thread den Prompt?

Nein, und die Doku sagt das in einem Satz: Ein Thread cacht deinen Prompt nicht für dich. Prefill, also die Verarbeitung der Konversation durch das Modell vor dem ersten Token, ist das, was du mit dem Prompt-Cache überspringst, und die Breakpoints setzt weiterhin du. Der einfache Weg ist ein cache_control auf oberster Ebene bei jedem Request.

Genau dieses Feld gehört zu den festen Feldern eines Threads. model, thinking, tool_choice, output_config, die Menge der Beta-Header und das cache_control auf oberster Ebene müssen bei jedem Turn zum Create-Request passen, sonst liefert die API thread_fingerprint_mismatch. system und tools gehören nur in den Create-Request. Wer davon etwas ändert, braucht einen neuen Thread.

Das Limit liegt wie gewohnt bei 4 Breakpoints, nur mit weniger Spielraum. Breakpoints auf system und tools im Create-Request zählen bei jedem Continue wieder mit, und ein einmal gesendeter Breakpoint lässt sich weder verschieben noch entfernen. Wenn du die Konversation von Hand erneut sendest (Replay), entferne zuerst die alten Breakpoints in den Nachrichten; der SDK-Helper erledigt das für dich.

Damit gibt es zwei unabhängige Uhren. Der Thread läuft 5 Minuten nach seinem letzten Request ab. Der Cache lebt standardmäßig 5 Minuten oder eine Stunde mit ttl: "1h" zu einem höheren Schreibpreis (in Claude Code bekommen nur manche Sessions die Stunde). Mit der Ein-Stunden-TTL beendet eine Pause von 20 Minuten den Thread, der Cache kann aber warm bleiben. Das Replay lädt dann alles neu hoch und liest das Präfix trotzdem günstig, solange Präfix und Einstellungen übereinstimmen. Ein verlorener Thread meldet sich selbst: Das nächste Continue liefert 404. Ein verlorener Cache bleibt stumm, und mit einer Cache-Diagnose unterscheidest du einen abgelaufenen Eintrag von einem geänderten Prompt.

Was unterstützen Claude Message Threads nicht?

Die meisten Werkzeuge, mit denen du eine lange Konversation verwaltest:

append-only        each response id can be continued once; no edits, no branches
5-minute expiry    then a continue returns 404 thread_not_found
no compaction      compaction on demand returns 400; summarize in your code, start a new thread
no context editing except clear_thinking_20251015 with keep: "all"
no token counting  count the full conversation with system and tools instead
no batches         a batch item with thread fails with invalid_request_error
not ZDR eligible   held in memory, deleted no more than 1 hour after last use

Organisationen mit HIPAA Readiness oder Inference Hooks können Threads gar nicht nutzen. Außerdem sagt dir keine Antwort, ob die API den Turn gespeichert hat; das merkst du erst beim nächsten Continue. Deine App muss also jede Nachricht selbst vorhalten. Jeder Thread endet in einem Replay, sobald er fünf Minuten inaktiv ist. Bau den Replay-Pfad vom ersten Tag an und teste ihn wie den Hauptpfad.

Schaltet das Anthropic-SDK Claude Message Threads standardmäßig ein?

Im Tool Runner ja. Ich habe das Python-Wheel anthropic 2.4.0 gelesen. Ein Tool Runner schickt seine Requests über einen Thread, solange du nicht thread=False übergibst, und er setzt unsupported_request_behavior="continue_unthreaded": Nach einem thread_unsupported_request-Fehler oder einem zweiten thread_not_found direkt nach einem Replay lässt er den Thread fallen und schickt vollständige Requests. Andere Fehler landen weiterhin in deinem Code. Das Client-Attribut, das Threading erlaubt, _supports_message_threads, ist bei Anthropic und AsyncAnthropic true, und die AWS- und Foundry-Clients erben das. Bei den Bedrock- und Vertex-Clients ist es false, dort wirft client.beta.messages.thread() einen Fehler. Wenn du einen Agenten mit Tool Runner mit Daten arbeiten lässt, die du aus Funktionen ohne ZDR heraushalten wolltest, setz thread=False im selben Commit, mit dem du das SDK aktualisierst.

Solltest du jetzt auf Claude Message Threads bauen?

Schalte sie dort ein, wo Latenz wehtut und der Kontext riesig ist: große Coding-Schleifen, Computer Use mit Screenshots, die sonst bei jedem Turn neu hochgeladen werden. Agents, die auf einen Menschen, ein Review oder einen Timer warten, bleiben oft länger als fünf Minuten stehen. Für sie ist das Replay der Normalfall, und der Thread lohnt sich nur innerhalb von Arbeitsschüben.

Mein Rat für Tag eins: Bevor du thread einbaust, logge pro Request drei Zahlen, nämlich Kontextgröße, Zeit bis zum ersten Token und cache_read_input_tokens. Die Ankündigung hat eine Kohorte gemessen, und dein Traffic gehört vielleicht nicht dazu. Sind die Cache Reads niedrig, verlierst du die Prefill-Zeit durch Cache-Misses, und die holt dir ein Thread nicht zurück.