Anthropic lancia i message threads: richieste più leggere per gli agenti Claude

Se hai costruito un agente con l’API di Claude, conosci bene il problema: a ogni turno devi rimandare al server l’intera conversazione, con istruzioni di sistema, definizioni degli strumenti e tutta la cronologia. Più il dialogo si allunga, più le richieste diventano pesanti. Il 2 novembre 2026 Anthropic ha risposto con i message threads, una nuova funzione in beta della Messages API che sposta la memoria della conversazione sul server per un breve periodo, così da inviare soltanto i messaggi nuovi.

La novità è descritta nelle note di rilascio della piattaforma Claude e nella documentazione dedicata. In questo articolo ti spiego come funziona, quali limiti ha e per quali progetti ha senso adottarla subito.

Che cosa sono i message threads di Anthropic

Un message thread è una conversazione che l’API conserva lato server per un tempo limitato. Invece di spedire ogni volta tutto lo storico, mandi la conversazione completa una sola volta, poi continui inviando solo le battute successive. Secondo Anthropic questo si traduce in richieste più piccole e in un tempo al primo token più basso e più stabile man mano che il dialogo cresce.

Il vantaggio è dichiarato soprattutto per i cicli di lavoro lunghi degli agenti, quelli in cui il modello chiama strumenti, riceve risultati e ragiona per decine di passaggi. È il caso tipico di un assistente di programmazione o di un agente di supporto che lavora a lungo sulla stessa pratica.

Come si crea e si continua un thread

Il meccanismo è semplice. Alla prima richiesta invii messaggi, istruzioni di sistema e strumenti insieme al parametro thread impostato su “create”. L’API salva la conversazione, compresa la risposta di Claude, associandola all’identificativo della risposta. Per i turni successivi invii soltanto i nuovi messaggi, con il parametro thread impostato su “continue” e il riferimento all’identificativo del messaggio precedente.

Non esiste quindi un identificativo di thread separato: il riferimento è l’id della risposta. Ogni id può essere continuato una sola volta e i thread sono in sola aggiunta, cioè non puoi riscrivere ciò che è già stato salvato.

Nelle richieste di continuazione devi anche togliere i campi system e tools, perché il thread li conserva dalla richiesta iniziale. Se li invii di nuovo, anche con valore nullo, ricevi un errore 400.

Gli header e i campi da non cambiare

La funzione richiede l’header beta message-threads-2026-08-12 su ogni richiesta del thread. Alcuni parametri devono restare identici dall’inizio alla fine: modello, scelta degli strumenti, impostazioni di ragionamento, server MCP, gestione del contesto, configurazione dell’output e l’insieme degli header beta. Se qualcosa cambia, l’API risponde con un errore di mancata corrispondenza dell’impronta del thread.

Restano invece liberi, turno per turno, campi come il numero massimo di token, le sequenze di stop, lo streaming, i metadati e il livello di servizio. In pratica puoi regolare la lunghezza della risposta, ma non cambiare modello a metà strada.

Durata, cancellazione e che cosa succede se il thread sparisce

Qui sta il vincolo più importante. Un thread scade 5 minuti dopo l’ultima richiesta e ogni nuova risposta salvata fa ripartire il conteggio. In ogni caso l’API lo elimina entro un’ora dall’ultimo utilizzo. Se provi a continuare un thread non più disponibile, ricevi un errore 404.

Per questo Anthropic consiglia di tenere sempre una copia della conversazione sul tuo lato e di costruire fin da subito il percorso di recupero. Quando il thread non esiste più, rimandi l’intera conversazione in una nuova richiesta di creazione e riparti da lì. Non c’è infatti alcuna conferma dell’avvenuto salvataggio: ti accorgi di un thread perso solo alla richiesta successiva.

Questa è la differenza concettuale rispetto a una memoria persistente. I message threads sono una scorciatoia di rete e di calcolo, non un archivio di lungo periodo.

Streaming, errori e riprese

Con lo streaming l’id della risposta arriva nell’evento iniziale, ma conviene continuare solo dopo l’evento di chiusura del messaggio. Se il flusso si interrompe prima, puoi rinviare la stessa richiesta di continuazione. Se ricevi gli errori che indicano che il thread è già stato continuato o che una continuazione è ancora in corso, la strada indicata è riaprire la conversazione completa.

Tra gli errori da gestire ci sono thread_not_found (404), la mancata corrispondenza dell’impronta, il thread già continuato e le richieste non supportate. Tutti si risolvono mantenendo invariati i campi fissi oppure ricreando il thread dalla cronologia che custodisci.

Caching, costi e limiti da conoscere

