AIREITERAnthropic hat Message Threads am 2. November 2026 als öffentliche Beta veröffentlicht. Der wichtigste Punkt wird dabei leicht missverstanden: Bei Anfragen mit 500.000 bis 1 Million Tokens sinkt die mediane Zeit bis zum ersten Token um etwa 35 Prozent – an der Tokenabrechnung ändert sich jedoch nichts. Für lange Agentenschleifen ist das vor allem eine Optimierung der Übertragung, allerdings mit einem strikten Leerlauf-Limit von 5 Minuten.
Schnellere Anfragen, gleiche Rechnung: Was Threads ändern – und was nicht
Message Threads speichern den vorübergehenden Konversationszustand serverseitig für die Messages API und sind seit dem 2. November 2026 als öffentliche Beta verfügbar. Beim ersten Aufruf überträgst du den vollständigen Verlauf mit thread: { "type": "create" }. Danach werden nur neue Nachrichten zusammen mit previous_message_id und thread: { "type": "continue" } gesendet. Laut Anthropics Ankündigung und der Plattformdokumentation liegt der Zustand im verschlüsselten Arbeitsspeicher, wird nie auf der Festplatte abgelegt, läuft nach 5 Minuten Inaktivität ab und spätestens 1 Stunde nach der letzten Nutzung gelöscht.
Jede Anfrage innerhalb eines Threads muss den Beta-Header anthropic-beta: message-threads-2026-08-12 enthalten. Preise und Ratenlimits bleiben unverändert: Claude liest in jedem Turn weiterhin die komplette Konversation, deshalb zahlst du dieselben Input- und Output-Tokens – nur die Zahl der übertragenen Bytes sinkt deutlich.
„Ja, nett – aber die Tokenkosten sinken nicht :( Claude liest in jedem Turn weiterhin die komplette Konversation und der Tokenverbrauch bleibt unverändert“ – @_navicstein als Antwort auf den offiziellen Launch-Thread
Die offizielle Ankündigung nennt für Anfragen mit 500.000 bis 1 Million Tokens eine rund 35 Prozent niedrigere mediane TTFT – ohne Tokenrabatt.
Threads und Prompt Caching in einem Absatz
Threads reduzieren, was du sendest; Prompt Caching reduziert, für welchen Teil du den vollen Preis zahlst. Threads cachen nicht automatisch – die Breakpoints über cache_control musst du weiterhin selbst setzen. Die Details zum Zusammenspiel weiter unten folgen der Implementierungsanalyse: Verwende bei jeder Fortsetzung ein übergeordnetes cache_control. Cache-Lesezugriffe kosten 0,1-mal den normalen Input-Preis, bei Claude Opus 5.5 und Sonnet 5.5 0,05-mal.
Threads und verwaltete Agenten-Threads
In den Suchergebnissen werden zwei unterschiedliche Arten von „Threads“ vermischt. Message-Threads der Messages API – um die es hier geht – optimieren vorübergehend die Größe von Requests und bieten keine API zum Auflisten, Lesen oder Löschen. Session-Threads der Managed-Agents-API (GET /v1/sessions/{session_id}/threads/{thread_id}) sind dagegen Ausführungs-Threads innerhalb der verwalteten Agenten-API und verfügen über Endpunkte zum Auflisten, Abrufen und Archivieren. Wenn in der Dokumentation von Child-Threads, Event-Streams oder Archivierung die Rede ist, bist du bei der falschen API. Die API-Referenz für Session-Threads zeigt, welche Oberfläche du brauchst.
So läuft ein Thread ab: Erstellen, fortsetzen, ablaufen
Praktisch funktionieren Threads nach dem Append-only-Prinzip: Zuerst wird der vollständige Kontext angelegt, danach werden nur Änderungen übertragen und nach einem Verlust wird der Verlauf erneut abgespielt. Eine API zum Verzweigen, Bearbeiten, Zurückspulen oder Inspizieren gibt es nicht. Jede Antwort liefert eine neue id, und jede id kann nur einmal fortgesetzt werden. Die Feld- und Fehlerregeln in diesem Abschnitt entsprechen der Plattformdokumentation und der ausführlichen Implementierungsanalyse.
Beim Erstellen werden alle Bestandteile übertragen: der vollständige Inhalt von messages, system und tools sowie:
{
"model": "claude-opus-5-5",
"system": "You are a support agent for Acme. Keep replies short.",
"messages": [{ "role": "user", "content": "Hi! I have a question about an order." }],
"thread": { "type": "create" }
}Bei einer Fortsetzung wird nur das übertragen, was neu hinzugekommen ist – normalerweise eine User-Nachricht oder Blöcke vom Typ tool_result:
{
"model": "claude-opus-5-5",
"messages": [{ "role": "user", "content": "How long does standard shipping usually take?" }],
"thread": { "type": "continue", "previous_message_id": "msg_xxx_from_create" }
}system und tools dürfen bei continue nicht mitgesendet werden – selbst "system": null führt zu einem 400-Fehler. Bei Streaming musst du auf message_stop warten, bevor du fortsetzt; die verwendbare ID für den nächsten Aufruf kommt in message_start.
Welche Felder du innerhalb eines Threads ändern kannst
Anthropic bildet für einen Teil der Create-Anfrage einen Fingerabdruck. Wird ein solcher Wert geändert, kommt thread_fingerprint_mismatch zurück und ein neuer Thread ist erforderlich.
| Gruppe | Beispiele | Regel bei continue |
|---|---|---|
| Nur beim Erstellen | system, tools | Nie erneut senden; auch null schlägt fehl |
| Fest | model, tool_choice, thinking, mcp_servers, context_management, output_config, Container-Skills, Behandlung von cache_control auf oberster Ebene | Muss identisch bleiben |
| Frei änderbar | max_tokens, stop_sequences, stream, metadata, service_tier | Darf sich pro Turn ändern |
| Immer erneut senden | MCP-Server-URLs/-Authentifizierungstokens, container-ID | Wird nicht serverseitig gespeichert und muss bei jeder Nutzung enthalten sein |
Bei Modellen mit Extended Thinking ist besondere Vorsicht nötig: Änderungen an system oder tools können frühere thinking- oder redacted_thinking-Blöcke ungültig machen. Liefert ein vollständiges Replay nach Ablauf des Threads einen 400-Fehler, solltest du die veralteten Thinking-Blöcke aus dem erneut gesendeten Verlauf entfernen, statt ihn unverändert erneut zu übertragen.
Die 5-Minuten-Regel und das notwendige Replay
Behandle Threads als Best-Effort-Funktion: Speichere den vollständigen Verlauf, Systemanweisungen, Tools und Dateireferenzen lokal, denn erst eine erfolgreiche nächste Fortsetzung bestätigt, dass der Zustand tatsächlich vorhanden ist. Dateien werden nur referenziert – wird eine Datei während des Threads gelöscht, schlägt die Fortsetzung fehl.
Die Ablaufzeit wird nach jeder gespeicherten Antwort zurückgesetzt. Nach 5 Minuten Inaktivität liefert der nächste continue-Aufruf einen 404-Fehler; anschließend musst du die vollständige Konversation als neuen create-Aufruf wiederholen. Spätestens 1 Stunde nach der letzten Nutzung sind die Daten gelöscht.
| HTTP | Code | Was passiert ist | Das ist zu tun |
|---|---|---|---|
| 404 | thread_not_found | Abgelaufen, nicht gespeichert, falscher Key oder Workspace, erstes Bild an einen reinen Text-Thread angehängt, von einem Fallback-Modell verarbeitet oder Antwort noch in Generierung | Key, Workspace und Konfiguration prüfen, anschließend den vollständigen Verlauf als neuen create-Aufruf wiedergeben |
| 400 | thread_fingerprint_mismatch | Ein festgelegtes Feld wurde geändert | Ursprünglichen Wert wiederherstellen oder neuen Thread starten |
| 400 | thread_already_continued | Die angegebene previous_message_id wurde bereits verwendet | Mit der neuesten id fortsetzen |
| 400 | thread_continue_in_flight | Parallele Fortsetzung mit derselben ID | Auf den laufenden Aufruf warten und danach dessen neue ID verwenden; andernfalls Replay ausführen |
| 400 | thread_unsupported_request | Nicht unterstützte Einstellung, etwa mehr als 4 Cache-Breakpoints oder Batches | Einstellung entfernen oder die Anfrage ohne Thread senden |
Fehlgeschlagene Thread-Anfragen werden laut der Dokumentationszusammenfassung vor der Modellausführung abgebrochen. Sie verbrauchen daher keine Tokens und setzen den Ablauf-Timer nicht zurück. Speichere die ID der letzten erfolgreichen Antwort atomar, bevor du den nächsten Turn akzeptierst. Bei Tool-Aktionen mit Seiteneffekten müssen Replays außerdem idempotent abgesichert werden.
Python-Struktur für ein Replay (behandle nur verifiziertes thread_not_found; Fehler wegen Fingerprint, Parallelität und nicht unterstützten Requests brauchen separate Pfade):
try:
resp = client.beta.messages.create(
model="claude-opus-5-5",
messages=[new_msg], # delta only
thread={"type": "continue", "previous_message_id": last_id},
extra_headers={"anthropic-beta": "message-threads-2026-08-12"},
)
except NotFoundError: # thread_not_found after checking identity/config
resp = client.beta.messages.create(
model="claude-opus-5-5",
system=SYSTEM, tools=TOOLS,
messages=full_history + [new_msg], # you stored this
thread={"type": "create"},
extra_headers={"anthropic-beta": "message-threads-2026-08-12"},
)Die 404-Falle bei Proxies und rotierenden API-Keys
Dieses Verhalten wurde von Betreibern berichtet, steht aber noch nicht in der offiziellen Dokumentation: Ein Thread ist an die Organisation, den Workspace und das Zugangstoken gebunden, mit denen er erstellt wurde. Rotiert ein Relay die API-Keys pro Anfrage, wird der Thread mit Key A erstellt und mit Key B fortgesetzt. Das sieht exakt wie ein Ablauf aus: endlose 404-Fehler, anschließend ein vollständiges Replay – ohne jeden Geschwindigkeitsvorteil.
„Der Thread ist an den Key und Workspace gebunden, mit denen er erstellt wurde. Ein anderer Key führt zu 404 thread_not_found. Ein Relay mit rotierenden Keys erhält zuerst einen 404 und sendet danach den gesamten Verlauf erneut.“ – @ak12kpoot (chinesischer Hinweis eines Entwicklers zum Proxy-Verhalten)
Binde einen Thread an einen einzelnen Key oder deaktiviere Threads auf Routen mit einem Key-Pool.
Wo Threads laufen, was sie ausschließt und ob du jetzt umsteigen solltest
Message Threads sind über die Claude API, Claude Platform auf AWS, Anthropic-verwaltete Google-Cloud-Claude-Modelle und Claude in Microsoft Foundry verfügbar. In der Beta werden alle Modelle abgedeckt; eine separate Modell-Allowlist oder eine genannte Warteliste gibt es nicht.
Für die Planung wichtiger sind die Bereiche, die ausgeschlossen bleiben:
| Bereich | Status |
|---|---|
| Amazon Bedrock | Nicht unterstützt |
| Message Batches | Nicht unterstützt – gebündelte Thread-Elemente schlagen fehl |
| Token-Counting-Endpunkt | Nicht unterstützt – den vollständigen Verlauf musst du selbst zählen |
| Komprimierung / Context Editing | Nicht unterstützt (außer clear_thinking mit keep all) |
| Zero Data Retention, HIPAA-fertige Umgebungen, Inference Hooks | Nicht zugelassen |
| Thread-Management-API | Nicht vorhanden – Threads können weder aufgelistet noch gelesen oder gelöscht werden |
Entscheidungshilfe
- Jetzt Threads einsetzen: für aktive Coding-Agenten, Computer-Use-Schleifen mit Screenshots oder dokumentenlastige Abläufe mit Dutzenden Turns und Abständen von weniger als 5 Minuten. Prompt Caching und einen Replay-Pfad solltest du kombinieren.
- Vorerst darauf verzichten: bei menschlich getakteten Chats, pausierten Workflows, Batch-Pipelines, ZDR-/HIPAA-Workloads oder Deployments auf Bedrock.
- Nur bei echtem Nutzen kombinieren: Ein
cache_controlauf oberster Ebene zählt in jeder Anfrage gegen das Limit von 4 Breakpoints. Breakpoints aussystem/toolsbeim Erstellen werden bei jeder Fortsetzung erneut mitgezählt. Wird das Limit überschritten, kommtthread_unsupported_requestzurück. Fasse die Breakpoints daher zusammen, bevor du beide Funktionen aktivierst.
Siehe auch: Claude API Pricing Guide 2026, Claude Skills API Guide.
FAQ
Welchen Beta-Header und welchen Parameter brauche ich?
Sende bei jeder Anfrage innerhalb des Threads anthropic-beta: message-threads-2026-08-12. Beim ersten Aufruf kommt zusätzlich thread: { "type": "create" } zum Einsatz, danach thread: { "type": "continue", "previous_message_id": "<last response id>" }.
Was passiert, wenn ein Thread abläuft?
Die nächste Fortsetzung liefert 404 thread_not_found. Sende messages vollständig sowie das ursprüngliche system/tools erneut als neuen create-Aufruf. Der Ablauf erfolgt nach 5 Minuten Inaktivität; spätestens 1 Stunde nach der letzten Nutzung wird gelöscht.
Kann ich Threads auflisten, inspizieren oder löschen?
Nein. Für Threads der Messages API gibt es keine Management-API. Der lokal gespeicherte Verlauf ist die einzige dauerhafte Aufzeichnung.
Funktioniert das mit Amazon Bedrock?
Nein. Unterstützt werden die Claude API, AWS Claude Platform, Microsoft Foundry und Anthropic-verwaltete Google-Cloud-Umgebungen. Bedrock-Anfragen müssen weiterhin den vollständigen Verlauf übertragen.
Kann ich System-Prompt oder Tools innerhalb eines Threads ändern?
Nein. Erstelle mit dem neuen system/tools-Inhalt einen neuen Thread. Geänderte Werte bei continue lösen thread_fingerprint_mismatch aus. Dasselbe gilt für model, tool_choice und die Thinking-Konfiguration.
Funktioniert es mit Streaming, Tools und MCP?
Ja, aber mit einigen Regeln: Warte vor der nächsten Fortsetzung auf message_stop, sende MCP-URLs/-Tokens und container-IDs in jedem Turn erneut und übertrage fallbacks entweder bei jeder Anfrage oder bei keiner. Eine Antwort des Fallback-Modells wird nicht gespeichert und muss wiederholt werden.