Un agent chargé d’examiner une transformation SQL accumule le schéma, les requêtes, les résultats d’outils et ses premières analyses. À chaque étape, son application renvoie souvent toute cette conversation à l’API. Même si le nouveau résultat ne tient qu’en quelques lignes, l’envoi reprend aussi le contexte déjà transmis.
Le 2 novembre 2026, Anthropic a annoncé message threads, une bêta de l’API Messages qui permet d’envoyer seulement les nouveaux messages après un premier envoi complet. Le serveur reconstitue le contexte avant l’appel au modèle. L’objectif est de réduire le délai avant le premier token, particulièrement dans les conversations longues. Claude continue cependant de lire la conversation complète : le mécanisme ne réduit pas à lui seul les tokens utilisés. Annonce officielle.
Pour une équipe data, la question utile est donc précise : l’attente vient-elle de la transmission et de la préparation d’un historique croissant, ou du raisonnement et des outils ? Cette analyse documentaire explique le contrat et propose un premier essai contrôlé. Nous n’avons pas appelé cette bêta ni mesuré son gain sur un agent réel.
Ce qui change dans une conversation d’agent
Considérons un scénario fictif : un assistant examine les ventes par magasin. Une requête joint orders, qui porte un montant par commande, à order_lines, qui contient plusieurs lignes par commande. La question est précise : cette jointure multiplie-t-elle le montant avant son agrégation ? L’assistant reçoit le SQL et la règle métier, demande le schéma des deux tables, puis le résultat d’un contrôle du nombre de lignes par commande. Le développeur conserve déjà ces échanges pour pouvoir reprendre l’analyse.
Sans thread, chaque requête transmet de nouveau cet historique. Avec un thread actif, les étapes suivantes peuvent transmettre les ajouts et une référence à la réponse précédente. Le modèle reçoit toujours le contexte reconstitué. On change le transport et une partie de la préparation de la requête, pas le problème métier soumis à Claude.
Cette différence explique deux décisions d’intégration. D’abord, un résultat d’outil très court peut être intéressant à envoyer seul si l’historique est volumineux. Ensuite, une réponse lente parce qu’elle lance une requête SQL coûteuse ne devient pas automatiquement rapide : le temps de l’outil reste à diagnostiquer séparément.
Anthropic rapporte une amélioration médiane du délai au premier token dans certaines longues requêtes Claude Code. Ce résultat fournisseur ne mesure ni votre réseau, ni vos documents, ni la durée totale de votre agent. Nous ne le transposons pas au cas SQL présenté ici.
Suivre trois étapes sur le même dossier SQL
Le contrat repose sur une création, une continuation, puis une éventuelle reconstruction. Les deux extraits suivants montrent seulement les champs thread ; ils ne constituent pas des requêtes complètes à exécuter.
{ "thread": { "type": "create" } }
Le premier appel porte la conversation complète et les paramètres initiaux. Imaginons une réponse identifiée msg_A après la première analyse du SQL.
{ "thread": { "type": "continue", "previous_message_id": "msg_A" } }
Le deuxième appel ajoute le schéma demandé. Il ne réexpédie pas la réponse msg_A. La nouvelle réponse, par exemple msg_B, devient la référence pour le prochain tour. Le client garde les échanges complets dans son propre journal. Le troisième tour apporte le contrôle de cardinalité : Claude doit encore relier ce résultat au SQL initial et à la règle « un montant par commande ». Le thread ne vérifie pas la jointure à sa place.
| Étape du scénario |
Envoi quand le thread est actif |
Ce que le client doit encore conserver |
| SQL et règles métier |
Historique initial et création |
Messages initiaux, paramètres et réponse A |
| Schéma demandé |
Nouveaux messages et référence A |
Schéma et réponse B, ajoutés au journal |
| Résultat du contrôle SQL |
Nouveaux messages et référence B |
Résultat et réponse C, ajoutés au journal |
La référence doit avancer avec la conversation. Elle ne sert pas à ouvrir plusieurs branches concurrentes du même état. Si deux analyses doivent diverger, par exemple tester deux hypothèses de jointure, il faut préparer deux conversations cohérentes plutôt que partager aveuglément le même dernier identifiant.
Le détail des champs et des erreurs est versionné dans la documentation message threads. Le header de bêta est message-threads-2026-08-12 : sa date n’est pas la date de l’annonce publique du 2 novembre.
Garder le journal local, y compris pour une reprise
Le thread est une optimisation temporaire. Le client ne doit pas devenir incapable de poursuivre lorsque sa référence serveur disparaît. Il doit conserver les messages utilisateurs, les réponses et les résultats d’outils qui constituent la conversation réelle.
Dans notre scénario, le contrôle SQL peut prendre du temps ou attendre une validation humaine. Au retour, l’application doit pouvoir reconstruire exactement le dossier : SQL initial, règles, échanges précédents et résultat nouvellement obtenu. Conserver seulement msg_B et la dernière question serait insuffisant.
Le helper des SDK officiels gère une partie de cette reprise. Son historique en mémoire ne remplace toutefois pas une conservation adaptée à une application qui redémarre. Le code du SDK Python consulté est une référence à rapprocher de la version réellement installée, et non une raison de supposer que tout ancien client possède ce helper.
L’effort principal de migration se situe ici : identifier qui possède le journal et qui décide de l’état suivant. Un agent déjà bien structuré peut changer son envoi sans réécrire ses outils. Un client qui ne conserve pas ses réponses doit d’abord corriger cette dépendance à l’état distant.
Distinguer expiration, suppression et conservation applicative
Les notes de version indiquent une expiration après cinq minutes depuis la dernière requête et une suppression au plus tard une heure après le dernier usage. Ce sont deux durées différentes. Le thread ne constitue donc pas une mémoire durable entre une réunion du matin et une reprise le lendemain. Notes de version du 2 novembre.
Pour un essai, interrompez volontairement le scénario après le deuxième tour. Vérifiez que votre client sait revenir à une création complète quand le serveur ne peut plus continuer le thread. Deux erreurs demandent des corrections différentes :
Signal dans error.details.error_code |
Décision d’intégration |
thread_not_found avec HTTP 404 |
Reconstruire avec le journal complet, le nouveau résultat, system et tools, dans une nouvelle création. Ce code ne prouve pas à lui seul une expiration. |
thread_fingerprint_mismatch avec HTTP 400 |
Un paramètre fixe diffère. Conserver sa valeur initiale ou recréer le thread si le changement est voulu. |
Un modèle inexistant peut aussi produire un 404. Ne déclenchez donc pas une reconstruction sur ce seul statut. En streaming, attendez également message_stop avant de continuer depuis l’identifiant reçu : sa présence au début du flux ne prouve pas que la réponse est terminée.
Les documents de traitement des données marquent cette fonctionnalité non éligible à la conservation nulle des données (ZDR) ni au dispositif HIPAA. Une conservation en mémoire chiffrée côté fournisseur ne doit pas être assimilée à votre propre politique de conservation ni à une garantie de résidence en France. Le journal de votre application possède également son propre cycle de vie. API et conservation des données.
Un premier essai peut donc utiliser un SQL et un schéma fictifs. Cela permet d’examiner les requêtes et la reprise sans ajouter des données client au dossier de test. La compatibilité avec les règles de l’organisation reste à établir avant un usage réel.
Le prompt caching répond à une autre question
Un thread évite de retransmettre l’historique à chaque tour. Le prompt caching vise la réutilisation de préfixes du contexte et possède ses propres règles de lecture, d’écriture et de tarification. Activer l’un ne revient pas à activer l’autre. Documentation du prompt caching.
Pour évaluer le transport, gardez donc la même politique de cache dans les deux variantes. Sinon, vous changez simultanément deux mécanismes et ne savez plus ce qui explique le résultat.
Les tarifs standard des tokens et les limites de débit restent applicables aux threads. Le nom de la fonctionnalité ne justifie pas une estimation d’économie. Pour suivre les dépenses réelles, distinguez tokens d’entrée, lectures et écritures du cache, tokens de sortie et reprises. Le guide de l’API de coûts Claude traite la collecte et le rapprochement de ces mesures.
Vérifier l’accès avant de modifier son client
La bêta est documentée sur l’API Claude native, Claude Platform on AWS, Claude Models on Google Cloud géré par Anthropic et Microsoft Foundry. Ces appellations ne désignent pas toutes les offres portant les noms AWS ou Google : vérifiez votre point d’accès exact. Un abonnement Claude grand public ne suffit pas à décrire votre configuration API. Disponibilité annoncée.
Le protocole conserve aussi des contraintes. Sur une continuation, omettez system et tools : les renvoyer, même à null, provoque une erreur. Le modèle, tool_choice, thinking et le format de sortie font notamment partie des champs fixes. Une modification voulue impose une nouvelle création. De même, remplacer les anciens échanges par un résumé demande un nouveau thread ; l’historique existant ne se réécrit pas.
Pour le premier essai, choisissez une configuration minimale déjà utilisée par l’équipe. Écartez temporairement les variantes avancées que le dossier n’a pas encore qualifiées. Cela rend un refus du serveur plus facile à expliquer qu’un test mêlant plusieurs nouveautés.
Un protocole de mesure avant généralisation
La fiche d’essai téléchargeable organise le cas SQL en deux variantes : historique complet à chaque tour, puis thread. Elle ne contient aucun résultat prétendument obtenu chez Nymphar.
Gardez identiques le modèle, les messages, les outils, le cache et les paramètres de génération. Mesurez séparément :
- La taille du corps envoyé, pour vérifier que les tours suivants transportent réellement moins de données.
- Le délai au premier token, avec les mêmes points de départ et d’arrivée dans le client.
- La durée totale, pour voir si l’attente des outils domine encore le parcours.
- L’usage et le coût, pour contrôler séparément les effets du cache et des reprises.
- La cohérence de la conversation, notamment après une interruption ou une reconstruction.
Répétez les essais sur plusieurs tailles d’historique et distinguez les créations des continuations. Une moyenne qui mélange les reprises complètes avec les tours actifs peut masquer le comportement qui vous intéresse. Conservez aussi les erreurs : une variante qui démarre vite mais perd le contexte ne remplit pas la même tâche.
Les threads méritent donc un essai lorsque l’agent enchaîne rapidement des tours avec un contexte croissant et que l’attente avant réponse est un problème observé. Pour un traitement isolé, une tâche qui attend longtemps entre deux étapes ou un contexte déjà réduit, mesurez d’abord ce qui coûte du temps. Le bon critère est une tâche achevée plus utilement, avec une reprise fiable, pas la seule présence d’un nouvel identifiant de conversation.