I thread non attivano da soli la cache dei prompt: sei tu a scegliere i punti di cache. Puoi inviare il parametro cache_control a livello principale in ogni richiesta, così da mettere in cache ogni turno. Una richiesta con thread può avere al massimo quattro punti di cache, e quello principale conta come uno. Superare il limite produce un errore 400.

Sul fronte economico, Anthropic precisa che i thread non cambiano prezzi né limiti di velocità. Il beneficio è tecnico: meno dati da spedire e meno lavoro di validazione e tokenizzazione dello storico. La documentazione non pubblica benchmark numerici, quindi ogni stima di risparmio va verificata sul tuo carico reale e non data per scontata.

Se ti interessa tenere sotto controllo la spesa complessiva, può esserti utile la nostra analisi della Usage and Cost Analytics API di Anthropic, arrivata in beta proprio in questi giorni.

Dati, conformità e funzioni escluse

Il punto più delicato riguarda la gestione dei dati. I thread sono tenuti in memoria, cifrati con una chiave gestita dal server, mai scritti su archivi durevoli e cancellati entro un’ora dall’ultimo uso. Nonostante questo, la funzione non è idonea ai flussi con conservazione zero dei dati né alle organizzazioni con la prontezza HIPAA attiva, che non possono usarla. L’uso dei thread non pregiudica però le altre funzioni compatibili con la conservazione zero.

Ci sono poi funzioni non supportate: le richieste in batch, il conteggio dei token con thread, la compattazione su richiesta e quasi tutte le modalità di modifica del contesto. Non esiste inoltre un’API per elencare, leggere o cancellare un thread, e le organizzazioni con gli hook di inferenza attivi non possono utilizzarli.

Sono previsti anche i fallback, a condizioni precise: la decisione va presa alla creazione del thread e un turno servito da un modello di ripiego non viene salvato, quindi non puoi continuarlo. In caso di rifiuto del modello, la raccomandazione è aprire un nuovo thread senza il turno che l’ha provocato.

Dove è disponibile e per chi ha senso usarlo

I message threads sono in beta sulla Claude API, su Claude Platform su AWS, su Claude Models su Google Cloud nella versione gestita da Anthropic e su Claude in Microsoft Foundry. La documentazione dice che la funzione è disponibile su ogni modello e negli esempi usa claude-opus-5-5. Esiste anche un helper negli SDK che gestisce in automatico creazione e continuazione.

Chi ne trae più vantaggio? Soprattutto chi sviluppa agenti con molti turni e strumenti, dove l’invio ripetuto di prompt di sistema lunghi e cronologie voluminose pesa sulla latenza. Per una chat breve o per carichi in batch il guadagno è poco o nullo, e per i settori regolati i vincoli su conservazione dei dati e HIPAA possono chiudere la strada.

Per chi lavora con Claude ogni giorno, anche nel marketing e nella SEO, vale la pena ripassare le basi nella nostra guida a Claude. E se vuoi capire come cambiano i limiti d’uso dei piani, leggi anche il nostro approfondimento su Claude Max e Ultra.

Il contesto: perché Anthropic lavora sulla latenza degli agenti

Negli ultimi mesi gli agenti sono diventati il banco di prova dei grandi laboratori. Più un agente lavora a lungo, più il costo nascosto non è il singolo token ma la ripetizione continua del contesto. Intervenire su questo punto significa rendere più sostenibili le applicazioni che girano per ore.

Va detto con chiarezza che la funzione è in beta, con un header datato 12 agosto 2026 e con limiti stretti sulla durata. Non è una soluzione universale, ma un’ottimizzazione da applicare con criterio dove i turni sono ravvicinati. Se tra un messaggio e l’altro passano più di cinque minuti, il thread semplicemente non c’è più.

Un altro aspetto da considerare è la sicurezza operativa degli agenti. Se ti occupi di protezione dei sistemi, leggi cosa è emerso nel caso Cathedral di Anthropic, dove gli agenti hanno violato sistemi in poche ore.

Conclusioni: come provarli senza rischi

Il consiglio pratico è procedere per gradi. Parti da un agente di test, attiva l’header beta, crea un thread e misura tempo al primo token e dimensione delle richieste con e senza la funzione. Tieni sempre la cronologia nel tuo sistema e scrivi subito la logica che, davanti a un errore 404, ricrea il thread dall’inizio.

Valuta poi i vincoli di conformità prima di portare la funzione in produzione, soprattutto se tratti dati sanitari o hai bisogno di conservazione zero. Se lavori con le API di Claude, prova i message threads su un caso reale e verifica se il guadagno in latenza giustifica la complessità in più. Dimmi la tua esperienza: ci interessa sapere come vanno nei tuoi progetti.