AIREITERAnthropic ha reso disponibili in beta pubblica i message threads il 2 novembre 2026. Il vantaggio principale, però, è facile da interpretare male: sulle richieste da 500K-1M token il tempo mediano al primo token scende di circa il 35%, ma il costo in token non cambia. Per gli agenti che eseguono loop molto lunghi è soprattutto un'ottimizzazione del trasporto, con un limite rigido di 5 minuti di inattività.
Richieste più veloci, stesso costo: cosa cambia davvero con i thread
I message threads sono uno stato conversazionale temporaneo, conservato lato server per la Messages API e lanciato in beta pubblica il 2 novembre 2026. Nella prima richiesta invii l'intera cronologia con thread: { "type": "create" }; nelle successive mandi soltanto i nuovi messaggi insieme a previous_message_id, usando thread: { "type": "continue" }. Come spiegano l'annuncio di Anthropic e la documentazione della piattaforma, lo stato risiede in memoria cifrata, non viene mai scritto su disco, scade dopo 5 minuti di inattività e viene eliminato non oltre 1 ora dall'ultimo utilizzo.
Ogni richiesta all'interno di un thread deve includere l'header beta anthropic-beta: message-threads-2026-08-12. Prezzi e limiti di utilizzo restano invariati: Claude continua a leggere l'intera conversazione a ogni turno, quindi paghi gli stessi token di input e output, anche se trasferisci molti meno byte.
"Sì, bello, ma non riduce il costo dei token :( Claude continua a leggere l'intera conversazione a ogni turno e il consumo di token resta invariato" — @_navicstein, in risposta al thread ufficiale del lancio
L'annuncio ufficiale indica una riduzione di circa il 35% del TTFT mediano per richieste da 500K-1M token, senza alcuno sconto sui token.
Thread e prompt caching in breve
I thread riducono ciò che invii; il prompt caching riduce ciò che paghi a prezzo pieno. I thread non applicano alcun caching automatico: devi comunque impostare i punti di interruzione con cache_control. L'interazione dettagliata con il caching riportata più avanti segue la disamina dell'implementazione: mantieni un cache_control di primo livello in ogni continuazione, con le letture dalla cache a 0.1x del prezzo base dell'input (0.05x su Claude Opus 5.5 e Sonnet 5.5).
Thread Messages API e thread delle sessioni managed-agent
I risultati di ricerca spesso confondono due tipi diversi di «thread». I message threads della Messages API — quelli trattati in questo articolo — sono un'ottimizzazione effimera delle dimensioni delle richieste e non dispongono di API per l'elenco, la lettura o l'eliminazione. I thread delle sessioni managed-agent (GET /v1/sessions/{session_id}/threads/{thread_id}) sono invece thread di esecuzione all'interno dell'API managed-agents di Anthropic, con endpoint per elencarli, recuperarli e archiviarli. Se nella documentazione trovi riferimenti a child thread, flussi di eventi o archiviazione, stai consultando l'API sbagliata. La documentazione API dei thread di sessione ti permette di verificare quale superficie ti serve.
Il ciclo di vita di un thread: creazione, continuazione e scadenza
In pratica, un thread funziona in modalità append-only: lo crei con il contesto completo, lo prosegui aggiungendo solo le differenze e, se va perso, lo ricrei con un replay. Non esistono API per diramare, modificare, riavvolgere o ispezionare un thread. Ogni risposta restituisce un nuovo id, e ciascun id può essere usato per una sola continuazione. Le regole sui campi e sugli errori in questa sezione seguono la documentazione della piattaforma, come dettagliato nella disamina dell'implementazione.
La creazione include tutto: messages, system e tools completi, oltre a:
{
"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" }
}La continuazione contiene solo ciò che è nuovo, in genere un messaggio dell'utente o blocchi 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" }
}Durante una continuazione non inviare system né tools: anche "system": null genera un errore 400. Se usi lo streaming, aspetta message_stop prima di proseguire; l'ID utilizzabile per la continuazione arriva in message_start.
Quali campi puoi modificare durante un thread
Anthropic calcola un fingerprint su una parte della richiesta di creazione. Se modifichi uno dei valori inclusi nel fingerprint, ricevi thread_fingerprint_mismatch e devi aprire un nuovo thread.
| Gruppo | Esempi | Regola per la continuazione |
|---|---|---|
| Solo in creazione | system, tools | Non reinviarli mai; anche null causa un errore |
| Fissi | model, tool_choice, thinking, mcp_servers, context_management, output_config, competenze del container, gestione di cache_control di primo livello | Devono restare identici |
| Modificabili | max_tokens, stop_sequences, stream, metadata, service_tier | Possono cambiare a ogni turno |
| Da reinviare sempre | URL / token di autenticazione dei server MCP, ID del container | Non vengono conservati lato server: includili ogni volta che li usi |
Con i modelli dotati di extended thinking serve un'attenzione in più: modificare system o tools può invalidare i blocchi thinking / redacted_thinking precedenti. Se un replay completo dopo la scadenza restituisce un errore 400, elimina dalla cronologia riprodotta i blocchi di thinking obsoleti invece di ritentare la richiesta identica.
La regola dei 5 minuti e il replay da implementare
Considera i thread una funzione best-effort: conserva localmente la cronologia completa, il system prompt, gli strumenti e i riferimenti ai file, perché la persistenza è confermata soltanto quando una continuazione successiva va a buon fine. I file vengono mantenuti tramite riferimento: se un file viene eliminato durante il thread, la continuazione non può riuscire.
Il timer della scadenza si azzera a ogni risposta memorizzata. Dopo 5 minuti di inattività, la continuazione successiva restituisce 404 e devi reinviare l'intera conversazione come una nuova create. I dati vengono eliminati non oltre 1 ora dall'ultimo utilizzo.
| HTTP | Codice | Cosa è successo | Cosa fare |
|---|---|---|---|
| 404 | thread_not_found | Thread scaduto, non memorizzato, chiave/workspace errati, prima immagine aggiunta a un thread solo testuale, risposta gestita dal modello di fallback oppure generazione ancora in corso | Verifica chiave/workspace e configurazione, poi riproduci l'intera cronologia con una nuova create |
| 400 | thread_fingerprint_mismatch | È cambiato un campo fisso | Ripristina il valore originale o avvia un nuovo thread |
| 400 | thread_already_continued | Quel previous_message_id è già stato utilizzato | Prosegui dall'id più recente |
| 400 | thread_continue_in_flight | È stata avviata una continuazione concorrente sullo stesso ID | Attendi che termini, poi usa il nuovo ID; in alternativa esegui il replay |
| 400 | thread_unsupported_request | Impostazione non supportata, per esempio più di 4 punti di interruzione della cache o richieste batch | Rimuovi l'impostazione o invia la richiesta senza thread |
Secondo il riepilogo della documentazione, le richieste che falliscono a livello di thread vengono bloccate prima dell'esecuzione del modello: non consumano token e non azzerano il timer di scadenza. Salva in modo atomico l'ID dell'ultima risposta riuscita prima di accettare il turno successivo e rendi i replay idempotenti quando le azioni degli strumenti hanno effetti collaterali.
Struttura del replay in Python (gestisci soltanto il thread_not_found verificato; gli errori di fingerprint, concorrenza e richiesta non supportata richiedono rami separati):
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"},
)Il trabocchetto dei 404 con proxy e rotazione delle chiavi
Si tratta di un comportamento segnalato dagli operatori, non ancora documentato ufficialmente: un thread è legato all'organizzazione, al workspace e alla credenziale con cui è stato creato. Un relay che ruota le chiavi API a ogni richiesta creerà il thread con la chiave A e proverà a proseguirlo con la chiave B. Il risultato è identico a una scadenza: una sequenza infinita di 404 seguita dal replay completo, senza alcun guadagno di latenza.
"Il thread è legato alla key e al workspace con cui viene creato; cambiando key si ottiene 404 thread_not_found. Un proxy che ruota le key incassa prima un 404 e poi reinvia tutto." — @ak12kpoot (nota di uno sviluppatore cinese sul comportamento dei proxy)
Associa ogni thread a una sola chiave oppure disattiva i thread sui percorsi che usano chiavi condivise.
Dove funzionano i thread, cosa escludono e se conviene adottarli subito
I message threads sono disponibili su Claude API, Claude Platform su AWS, Anthropic-managed Google Cloud Claude Models e Claude in Microsoft Foundry. La beta copre tutti i modelli; non esiste una allowlist separata dei modelli né è indicata una lista d'attesa.
Per pianificare il lancio, però, contano soprattutto le esclusioni:
| Area | Stato |
|---|---|
| Amazon Bedrock | Non supportato |
| Message Batches | Non supportati: gli elementi batch dei thread falliscono |
| Endpoint per il conteggio dei token | Non supportato: devi contare autonomamente l'intera cronologia |
| Compaction / context editing | Non supportati (eccetto clear_thinking con keep all) |
| Zero data retention, HIPAA-ready, inference hooks | Non idonei |
| API di gestione dei thread | Nessuna: non puoi elencare, leggere o eliminare i thread |
Checklist per decidere
- Usali subito: agenti di coding attivi, loop di computer use con screenshot o flussi ricchi di documenti che eseguono decine di turni con pause inferiori a 5 minuti. Affiancali al prompt caching e a un percorso di replay.
- Per ora lasciali perdere: chat a ritmo umano, workflow sospesi, pipeline batch, carichi di lavoro ZDR/HIPAA o deployment su Bedrock.
- Combinali quando conviene: il
cache_controldi primo livello presente in ogni richiesta conta nel limite di 4 punti di interruzione; quelli definiti insystem/toolsdurante la creazione vengono conteggiati di nuovo in ogni continuazione. Superare il limite restituiscethread_unsupported_request, quindi accorpa i punti di interruzione prima di attivare entrambe le funzioni.
Puoi leggere anche: guida ai prezzi della Claude API 2026, guida alla Claude Skills API.
FAQ
Quale header beta e quale parametro devo usare?
Invia anthropic-beta: message-threads-2026-08-12 in ogni richiesta del thread, insieme a thread: { "type": "create" } nella prima chiamata e a thread: { "type": "continue", "previous_message_id": "<last response id>" } nelle successive.
Cosa succede quando un thread scade?
La continuazione successiva restituisce 404 thread_not_found. Reinvia l'intero messages insieme a system/tools originali come nuova create. La scadenza avviene dopo 5 minuti di inattività, con eliminazione non oltre 1 ora dall'ultimo utilizzo.
Posso elencare, ispezionare o eliminare i thread?
No. Per i thread della Messages API non esiste un'API di gestione. L'unica copia durevole è la cronologia che conservi localmente.
Funziona su Amazon Bedrock?
No. Le superfici supportate sono Claude API, AWS Claude Platform, Microsoft Foundry e Google Cloud gestito da Anthropic. Su Bedrock devi continuare a inviare l'intera cronologia.
Posso modificare il system prompt o gli strumenti durante un thread?
No. Crea un nuovo thread con il nuovo system/tools. Inviare valori modificati durante una continuazione genera thread_fingerprint_mismatch. La stessa regola vale per model, tool_choice e configurazione del thinking.
Funziona con streaming, strumenti e MCP?
Sì, ma con alcune regole: aspetta message_stop prima di proseguire, reinvia URL/token MCP e ID del container a ogni turno e invia fallbacks in ogni richiesta oppure in nessuna. Una risposta prodotta dal modello di fallback non viene memorizzata e deve essere riprodotta.