Claude API: Message Threads halten den Verlauf
Mit Message Threads schicken Agenten nur noch neue Nachrichten an die Claude API. Was das bringt, was es nicht spart und warum es nicht unter ZDR fällt.
Ein Agent, der eine Stunde an einer Codebasis arbeitet, schickt der API bei jedem Schritt den kompletten bisherigen Verlauf: jede Datei, die er gelesen hat, jedes Tool-Ergebnis, jeden Screenshot. Die API nimmt das jedes Mal neu entgegen, prüft und tokenisiert es. Mit den Message Threads, seit dem 02.11.2026 als Beta in der Claude API, soll das entfallen. Der Server hält den Verlauf zwischen zwei Anfragen, der Client schickt nur noch das, was neu dazugekommen ist.
So funktioniert es
Die erste Anfrage sieht aus wie bisher, mit vollem Verlauf, system und tools, dazu "thread": {"type": "create"} und der Beta-Header message-threads-2026-08-12. Unter der ID der Antwort legt die API die Konversation samt Claudes Antwort ab. Jede weitere Anfrage enthält nur die neuen Nachrichten und verweist auf die vorige Antwort:
{
"model": "claude-opus-5-5",
"max_tokens": 4096,
"messages": [{ "role": "user", "content": "Und jetzt die Tests." }],
"thread": { "type": "continue", "previous_message_id": "<ID der letzten Antwort>" }
}
system und tools bleiben bei Folgeanfragen weg, der Thread übernimmt sie aus der ersten Anfrage. Andere Felder wie model oder thinking sind für die Dauer des Threads festgelegt.
Ein Thread ist ausdrücklich "best-effort". Er läuft fünf Minuten nach der letzten Anfrage ab, jede gespeicherte Antwort startet die fünf Minuten neu. Kann die API einen Thread nicht fortsetzen, kommt ein 404 mit thread_not_found, und der Client muss den vollen Verlauf aus seiner eigenen Kopie neu schicken. Den Verlauf lokal mitzuführen bleibt also Pflicht. Die SDKs bringen einen Helfer mit, der diesen Neustart einmal selbst übernimmt.
Was es bringt und was nicht
Der Gewinn liegt bei der Latenz. Laut Anthropic sinkt die mittlere Zeit bis zum ersten Token bei Anfragen mit 500.000 bis einer Million Tokens um etwa 35 Prozent, gemessen bei Nutzern von Claude Code, wo Threads schon standardmäßig laufen.
Billiger wird es nicht. Bei jedem Schritt liest Claude weiter den kompletten Verlauf, die Token-Rechnung bleibt dieselbe, Preise und Rate Limits ändern sich nicht. Auch Prompt Caching übernimmt der Thread nicht automatisch. Wer Kosten sparen will, setzt die cache_control-Marken weiter selbst, pro Anfrage sind höchstens vier erlaubt.
| ohne Thread | mit Thread | |
|---|---|---|
| Größe der Anfrage | wächst mit jedem Schritt | nur die neuen Nachrichten |
| Zeit bis zum ersten Token | steigt mit dem Verlauf | niedriger und gleichmäßiger |
| Token-Kosten | voller Verlauf | unverändert voller Verlauf |
| Verlauf auf dem Server | nein | bis zu einer Stunde |
| Zero Data Retention | möglich | nicht für diese Funktion |
Datenschutz: kein Zero Data Retention
Für DSGVO-bewusste Teams ist der letzte Punkt der wichtigste. Die Dokumentation führt Message Threads als nicht geeignet für Zero Data Retention (ZDR) und HIPAA. Was ein Thread enthält, also Verlauf, System-Prompt und Tools, liegt verschlüsselt im Arbeitsspeicher, wird nie dauerhaft gespeichert und spätestens eine Stunde nach der letzten Nutzung gelöscht. Andere ZDR-fähige Funktionen bleiben davon unberührt.
Wer einen ZDR-Vertrag hat, sollte Threads also nicht einfach einschalten, sondern vorher klären, ob eine Stunde im Arbeitsspeicher zum eigenen Vertrag und zur Datenschutz-Folgenabschätzung passt. Wie heikel solche Retention-Fragen werden können, hat sich im Juni bei Fable 5 und den ZDR-Verträgen gezeigt.
Verfügbar sind Threads über die Claude API, Claude Platform on AWS, Claude Models on Google Cloud (von Anthropic betrieben) und Claude in Microsoft Foundry, für alle aktuellen Modelle bis zurück zur 4.5-Generation. Wer neu mit der API arbeitet, findet die Grundlagen im Artikel KI per API: das Modell als Baustein im Code.