The Pulse
Anthropic aggiunge thread lato server per i cicli degli agenti
Il 2 novembre Anthropic ha annunciato la versione beta dei thread di messaggi per la Messages API, che consentono agli sviluppatori di conservare una conversazione sul server e inviare solo i nuovi messaggi nei turni successivi. I thread sc
AI.info Team · Scritto con l’IA · verificato ·
Il 2 novembre Anthropic ha annunciato la versione beta dei thread di messaggi per la Messages API. La funzionalità conserva una conversazione sul server, così che le richieste successive inviino solo i messaggi aggiunti dopo l’ultima risposta. Secondo Anthropic, questo può ridurre le dimensioni delle richieste e il tempo al primo token nelle conversazioni lunghe e nei cicli degli agenti.
Creare e continuare un thread
Un thread inizia con una richiesta che contiene l’intera conversazione, insieme al prompt di sistema e agli strumenti. La richiesta aggiunge thread: {"type": "create"}; l’API memorizza la conversazione, compresa la risposta di Claude, associandola all’ID della risposta. Per continuare, l’applicazione invia solo i messaggi aggiunti dopo quella risposta e la identifica con thread: {"type": "continue", "previous_message_id": "..."}.
In una richiesta di continuazione, l’applicazione omette il prompt di sistema e gli strumenti, che restano associati al thread. L’intestazione beta message-threads-2026-08-12 deve accompagnare ogni richiesta nel thread. L’helper per i thread dell’SDK di Anthropic può aggiungere l’intestazione, creare il thread al primo turno e inviare solo i nuovi messaggi nei turni successivi. Gli sviluppatori possono anche costruire le richieste autonomamente.
Scadenza e recupero
Un thread scade cinque minuti dopo la sua ultima richiesta. L’API lo elimina entro un’ora dall’ultimo utilizzo. Ogni risposta memorizzata fa ripartire l’intervallo di cinque minuti. Se una richiesta di continuazione non può procedere perché il thread non è disponibile, restituisce un errore 404; la procedura di recupero indicata nella documentazione consiste nell’inviare nuovamente l’intera conversazione in un nuovo thread.
Secondo Anthropic, l’applicazione dovrebbe conservare una propria copia di ogni messaggio e predisporre fin dall’inizio una procedura per riproporre la conversazione. L’API non indica nella risposta se ha memorizzato quel turno, quindi l’applicazione scopre solo con una successiva richiesta di continuazione se il thread può essere continuato. L’helper dell’SDK conserva la conversazione in memoria finché esiste il relativo oggetto helper, ma non la salva altrove.
Regole e limitazioni delle richieste
Alcuni campi della richiesta devono rimanere coerenti tra un turno e l’altro. Il modello, la scelta degli strumenti, le impostazioni di ragionamento e gli altri campi fissi elencati devono corrispondere ai valori usati per creare il thread; la modifica di un valore può causare un errore 400. I prompt di sistema e gli strumenti vengono inviati solo al momento della creazione di un thread. Altri campi, tra cui il numero massimo di token in output, le sequenze di arresto, lo streaming e i metadati, possono cambiare tra un turno e l’altro.
Nei thread è possibile solo aggiungere messaggi e ogni ID di risposta può essere usato una sola volta per continuare la conversazione. Per modificare un messaggio precedente o creare una diramazione a partire da esso, gli sviluppatori devono avviare un nuovo thread. I thread non supportano Message Batches, il conteggio dei token o la compattazione delle conversazioni e non sono disponibili per le organizzazioni che hanno abilitato la predisposizione per HIPAA o attivato gli hook di inferenza. La documentazione precisa inoltre che i thread non sono idonei alla conservazione zero dei dati né a HIPAA.
Disponibilità e benefici dichiarati
La versione beta è indicata come disponibile per Claude API, Claude Platform on AWS, Claude Models on Google Cloud (Anthropic managed) e Claude in Microsoft Foundry. Secondo Anthropic, i thread possono ridurre le dimensioni delle richieste successive e mantenere il tempo al primo token più basso e più stabile man mano che una conversazione si allunga. La documentazione spiega che, senza un thread, a ogni turno l’intera conversazione viene caricata ed elaborata di nuovo; con un thread, la maggior parte di questo lavoro riguarda solo il nuovo turno. Non viene fornita una misura numerica del miglioramento della latenza.