Introduzione ai thread di messaggi

Il 2 novembre 2026 Anthropic ha annunciato l’accesso in beta pubblica ai thread di messaggi per le applicazioni che utilizzano la Messages API sulla Claude Platform. Questa innovazione permette di inviare alla API solo i messaggi aggiuntivi dopo una prima richiesta contenente l’intera conversazione, evitando di ricaricare l’intera cronologia ad ogni turno.

La funzionalità è pensata per scenari in cui la latenza è critica, come gli agenti di programmazione di lunga durata, gli agenti che interagiscono con il computer mantenendo screenshot nel thread, e i flussi di lavoro che elaborano numerosi documenti e immagini.

Anthropic segnala 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 mostrano una riduzione media del 35 % del tempo necessario per ricevere il primo token.

Ciclo di vita delle richieste e meccanismo di ripristino

In assenza di thread, ad ogni turno l’intera conversazione viene ricaricata, convalidata e tokenizzata nuovamente. Con i thread, solo il nuovo turno viene processato 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 rimane invariato; si applicano le tariffe standard e i limiti di frequenza esistenti.

La documentazione ufficiale suddivide il ciclo di vita in due tipologie di richieste:

    • Richiesta di creazione: invia la conversazione completa, il prompt di sistema e gli strumenti, includendo il parametro thread. L’API archivia la conversazione e la risposta di Claude associandole all’ID della risposta.
    • Richiesta di continuazione: invia solo i messaggi successivi alla risposta precedente, insieme all’ID di quella risposta, escludendo i campi system e tools. Ogni nuovo ID di risposta viene usato per il turno successivo.

I thread operano secondo il principio del “massimo sforzo” e scadono cinque minuti dopo l’ultima richiesta; ogni risposta archiviata fa ripartire questo intervallo. Le applicazioni devono conservare una propria copia di ogni messaggio perché, se l’API non può più proseguire un thread, il client deve inviare nuovamente l’intera conversazione in una nuova richiesta di creazione.

L’helper per i thread dell’SDK automatizza la creazione e la continuazione, aggiunge l’intestazione beta richiesta, mantiene la conversazione in memoria e, in caso di errori specifici di continuazione, ripete automaticamente una volta l’invio dell’intera conversazione.

Conservazione, cache e limitazioni di sicurezza

I contenuti dei thread sono conservati in memoria e protetti da crittografia gestita dal server; non vengono scritti su storage persistente e vengono eliminati entro un’ora dall’ultimo utilizzo. Un thread contiene:

    • La conversazione inviata al modello
    • Il prompt di sistema
    • Gli strumenti della richiesta di creazione
    • Un’impronta digitale dei campi fissi, usata per verificare le richieste successive

I file allegati sono conservati tramite riferimenti, quindi le applicazioni devono mantenere disponibili tutti i file usati nella conversazione per l’intera durata del thread.

I thread di messaggi non sono idonei per la “conservazione zero dei dati” né per l’uso in ambito HIPAA, anche se non influiscono sull’idoneità di altre funzionalità che prevedono la conservazione zero dei dati.

Per quanto riguarda la cache, i thread non memorizzano automaticamente i prompt. 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.

Altre regole operative:

    • I thread sono di sola aggiunta; ogni ID di risposta può essere usato per continuare una sola volta.
    • Modificare un campo creato solo in fase di creazione (come system o tools) o un campo fisso richiede l’avvio di un nuovo thread con l’intera conversazione.
    • I thread non supportano Message Batches, il conteggio dei token, la compattazione su richiesta o la maggior parte delle operazioni di modifica del contesto.

Streaming, disponibilità e limiti della beta

Quando si utilizza lo streaming, i client devono attendere l’evento message_stop prima di continuare con l’ID della risposta, perché una richiesta di continuazione inviata prematuramente può generare 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 nuovamente l’intera conversazione in una nuova richiesta di creazione.

La beta è disponibile su più ambienti:

    • Claude Platform nativa
    • Claude Platform su AWS
    • Claude in Microsoft Foundry
    • Claude Models su Google Cloud con gestione Anthropic

Il supporto beta è attivo per tutti i modelli, ma non esiste alcuna API per elencare, leggere o eliminare i thread. Inoltre, i thread 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 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.

Implicazioni per gli sviluppatori e scenari d’uso

Gli sviluppatori che costruiscono agenti di lunga durata devono rivedere le loro architetture di gestione della conversazione. In particolare:

    • Implementare una cache locale della cronologia completa per poter ricreare un thread in caso di scadenza.
    • Gestire il timeout di cinque minuti, pianificando heartbeat o richieste di “keep‑alive” se necessario.
    • Assicurarsi che tutti i file referenziati rimangano accessibili per l’intera durata del thread, altrimenti la continuazione fallirà.
    • Utilizzare l’helper SDK per ridurre la complessità di creazione e continuazione, ma testare i casi di errore di streaming e fallback.

Scenari tipici includono:

    • Agent coding assist: un agente che scrive, compila e testa codice per ore, inviando screenshot e log di compilazione come file.
    • Elaborazione documentale massiva: un workflow che analizza centinaia di PDF e immagini, richiedendo più turni di ragionamento.
    • Automazione di interfacce grafiche: un agente che interagisce con un desktop virtuale, catturando schermate ad ogni passo e richiedendo decisioni contestuali.

In tutti questi casi, la riduzione della latenza (fino al 35 %) può tradursi in risparmi di tempo e costi significativi, soprattutto quando le conversazioni superano i 500.000 token.

Conclusioni

I thread di messaggi di Anthropic rappresentano un passo importante verso l’ottimizzazione delle interazioni con modelli di grandi dimensioni in scenari di lunga durata. La beta, pur offrendo miglioramenti di latenza, introduce regole di ciclo di vita, scadenza e conservazione che richiedono attenzione da parte degli sviluppatori. La mancanza di API per la gestione dei thread e le limitazioni relative a cache, batch e contesto implicano che le applicazioni debbano mantenere una copia locale della cronologia e prevedere meccanismi di fallback.

Con il supporto esteso su più cloud e piattaforme, Anthropic sembra pronta a scalare questa funzionalità, ma il successo dipenderà dalla capacità dei team di integrazione di adottare le best practice suggerite e di gestire correttamente la sicurezza e la conformità dei dati.