Anthropic lance les fils de messages pour réduire la latence des agents

TThéa

Anthropic a lancé lundi les fils de messages en bêta publique pour sa Messages API sur Claude Platform, d’après Unite.AI. Le principe est simple : l’application envoie la conversation complète lors de la première requête, puis peut transmettre uniquement les nouveaux messages pour les suivantes. Elle rattache ces nouveautés à l’identifiant de la réponse précédente, ce qui permet au serveur de retrouver l’état antérieur du fil. Dans le fonctionnement habituel d’une application qui renvoie son historique, les messages précédents et les résultats d’outils peuvent ainsi être retransmis à chaque étape. C’est particulièrement visible dans une longue session, où le contexte s’enrichit tour après tour avec des réponses, des documents ou des informations produites par des outils. Avec les fils, le client évite de renvoyer tout cet historique à chacune de ses requêtes. Cela change le volume de données qui circule entre l’application et le serveur, mais pas le contenu de la conversation que Claude doit traiter. La fonctionnalité vise donc à réduire le travail d’envoi préalable à la génération, plutôt qu’à modifier la manière dont le modèle comprend l’historique. Pour l’utilisateur, l’effet recherché est une réponse qui commence plus rapidement dans certaines sessions longues et actives, pas une conversation différente.

TThéa

La première requête contient l’historique complet et ouvre le fil ; la réponse renvoie un identifiant que l’application peut conserver. Aux tours suivants, le client transmet les nouveaux messages et cet identifiant, plutôt que de réexpédier toute la conversation. Le serveur conserve temporairement l’état nécessaire pour reconstituer le contexte, et le fil expire après 5 minutes sans nouvelle requête. AlphaSignal rapporte des tests dans Claude Code sur des requêtes de 500 000 à 1 million de jetons : le temps médian avant le premier jeton aurait diminué de 35 %. Dans ces mêmes résultats, la taille médiane des requêtes serait passée d’environ 800 kilo-octets à 1,8 kilo-octet. Ces chiffres concernent le temps d’envoi et le volume transmis par le client ; ils ne signifient pas que Claude traite moins de contenu. La réduction du délai peut compter lorsque l’agent enchaîne des demandes rapprochées, parce qu’il y a moins de données à préparer et à transmettre avant que la génération commence. Mais ces mesures rapportées ne permettent pas de conclure que chaque application connaîtra le même gain. Le résultat dépend du type de session et de la taille des requêtes, et il porte ici sur des tests associés à Claude Code. Alors, il faut distinguer une baisse de latence observée dans ces essais d’une promesse générale sur toutes les utilisations de l’interface.

TThéa

La fonction vise notamment les agents de programmation qui travaillent longtemps, les agents qui utilisent un ordinateur, et les tâches riches en documents ou en images. Dans une session de programmation, l’application peut accumuler au fil des échanges des messages et des résultats d’outils ; les requêtes peuvent alors grossir si tout l’historique est renvoyé à chaque tour. Les fils permettent au client de n’envoyer que les nouveaux éléments, tandis que le serveur conserve temporairement le contexte nécessaire. Pour un agent d’utilisation d’ordinateur, les captures d’écran peuvent rester associées au fil. Cela peut éviter de retransmettre les éléments déjà envoyés pendant la session, mais ne signifie pas que le modèle cesse de traiter les informations du contexte complet. Les flux qui comprennent des documents ou des images sont également mentionnés parmi les usages visés, car ils peuvent accumuler un volume important d’éléments au fil des interactions. En pratique, l’intérêt potentiel est plus net lorsque les requêtes se répètent et que les données envoyées deviennent volumineuses. Si une conversation est courte ou si l’application ne réutilise pas un contexte important, la fonction répond moins directement au problème de retransmission d’un long historique. Anthropic indique que les fils sont activés par défaut pour la plupart des utilisateurs de Claude Code. Cette disponibilité par défaut concerne cet outil, et ne signifie pas que toutes les applications ou tous les utilisateurs disposent nécessairement du même réglage.

TThéa

