Anthropic réduit d’environ 35 % la latence de Claude dans les longues conversations

Les longues conversations avec Claude présentent une particularité technique peu agréable : l’historique ne cesse de s’allonger et l’application le renvoie intégralement avec chaque nouvelle réplique. Imaginez un agent qui a déjà discuté des exigences avec l’utilisateur, lu plusieurs fichiers et exécuté une dizaine d’actions. Pour lui demander de passer à l’étape suivante, le développeur doit de nouveau transmettre toute la conversation accumulée. Cela augmente la taille de la requête et le délai avant le début de la réponse.

Anthropic propose pour ces scénarios les message threads, des fils de messages disponibles en bêta publique dans l’API. L’historique complet est transmis une seule fois, après quoi l’application n’envoie que les nouveaux messages. L’entreprise affirme que, dans les très longues sessions, cette approche réduit d’environ 35 % l’attente avant la réponse de Claude. Pour le développeur, l’intérêt est simple : il faut retransmettre moins souvent le même contexte, en particulier avec les agents dont la durée de vie dépasse une seule requête.

À quoi cela ressemble en pratique

Supposons qu’un agent aide un développeur à corriger un bug. Il reçoit d’abord la description de la tâche, étudie le code, examine une cause possible et propose des modifications. L’utilisateur écrit ensuite : « Lance les tests et vérifie le résultat. » Dans le schéma classique, l’application peut reconstruire et renvoyer toute la conversation, du premier au dernier message. Avec les message threads, l’échange initial est déjà associé au fil : seule la nouvelle instruction vient donc s’y ajouter.

Cela ne signifie pas que le modèle dispose désormais d’une mémoire infinie ou qu’il n’est plus soumis à la fenêtre de contexte. Il s’agit avant tout d’une nouvelle méthode de transmission et de stockage de la séquence des messages côté API. Pour un chatbot limité à deux répliques, la différence peut passer inaperçue. En revanche, pour un agent de recherche, un assistant de programmation ou un assistant interne d’entreprise engagé dans une longue session de travail, le gain peut déjà modifier la perception de la rapidité du produit.

Où se situe l’avantage, et où commence le marketing

Les 35 % annoncés concernent le temps d’attente avant la réponse dans les très longues sessions, et non une accélération d’un tiers de chaque appel à Claude. Anthropic ne promet pas un tel résultat pour les conversations courtes. Il ne faut donc pas extrapoler ce chiffre à l’ensemble du produit : l’effet doit être mesuré dans vos propres scénarios, avec la longueur réelle de l’historique, les outils utilisés et la nature des requêtes.

Les prix et les limites de l’API restent inchangés au lancement de la fonctionnalité. Les message threads ne doivent donc pas être considérés comme une remise automatique. Même si l’application transmet moins de données répétées, la description publiée ne permet pas de conclure que la facture liée au traitement du contexte diminuera nécessairement. Pour l’heure, le principal avantage annoncé concerne la latence, pas le coût.

La bêta publique ne supprime pas non plus les questions opérationnelles. L’équipe doit déterminer combien de temps un fil subsiste, ce qui se passe lorsque l’historique associé devient indisponible, comment restaurer une conversation après une panne et comment éviter de mélanger les contextes de différents utilisateurs. Pour les données sensibles, les règles de conservation, de suppression et de journalisation sont particulièrement importantes. Il est risqué de considérer l’identifiant du fil comme l’unique source d’état tant que le comportement de la fonctionnalité n’a pas été vérifié sous une charge réelle.

Ce que les développeurs doivent faire

Mieux vaut commencer par une expérience limitée plutôt que migrer tout le produit. Choisissez un scénario véritablement long, par exemple un agent chargé de travailler sur du code, puis comparez la transmission classique de l’historique avec les message threads. Mesurez le délai jusqu’au premier fragment de réponse, la durée totale de la requête, la fréquence des erreurs et la qualité de conservation du contexte. Testez séparément les nouvelles tentatives, les messages parallèles et la restauration après l’interruption d’une session.

Si la latence diminue nettement sans créer de nouveaux problèmes d’état, la fonctionnalité pourra être progressivement étendue à d’autres processus agentiques. Si vos conversations sont courtes, il n’est pas nécessaire de modifier l’architecture dans l’urgence. Les message threads répondent à un problème précis des longues sessions : ils éliminent la retransmission permanente d’une conversation déjà connue. C’est une amélioration d’infrastructure utile, mais sa valeur dépend non pas d’un chiffre séduisant, mais des mesures réalisées au sein de votre produit.