Anthropic hat am 2. November auf der Claude Platform eine öffentliche Beta von Message Threads freigeschaltet. Entwickler fügen ihrer Messages-API-Anfrage einen thread-Parameter hinzu, senden in der ersten Runde die vollständige Unterhaltung und danach pro Runde nur noch die neuen Nachrichten samt ID der letzten Antwort. Den Rest, also das Zusammensetzen der Unterhaltung, übernimmt der Server.
Die offizielle Zahl stammt aus Claude Code. Die Funktion ist dort für die meisten Nutzer bereits standardmäßig aktiviert; bei Anfragen mit 500k bis 1M Token sinkt die mediane Zeit bis zum ersten Token um etwa 35 Prozent. Zu anderen Längenbereichen nennt der Blog keine Werte.
Die Beta gilt für die Claude API, Claude Platform on AWS, Microsoft Foundry sowie für von Anthropic betriebenes Claude auf Google Cloud. Die in der Dokumentation aufgeführten Modelle reichen von Sonnet 4.5 und Opus 4.5 bis zu Fable 5.1 und Mythos 5.1.
Gespart werden Validierung und Tokenisierung
Ohne Threads muss ein Agent in jeder Runde die gesamte Unterhaltung erneut hochladen, und die API validiert und tokenisiert sie jedes Mal von Neuem. Je länger die Sitzung, desto aufwendiger diese Vorarbeit. Besonders betroffen sind Agenten für die Computersteuerung, die frühere Screenshots in jeder Runde erneut mitschicken müssen.
Threads halten diese Inhalte im Arbeitsspeicher des Servers vor, sodass im Wesentlichen nur noch die neu hinzugekommene Runde verarbeitet werden muss.
Claude muss in jeder Runde dennoch die gesamte Unterhaltung lesen. Die Zahl der Token auf Modellseite sinkt also nicht, und Abrechnung sowie Ratenlimits folgen den bestehenden Regeln. Eine grobe Rechnung: Bei einer Sitzung mit 800.000 Token und 2.000 neuen Token pro Runde beträgt die mit Threads zu übertragende Datenmenge nur noch etwa ein Vierhundertstel, auf der Rechnung stehen aber weiterhin gut 800.000 Eingabe-Token. Geld sparen lässt sich weiterhin nur über Prompt-Caching, einen eigenen Schalter: Thread-Anfragen können auf oberster Ebene cache_control enthalten; ohne diesen Eintrag wird auch bei ausschließlich neuen Nachrichten nichts zwischengespeichert.
Bei der Integration einen Rückweg einplanen
Die Dokumentation beschreibt Threads als "Best Effort", und das bestimmt die Art der Anbindung.
- Ablauf: Ein Thread verfällt 5 Minuten nach der letzten Anfrage; mit jeder gespeicherten Antwort beginnt die Frist neu, spätestens 1 Stunde nach der letzten Nutzung wird er gelöscht.
- Ungültigkeit: Liefert eine Folgeanfrage 404, muss die vollständige Unterhaltung neu gesendet und ein neuer Thread angelegt werden. Die Antwort verrät nicht, ob die aktuelle Runde erfolgreich gespeichert wurde; das zeigt sich erst bei der nächsten Folgeanfrage.
- Kopie: Die maßgebliche Fassung der Unterhaltung bleibt bei der Anwendung. Die Hilfsfunktionen der offiziellen SDKs halten eine Kopie im Arbeitsspeicher und spielen sie automatisch erneut ein; mit dem Prozessende ist sie weg. Wer prozessübergreifend arbeiten will, muss selbst speichern.
- Feste Felder:
systemundtoolswerden nur beim Anlegen gesendet; sind sie in einer Folgeanfrage enthalten, auch als null, folgt ein 400-Fehler. Felder wiemodel,thinking,tool_choiceundmcp_serversmüssen in jeder Runde unverändert erneut gesendet werden, andernfalls kommtthread_fingerprint_mismatchzurück. Wer System-Prompt oder Tools wechseln will, muss einen neuen Thread eröffnen.
Auch bei der Compliance gibt es eine Einschränkung. Thread-Inhalte werden verschlüsselt im Arbeitsspeicher gehalten und nicht in einen dauerhaften Speicher geschrieben, die Funktion erfüllt aber nicht die Voraussetzungen für Zero Data Retention (ZDR). Unternehmen mit ZDR-Vertrag können andere Funktionen unverändert nutzen, Threads jedoch nicht.
Außerdem sollten Entwickler zwei Dinge auseinanderhalten: Auch Claude Managed Agents kennen Session Threads, das ist etwas anderes als die jetzigen Message Threads.
Eine fehlende Lücke wird geschlossen
Die Responses API von OpenAI bietet schon lange previous_response_id, ebenfalls eine ID, mit der man an den bisherigen Kontext anknüpft. Anthropic verlangte dagegen lange, dass der Client in jeder Runde den vollständigen Verlauf mitschickt. Das hat den Vorteil, zustandslos und unkompliziert umzusetzen zu sein, kostet aber Latenz, sobald die Sitzung wächst. Der neue Ansatz ist ein Kompromiss: Der Zustand liegt nur kurz auf dem Server, geht er verloren, wird neu eingespielt, und die Kopie auf Client-Seite bleibt unverzichtbar.
Nach den von Anthropic genannten Einsatzszenarien sind lang laufende Programmier-Agenten, Agenten für die Computersteuerung sowie Workflows mit vielen Dokumenten und Bildern die Hauptzielgruppe. Anthropic hat die Funktion zunächst standardmäßig im eigenen Claude Code aktiviert und erst danach für API-Nutzer geöffnet.
Wie viel gewöhnliche Unterhaltungen unterhalb von einigen Hunderttausend Token profitieren, dazu nennt Anthropic keine Zahlen; die Dokumentation sagt lediglich, Threads helfen am meisten in langen Agenten-Schleifen. Teams, die eigene Agenten bauen, sollten zunächst mit der Längenverteilung ihrer eigenen Sitzungen eine Messrunde fahren und erst dann entscheiden, ob sich für den Wiedereinspielpfad bei 404 eine zusätzliche Codeschicht lohnt.
Quellen: offizieller Claude-Blog, CocoLoop, Entwicklerdokumentation der Claude Platform; die Latenzreduktion folgt dem von Anthropic veröffentlichten Median für Claude Code, die grobe Rechnung ist eine Schätzung der Redaktion.