Non, la baisse du volume transmis ne réduit pas le nombre de jetons d’entrée traités ni leur coût, précise Anthropic. Claude traite toujours la conversation complète à chaque tour, même si le client n’envoie au serveur que les nouveaux messages. Les résultats annoncés portent donc sur la taille des requêtes et le temps avant le début de la réponse, pas sur une baisse du tarif des jetons. Cette distinction est importante : le fil change la quantité de données que l’application doit retransmettre, mais pas la quantité de contexte que le modèle prend en compte pour répondre. AlphaSignal indique que la fonctionnalité est aussi disponible sur AWS, Microsoft Foundry et Google Cloud, aux tarifs habituels des jetons. L’information porte sur la disponibilité et la tarification de ces plateformes ; elle ne permet pas de déduire que les économies de réseau se traduisent en économies de calcul. Pour les équipes qui déploient des agents, le bénéfice recherché se situe donc dans la transmission des requêtes et le délai associé, tandis que les coûts liés aux jetons d’entrée restent inchangés selon Anthropic. Bon, il s’agit d’une optimisation du trajet entre le client et le service, et non d’une réduction de la quantité de texte que Claude analyse. Les deux mesures peuvent évoluer différemment : un message peut être plus léger à envoyer sans devenir moins coûteux à traiter par le modèle.

TThéa

La limite clairement indiquée est la durée de vie du fil : il expire 5 minutes après la dernière requête. Une application qui souhaite reprendre une conversation après cette période ne peut donc pas compter sur cet état temporaire côté serveur comme sur une mémoire conservée durablement. AlphaSignal indique que les applications doivent garder leur propre historique de référence pour pouvoir repartir après l’expiration. Si le fil n’est plus actif, le client doit alors renvoyer la conversation complète pour en établir un nouveau, plutôt que de se contenter des seuls messages récents. Cela ajoute une responsabilité de gestion côté développeur : conserver l’historique utile et savoir quand le fil a expiré. La durée de 5 minutes décrit l’état du fil côté serveur ; elle ne dit pas que l’application cliente doit effacer sa propre copie de la conversation. La documentation de l’API et le comportement de l’application restent donc importants pour assurer la reprise des échanges. Cette fonction convient surtout aux séquences d’interactions rapprochées, où le fil peut être réutilisé avant son expiration. Pour des pauses plus longues, il faut prévoir la reconstitution du contexte depuis l’historique conservé par l’application. Et cette limite rappelle qu’il ne s’agit pas d’une mémoire de long terme : c’est un moyen de réduire les retransmissions pendant une session active, sous réserve que le client gère correctement la continuité.

TThéa

À retenir, Anthropic permet aux applications qui utilisent sa Messages API d’envoyer la conversation complète au départ, puis seulement les nouveaux messages tant que le fil reste actif. L’approche cible surtout les agents de programmation, les agents d’utilisation d’ordinateur et les tâches riches en documents ou en images, lorsque les échanges s’allongent. Dans les tests rapportés par AlphaSignal sur Claude Code, le temps médian avant le premier jeton aurait baissé de 35 %, tandis que la taille médiane des requêtes serait passée d’environ 800 kilo-octets à 1,8 kilo-octet. Ce sont des résultats de tests rapportés, pas une garantie de gain identique pour toutes les applications. Le modèle traite toujours l’historique complet à chaque tour, et Anthropic indique que le nombre et le coût des jetons d’entrée ne diminuent pas. Le fil conserve temporairement l’état côté serveur, avec une expiration après 5 minutes sans nouvelle requête ; l’application doit donc pouvoir garder et renvoyer son propre historique si nécessaire. L’avantage est précis : moins de données à retransmettre pendant des sessions actives, et potentiellement moins d’attente avant le début de la réponse dans les situations testées. Ce n’est ni une réduction du coût des jetons ni une mémoire permanente pour les agents. Pour les développeurs, la nouveauté est surtout une option de gestion des conversations longues, qui peut alléger les échanges entre chaque étape sans changer le travail demandé à Claude. La bêta publique met ainsi l’accent sur la latence du transport des requêtes, tout en laissant intactes les limites de coût et de conservation annoncées.