Anthropic accélère de 35 % les réponses de Claude dans les longues conversations

Une longue conversation avec un modèle n'est pas conçue de manière très élégante : avant chaque nouvelle réponse, l'application renvoie tout l'échange. Tant que l'historique ne compte que quelques messages, cela passe presque inaperçu. Mais lorsqu'un agent analyse un dépôt pendant des heures, pilote un ordinateur ou lit des centaines de documents, la retransmission du contexte devient une source de latence à part entière.

Anthropic propose Message Threads pour ces scénarios. La fonction est passée en bêta publique sur la plateforme Claude et, selon l'entreprise, réduit d'environ 35 % le temps avant l'apparition du premier token pour les requêtes dont le contexte va de 500 000 à un million de tokens.

Ce qui change dans la requête

Imaginons un agent qui a déjà chargé un gros projet : code source, documentation, résultats de tests et historique de ses propres actions. Le développeur écrit alors un court message : « Corrige l'erreur trouvée et relance les tests ».

Avec le schéma habituel, le client retransmet à Claude toute la conversation accumulée, avec ce message. Message Threads permet de n'envoyer que ce qui a changé depuis la requête précédente. Le modèle reçoit malgré tout l'historique complet, mais la couche de transport n'a plus à refaire transiter des centaines de milliers de tokens par le réseau.

C'est pourquoi Anthropic parle d'une accélération du temps jusqu'au premier token, et non d'une réduction du volume de contexte. L'utilisateur voit le début de la réponse plus tôt, mais le modèle continue de lire tout le dialogue et d'en tenir compte lors de la génération.

Où l'effet sera notable

Les principaux candidats sont les agents de longue durée. Un agent de code accumule peu à peu des fichiers, des messages du compilateur et des résultats de tests. Un agent d'interface conserve une séquence de captures d'écran et d'actions effectuées. Un système d'analyse de documents peut garder en contexte des rapports, des tableaux et des images. Dans tous ces cas, la nouvelle commande est minime comparée à l'historique déjà constitué.

Pour un chatbot ordinaire échangeant une dizaine de courtes répliques, la différence sera probablement plus modeste. Les 35 % annoncés concernent de très grosses requêtes, à partir de 500 000 tokens. On ne peut pas extrapoler ce chiffre à n'importe quelle conversation : le gain réel dépend de la taille de l'historique, du réseau, de la région, du modèle et du reste de l'infrastructure de l'application.

Il existe aussi une limite importante. Message Threads ne réduit pas la consommation de tokens : Claude traite toujours le contexte complet. La fonction améliore donc la latence de transfert des données, mais ne résout pas le problème du coût des longues conversations. Si la tâche exige des économies, les développeurs devront encore raccourcir l'historique, produire des résumés, déporter les données vers un stockage externe ou sélectionner plus précisément le contexte à chaque étape.

Que vérifier avant le déploiement

Le fil est conservé entre les requêtes dans une mémoire vive chiffrée et supprimé après cinq minutes d'inactivité. Pour un agent interactif, cela peut suffire, mais un processus en arrière-plan avec de longues pauses doit pouvoir restaurer son état ou retransmettre l'historique. L'identifiant du fil ne doit pas être considéré comme un stockage permanent de session.

La fonction est disponible sur la plateforme Claude, ainsi que via AWS, Microsoft Foundry et Google Cloud. Tant qu'elle reste en bêta publique, il est judicieux de l'activer progressivement : mesurer le temps jusqu'au premier token sur vos propres traces, vérifier le comportement après l'expiration des cinq minutes et prévoir un retour aux requêtes classiques.

La conclusion pratique est simple : si votre agent renvoie en permanence des centaines de milliers de tokens d'un contexte presque inchangé, Message Threads mérite d'être testé. Elle ne rendra pas le modèle moins cher et n'améliorera pas la qualité du raisonnement, mais elle peut supprimer une part notable de l'attente là où l'historique est devenu plus lourd que le nouveau message.