Message Threads in der Claude API: nur noch neue Nachrichten senden

Anthropic hat Message Threads in der Claude API als Beta freigegeben: Die Unterhaltung bleibt kurz auf dem Server, und jede weitere Anfrage schickt nur noch die neuen Nachrichten. Die Neuerung steht seit dem 2. November in den Claude Release Notes und läuft mit dem Beta-Header message-threads-2026-08-12.

Wie funktionieren Message Threads in der Claude API?

Bisher bedeutete jede Runde einer Unterhaltung mit der Messages API, den kompletten Verlauf neu zu senden: Systemprompt, Tools und alle Nachrichten. Laut der Dokumentation zu Message Threads musste die API das Ganze jedes Mal erneut validieren und tokenisieren. Mit einem Thread betrifft der Großteil dieser Arbeit nur noch die neue Runde.

Der gesamte Mechanismus ist ein neuer Parameter, thread:

1. Die erste Anfrage schicken wir wie gewohnt, mit der vollständigen Unterhaltung, system und tools, plus "thread": {"type": "create"}. Die API speichert die Unterhaltung samt Claudes Antwort unter der id dieser Antwort.
2. Folgeanfragen enthalten "thread": {"type": "continue", "previous_message_id": "<id>"} und nur die neuen Nachrichten, etwa die nächste Nutzernachricht oder Tool-Ergebnisse (tool_result).
3. system und tools lassen wir weg, weil der Thread sie kennt. Wer sie in einer continue-Anfrage mitschickt, bekommt einen 400-Fehler.

Laut Anthropic sind die Anfragen dadurch kleiner und die Zeit bis zum ersten Token kürzer und stabiler, auch wenn die Unterhaltung wächst. Am meisten profitieren lange Agent-Schleifen, in denen der Agent Dutzende Tool-Aufrufe macht und jedes Mal den wachsenden Verlauf übertragen musste (mehr dazu, wie solche Schleifen funktionieren, im Artikel Was ist ein KI-Agent).

Was übernimmt das SDK für uns?

Das SDK hat einen Helfer bekommen: client.beta.messages.thread(...). Wir erstellen ihn mit denselben Feldern wie eine normale Anfrage und schicken weitere Runden mit thread.send(...). Der Helfer setzt den Beta-Header selbst, legt den Thread in der ersten Runde an und setzt ihn in den folgenden fort.

Interessant: Der Beta-Tool-Runner im SDK nutzt Threads standardmäßig, Agenten auf dieser Basis können also ohne Codeänderung schneller werden (beim Erstellen des Runners lässt sich das abschalten).

Der Helfer kümmert sich auch um Fehlerfälle: Läuft ein Thread ab, schickt er die ganze Unterhaltung in einer neuen create-Anfrage noch einmal. Die vollständige Kopie hält er allerdings nur im Speicher, solange das Helfer-Objekt existiert.

Worauf sollte man achten?

Erstens auf die kurze Lebensdauer. Ein Thread läuft 5 Minuten nach der letzten Anfrage ab, und die API löscht ihn spätestens eine Stunde nach der letzten Nutzung. Die Dokumentation nennt Threads „best-effort“: Unsere Anwendung bleibt die Quelle der Wahrheit für die Unterhaltung und muss von Anfang an das erneute Senden nach einem 404-Fehler thread_not_found beherrschen.

Zweitens darauf, was sich nicht ändern darf. Felder wie model, thinking, tool_choice oder context_management müssen im ganzen Thread gleich bleiben, sonst antwortet die API mit dem Fehler thread_fingerprint_mismatch. Ein Thread lässt sich nur verlängern, und jede Antwort-id kann genau einmal fortgesetzt werden. Um eine frühere Nachricht zu bearbeiten oder den Systemprompt zu ändern, starten wir einen neuen Thread.

Drittens auf Prompt Caching. Ein Thread cacht selbst nichts. Der Cache funktioniert wie bisher, und eine Anfrage mit thread fasst höchstens 4 cache_control-Punkte. Am einfachsten ist es, in jeder Runde dasselbe cache_control auf oberster Ebene der Anfrage zu senden.

Viertens auf Funktionen, mit denen Threads nicht zusammenarbeiten:

1. Message Batches und Token Counting.
2. Compaction, auch Kompaktierung auf Anforderung, sowie Context Editing (mit einer in der Dokumentation beschriebenen Ausnahme).
3. Organisationen mit aktivierter HIPAA readiness oder Inference hooks.

Fünftens auf die Daten. Threads sind nicht ZDR-fähig (Zero Data Retention). Laut Dokumentation werden Unterhaltung, Systemprompt und Tools im Arbeitsspeicher gehalten, mit einem serververwalteten Schlüssel verschlüsselt und nie dauerhaft auf Platte geschrieben.

Wo und mit welchen Modellen funktioniert das?

Message Threads sind als Beta verfügbar in der Claude API, auf Claude Platform on AWS, Claude Models on Google Cloud (von Anthropic verwaltet) und in Microsoft Foundry. Unterstützt werden unter anderem Claude Fable 5.1 und Mythos 5.1, Opus 5.5, Sonnet 5.5 und Haiku 5.5, von den älteren auch Opus 4.5, Sonnet 4.5 und Haiku 4.5.

Threads ändern weder Preise noch Rate Limits. Wir zahlen für Tokens wie bisher, die Ersparnis betrifft also Zeit und Anfragegröße. Die Kosten sollte man weiter im Blick behalten, etwa mit der neuen API zur Kostenanalyse für Claude. Es ist eine weitere Änderung an der API selbst in den letzten Tagen, nach der Anhebung der Anfragegröße auf 128 MB.

(Nicht zu verwechseln mit „session threads“ in Claude Managed Agents. Das ist eine eigene Funktion, wie die Dokumentation betont.)

FAQ

Was sind Message Threads in der Claude API?

Eine Beta-Funktion, bei der die API die Unterhaltung kurzzeitig auf dem Server speichert. Nach der ersten Anfrage senden wir nur neue Nachrichten und die id der vorherigen Antwort.

Senken Message Threads die Kosten der Claude API?

Nicht direkt. Laut Dokumentation ändern Threads weder Preise noch Rate Limits. Der Gewinn sind kleinere Anfragen und eine kürzere Zeit bis zum ersten Token.

Wie lange speichert die Claude API einen Thread?

Ein Thread läuft 5 Minuten nach der letzten Anfrage ab, und die API löscht ihn spätestens eine Stunde nach der letzten Nutzung. Danach muss die ganze Unterhaltung erneut gesendet werden.

Funktionieren Message Threads auf Amazon Bedrock?

Die Dokumentation nennt die Claude API, Claude Platform on AWS, Claude Models on Google Cloud (von Anthropic verwaltet) und Microsoft Foundry. Amazon Bedrock steht nicht auf der Liste.