KI-Modelle und Plattformen
Anthropic startet Betaversion von Message Threads für langlebige Agenten
Unite.AI zu deinen bevorzugten Quellen auf Google hinzufügen
Anthropic führte am 2. November 2026 Nachrichtenthreads in einer öffentlichen Betaversion ein und ermöglichte es Anwendungen der Messages API auf der Claude Platform, nach einer anfänglichen Anfrage mit dem vollständigen Gespräch nur noch neue Nachrichten zu senden.
Die Funktion ist für aktive Sitzungen gedacht, bei denen es auf geringe Latenz ankommt. Dazu gehören lang laufende Coding-Agenten, Agenten zur Computernutzung, bei denen Screenshots im Thread verbleiben, sowie dokument- und bildintensive Arbeitsabläufe. Anthropic zufolge sinkt bei Anfragen mit 500.000 bis 1 Million Token die mediane Zeit bis zum ersten Token um etwa 35 %, wenn Message Threads für die meisten Claude-Code-Nutzer standardmäßig aktiviert sind.
Ablauf und Wiederherstellung von Anfragen
Ohne Thread wird bei jedem Gesprächsschritt der gesamte Gesprächsverlauf erneut hochgeladen, und die API validiert und tokenisiert ihn noch einmal vollständig. Mit einem Thread fällt der Großteil dieser Arbeit nur für den neuen Gesprächsschritt an, bevor die API den Gesprächsverlauf für das Modell neu aufbereitet. Claude liest bei jedem Gesprächsschritt weiterhin den gesamten Gesprächsverlauf, sodass der Tokenverbrauch unverändert bleibt. Es gelten die Standard-Tokenpreise und die bestehenden Ratenbegrenzungen.
Die offizielle Dokumentation unterteilt den Ablauf in Erstellungs- und Fortsetzungsanfragen. Eine Erstellungsanfrage übermittelt den vollständigen Gesprächsverlauf, den System-Prompt und die Tools zusammen mit dem thread Parameter; die API speichert den Gesprächsverlauf und Claudes Antwort unter der Response-ID. Bei einer Fortsetzungsanfrage werden nur die Nachrichten seit der vorherigen Antwort zusammen mit deren ID übermittelt; weggelassen werden system und tools. Jede neue Response-ID wird dann für den nächsten Gesprächsschritt verwendet.
Threads werden nach Möglichkeit bereitgestellt und laufen fünf Minuten nach ihrer letzten Anfrage ab; jede Antwort, die die API speichert, setzt diesen Zeitraum zurück. Die Anwendungen bleiben die maßgebliche Quelle und müssen eine eigene Kopie jeder Nachricht aufbewahren. Kann die API einen Thread nicht mehr fortsetzen, sendet der Client den vollständigen Gesprächsverlauf erneut in einer neuen Erstellungsanfrage. Der Thread-Helfer des SDK erstellt und setzt Threads fort, fügt den erforderlichen Beta-Header hinzu, hält den Gesprächsverlauf im Arbeitsspeicher und spielt ihn bei bestimmten Fortsetzungsfehlern automatisch einmal vollständig erneut ab.
Aufbewahrung und Caching
Thread-Inhalte werden unter serverseitig verwalteter Verschlüsselung im Arbeitsspeicher gehalten, niemals dauerhaft gespeichert und spätestens eine Stunde nach der letzten Verwendung gelöscht. Ein Thread umfasst den an das Modell gesendeten Gesprächsverlauf, den System-Prompt und die Tools der Erstellungsanfrage sowie einen Fingerabdruck fester Felder, anhand dessen spätere Anfragen überprüft werden. Dateien werden nur referenziert. Daher müssen Anwendungen alle im Gesprächsverlauf verwendeten Dateien verfügbar halten, solange der Thread aktiv ist. Message Threads kommen weder für Zero Data Retention noch für die Nutzung im Rahmen von HIPAA infrage; die Funktion wirkt sich jedoch nicht auf die Berechtigung für andere Funktionen zur Speicherung ohne Datenaufbewahrung aus.
Threads speichern Prompts nicht automatisch im Cache; Entwickler müssen Cache-Breakpoints oder Einstellungen auf oberster Ebene angeben cache_control . Eine Anfrage mit Thread kann höchstens vier Cache-Control-Breakpoints enthalten. Threads sind außerdem nur erweiterbar, und jede Response-ID kann einmal fortgesetzt werden. Wird ein Feld geändert, das nur bei der Erstellung gesetzt werden kann, etwa system oder tools, oder ein festes Feld, muss ein neuer Thread mit dem vollständigen Gesprächsverlauf erstellt werden.
Streaming, Verfügbarkeit und Funktionsbeschränkungen
Bei gestreamten Antworten müssen Clients auf das message_stop -Ereignis warten, bevor sie anhand der Response-ID fortfahren, da eine frühere Fortsetzungsanfrage einen 404-Fehler zurückgeben kann. Der SDK-Helfer wiederholt eine Fortsetzungsanfrage nicht automatisch, wenn ein Stream abbricht. Die API speichert keine Gesprächsschritte, die von Fallback-Modellen erstellt wurden. Daher muss der vollständige Gesprächsverlauf in einer neuen Erstellungsanfrage übermittelt werden, bevor Threads wieder verwendet werden können.
Die Betaversion ist auf der nativen Claude Platform, Claude Platform auf AWS, Claude in Microsoft Foundry und Claude Models auf Google Cloud unter der Verwaltung von Anthropic verfügbar; die Beta wird von allen Modellen unterstützt. Es gibt keine API zum Auflisten, Lesen oder Löschen von Threads. Threads unterstützen weder Message Batches noch das Zählen von Token, die bedarfsgesteuerte Komprimierung oder die meisten Möglichkeiten zur Bearbeitung des Kontexts. Außerdem sind sie für Organisationen mit aktivierten Inference Hooks nicht verfügbar.
Da Threads ablaufen und nicht über eine API abgerufen werden können, müssen Anwendungen, die die Betaversion nutzen, ihren Gesprächsverlauf weiterhin selbst speichern und eine Möglichkeit vorhalten, den vollständigen Verlauf erneut zu übermitteln – auch dann, wenn bei den üblichen Gesprächsschritten nur neue Nachrichten gesendet werden.
