Anthropic afferma che l’attesa si riduce del 35% nelle richieste di Claude Code comprese tra 500.000 e un milione di token, evitando che il client ritrasmetta l’intera conversazione a ogni turno. La funzione, chiamata message threads, è disponibile in beta pubblica per la Messages API ed è già attivata per impostazione predefinita per la maggior parte degli utenti di Claude Code.
La modifica riduce il lavoro preliminare alla risposta: dopo aver inviato una volta la cronologia completa, il client può inviare solo i nuovi messaggi e il riferimento alla risposta precedente. Ma non riduce la quantità di contesto elaborata da Claude. La conversazione completa continua a essere ricostruita sul server e il modello la legge a ogni turno, quindi l’uso di token non cambia.
Anthropic ha annunciato la funzione il 2 novembre. Non è limitata a Claude Code: può essere utilizzata anche dalla Messages API per creare agenti personalizzati, compresi quelli che gestiscono chiamate ripetute agli strumenti, schermate o grandi quantità di documenti e immagini.
Meno cronologia ripetuta prima di ogni risposta
Finora, ogni richiesta alla Messages API includeva l’intera cronologia: messaggi precedenti, risultati degli strumenti e qualsiasi altro contenuto accumulato. In una lunga sessione di programmazione, un agente può effettuare centinaia di richieste mentre legge file e modifica codice. Quando la conversazione raggiunge centinaia di migliaia di token, inviare nuovamente tutto quel materiale aggiunge un carico prima che Claude inizi a rispondere.
Con un thread, la prima richiesta continua a includere l’intera conversazione, oltre alle istruzioni di sistema e alle definizioni degli strumenti. Questa richiesta crea il thread sui server di Anthropic. Nelle richieste successive, il client trasmette solo i nuovi contenuti e l’identificatore della risposta precedente. Anthropic ricostruisce lì il contesto completo prima di passarlo al modello.
La differenza riguarda ciò che viaggia dall’applicazione all’API, non ciò che Claude deve leggere. L’azienda misura il risultato in base al tempo al primo token (TTFT): il tempo che trascorre prima che inizi a generare una risposta. Per le richieste di Claude Code con un contesto compreso tra 500.000 e un milione di token, Anthropic comunica una riduzione mediana di circa il 35%.
Questa percentuale si riferisce al TTFT in tale intervallo di contesto, non alla durata totale di un’attività né a tutte le richieste. La documentazione di Anthropic presenta i thread come particolarmente utili nelle sessioni lunghe e attive, in cui si accumulano risultati degli strumenti, modifiche ai file o altri dati che prima venivano trasmessi di nuovo.
Il miglioramento non riduce il costo dei token
Anthropic mantiene la normale fatturazione perché Claude continua a elaborare l’intera cronologia a ogni turno. Restano in vigore anche le tariffe standard dei token e i limiti di utilizzo esistenti. Message threads riduce le dimensioni delle richieste successive e il lavoro di convalida e tokenizzazione dei dati che tornano a raggiungere l’API, ma non esclude quel contesto dall’elaborazione del modello.
L’azienda sottolinea che i thread possono essere combinati con il prompt caching, la sua funzione di cache dei prompt. Sono meccanismi distinti: i thread evitano di ritrasmettere i messaggi precedenti dal client; la cache consente di riutilizzare contenuti già elaborati e può applicare tariffe ridotte alle letture dalla cache. Anthropic indica che i due meccanismi possono funzionare contemporaneamente, ma l’attivazione di un thread non attiva di per sé la cache.
Gli agenti che inviano ripetutamente file di grandi dimensioni potrebbero notare una differenza particolarmente evidente nei dati trasmessi. Guillaume Lebedel, cofondatore e CTO di StackOne, ha calcolato in una simulazione il possibile effetto per gli agenti che utilizzano il computer. Il suo esempio ipotizza che l’agente acquisisca un’immagine da 150 KB a ogni passaggio: alla richiesta numero 50, il metodo precedente avrebbe accumulato circa 7,5 MB di schermate, rispetto a circa 0,15 MB inviando solo l’ultima.
«La mia scommessa: gli agenti che utilizzano il computer lo adotteranno prima degli agenti di programmazione, perché una schermata per passaggio è ciò che rende pesante la ritrasmissione».
— Guillaume Lebedel, cofondatore e CTO di StackOne
Nello stesso esempio, Lebedel stima che la quantità totale di schermate trasmesse nell’arco di 50 passaggi scenderebbe da circa 191 MB a 7,5 MB, ovvero circa 25 volte in meno. Si tratta di calcoli basati su una simulazione, non su una prova dell’API in funzione. Lebedel ha previsto che gli agenti che utilizzano il computer potrebbero favorire l’adozione della funzione prima della fine dell’anno.
Un thread può scadere dopo cinque minuti
La beta ha un breve limite di inattività: non è più possibile continuare il thread dopo cinque minuti di inattività. Ogni risposta memorizzata dall’API azzera il timer. Se l’applicazione tenta di continuare un thread non più disponibile, l’API restituisce un errore 404; il client deve inviare di nuovo l’intera conversazione e creare un altro thread.
Questo non significa necessariamente che l’utente perda il contesto. Anthropic raccomanda che l’applicazione conservi una propria copia di tutti i messaggi, perché la cronologia salvata temporaneamente sul server non sostituisce il registro locale. L’helper per i thread del suo SDK può inviare di nuovo automaticamente la conversazione quando necessario. In un’integrazione personalizzata, lo sviluppatore deve gestire la scadenza e il ripristino.
Anthropic specifica inoltre che il contenuto dei thread viene mantenuto crittografato nella memoria del server e non viene scritto nell’archiviazione persistente. Anche se la possibilità di continuare il thread scade dopo cinque minuti, i dati possono rimanere in memoria fino a un’ora dall’ultimo utilizzo. La documentazione precisa che il server può eliminare il thread entro tale limite massimo.
La funzione non soddisfa i requisiti di zero data retention né quelli HIPAA. Di conseguenza, tali limiti sul trattamento dei dati possono impedirne l’utilizzo in determinati ambienti. Anthropic segnala inoltre che alcune funzionalità di gestione del contesto, inclusa la compattazione su richiesta, non sono supportate.
Come si attiva nella Messages API
L’API aggiunge il parametro thread. Nella prima richiesta si usa thread: {"type": "create"} insieme alla cronologia completa, alle istruzioni di sistema e agli strumenti. Nelle richieste successive si inviano i nuovi messaggi e thread: {"type": "continue", "previous_message_id": "..."}, con l’identificatore della risposta precedente.
Quando si continua un thread, le istruzioni di sistema e gli strumenti non vengono inviati di nuovo: vengono mantenuti quelli della richiesta che lo ha creato. Le richieste dirette devono includere anche l’intestazione beta message-threads-2026-08-12. L’SDK di Python offre un helper che gestisce l’avvio, la continuazione e tale intestazione. L’helper conserva una copia della conversazione in memoria finché l’oggetto esiste; se l’applicazione deve mantenere la cronologia dopo un riavvio, deve salvarla autonomamente.
La documentazione impone altre condizioni per le integrazioni dirette. Il thread consente solo aggiunte e ogni identificatore di risposta può essere continuato una sola volta; è necessario usare l’ID più recente. Per modificare un turno precedente o aprire un ramo, si crea un altro thread a partire dalla copia locale. Se non è più possibile continuare, l’applicazione deve riprodurre l’intera cronologia in una nuova richiesta di creazione.
La funzione è disponibile in beta pubblica per tutti i modelli Claude e può essere utilizzata su Claude Platform, Claude Platform su AWS, Claude su Microsoft Foundry e i modelli Claude gestiti da Anthropic su Google Cloud. Anthropic non ha annunciato in questi materiali una data di uscita dalla beta.
Fonti: The New Stack, The Decoder, Claude, Claude Platform Docs, TNW | Anthropic, TechRounder, Times of AI
