Anthropic lancia la beta dei thread di messaggi per gli agenti di lunga durata

Il 2 novembre 2026, Anthropic ha introdotto i thread di messaggi in beta pubblica, consentendo alle applicazioni che usano la Messages API sulla Claude Platform di inviare solo i nuovi messaggi dopo una prima richiesta contenente l’intera conversazione.

La funzionalità è pensata per le sessioni attive in cui la latenza è importante, tra cui gli agenti di programmazione di lunga durata, gli agenti che usano il computer e mantengono gli screenshot nel thread e i flussi di lavoro che si basano su numerosi documenti e immagini. Anthropic riferisce che, con i thread di messaggi attivati per impostazione predefinita per la maggior parte degli utenti di Claude Code, le richieste contenenti da 500.000 a 1 milione di token registrano una riduzione di circa il 35% del tempo mediano necessario per ricevere il primo token.

Ciclo di vita delle richieste e ripristino

Senza un thread, a ogni turno viene caricata di nuovo l’intera conversazione e l’API la convalida e la tokenizza nuovamente per intero. Con un thread, la maggior parte di queste operazioni riguarda solo il nuovo turno, prima che l’API ricostruisca la conversazione per il modello. Claude continua a leggere l’intera conversazione a ogni turno, quindi il consumo di token resta invariato. Si applicano le tariffe standard per i token e i limiti di frequenza esistenti.

La documentazione ufficiale suddivide il ciclo di vita in richieste di creazione e di continuazione. Una richiesta di creazione invia la conversazione completa, il prompt di sistema e gli strumenti con il thread parametro; l’API archivia la conversazione e la risposta di Claude associandole all’ID della risposta. Una richiesta di continuazione invia solo i messaggi successivi alla risposta precedente insieme all’ID di quella risposta, escludendo system e tools. Ogni nuovo ID di risposta viene quindi usato per il turno successivo.

I thread funzionano secondo il principio del massimo sforzo e scadono cinque minuti dopo l’ultima richiesta; ogni risposta archiviata dall’API fa ripartire questo intervallo. Le applicazioni restano la fonte di riferimento e devono conservare una propria copia di ogni messaggio. Se l’API non può più proseguire un thread, il client invia nuovamente l’intera conversazione in una nuova richiesta di creazione. L’helper per i thread dell’SDK crea e continua i thread, aggiunge l’intestazione beta richiesta, mantiene la conversazione in memoria e, in caso di specifici errori di continuazione, ripete automaticamente una volta l’invio dell’intera conversazione.

Conservazione e memorizzazione nella cache

I contenuti dei thread sono conservati in memoria e protetti dalla crittografia gestita dal server; non vengono mai scritti in un archivio persistente e sono eliminati entro un’ora dall’ultimo utilizzo. Un thread contiene la conversazione inviata al modello, il prompt di sistema e gli strumenti della richiesta di creazione, oltre a un’impronta digitale dei campi fissi, usata per verificare le richieste successive. I file sono conservati tramite riferimenti, quindi le applicazioni devono mantenere disponibili tutti i file usati nella conversazione per tutta la durata del thread. I thread di messaggi non sono idonei alla conservazione zero dei dati né all’uso in ambito HIPAA, anche se la funzionalità non influisce sull’idoneità per altre funzionalità che prevedono la conservazione zero dei dati.

I thread non memorizzano automaticamente i prompt nella cache; gli sviluppatori devono specificare punti di interruzione della cache o parametri di primo livello cache_control. Una richiesta con thread può includere al massimo quattro punti di interruzione per il controllo della cache. I thread sono inoltre di sola aggiunta e ogni ID di risposta può essere usato per continuare una sola volta. La modifica di un campo utilizzabile solo in fase di creazione, come system o tools, oppure di un campo fisso richiede un nuovo thread contenente l’intera conversazione.

Streaming, disponibilità e limiti della funzionalità

Per le risposte in streaming, i client devono attendere l’ message_stop evento prima di continuare usando l’ID della risposta, perché una richiesta di continuazione inviata in anticipo può restituire un errore 404. L’helper dell’SDK non riprova automaticamente una richiesta di continuazione se lo streaming si interrompe. L’API non archivia i turni generati da modelli di fallback; per riprendere l’uso dei thread, è necessario inviare l’intera conversazione in una nuova richiesta di creazione.

La beta è disponibile sulla Claude Platform nativa, sulla Claude Platform su AWS, su Claude in Microsoft Foundry e su Claude Models su Google Cloud con gestione Anthropic, con supporto beta per tutti i modelli. Non esiste un’API per elencare, leggere o eliminare i thread. I thread non supportano Message Batches, il conteggio dei token, la compattazione su richiesta o la maggior parte delle operazioni di modifica del contesto; inoltre, non sono disponibili per le organizzazioni che hanno attivato gli hook di inferenza.

Poiché i thread scadono e non possono essere recuperati tramite un’API, le applicazioni che usano la beta devono comunque conservare la propria cronologia delle conversazioni e mantenere una modalità per reinviare l’intera conversazione, anche quando i turni ordinari contengono solo nuovi messaggi.