Les flux de messages accélèrent Claude Code de 2 à 4 minutes par session de travail

Une longue session avec un agent de codage n’est pas particulièrement économe : vous ajoutez une courte instruction, puis le client retransmet au serveur tout l’historique accumulé. Lorsque le contexte atteint des centaines de milliers de tokens, ces chargements répétés commencent à peser sur le temps d’attente. Les flux de messages de Claude modifient précisément cette étape : après la première requête, le client n’envoie que les nouvelles données, tandis que l’historique précédent reste associé au flux côté service.

L’effet pratique est perceptible, mais il n’a rien de miraculeux. Anthropic fait état d’une réduction de 35 % du délai médian avant le premier token pour les requêtes comprises entre 500 000 et 1 million de tokens. L’auteur de ZDNET a analysé les journaux d’environ 980 requêtes adressées à Claude Code et estimé le gain qu’aurait apporté le nouveau mécanisme. Le résultat se situe entre deux et quatre minutes sur une session de travail de quatre heures comprenant 100 à 225 appels au modèle.

Où disparaît la latence

Imaginons un agent qui analyse depuis plusieurs heures un vaste dépôt. Son historique contient le code source, les résultats des tests, les réponses des outils et des dizaines de décisions antérieures. Auparavant, une nouvelle instruction telle que « corrige les deux erreurs restantes » pouvait s’accompagner d’une retransmission de l’ensemble de ces données. Désormais, le réseau transporte principalement la nouvelle instruction et les changements intervenus depuis la requête précédente.

Cela réduit le délai avant l’apparition du premier token, mais n’accélère pas le raisonnement du modèle une fois la réponse commencée. La fonction ne rend pas non plus Claude plus intelligent et n’agrandit pas sa fenêtre contextuelle. Elle élimine uniquement le transport répété de contenus déjà connus du serveur. Cette approche est particulièrement utile aux agents qui enchaînent de nombreuses étapes, ainsi qu’aux tâches impliquant des documents, des images et des captures d’écran : les pièces jointes volumineuses n’ont plus à être téléversées à chaque tour.

Il faut également souligner que les 2 à 4 minutes citées ne proviennent pas d’une comparaison directe de sessions identiques avant et après la mise à jour. Il s’agit d’un calcul appliquant aux anciens journaux la réduction de latence annoncée par Anthropic. Cette estimation donne une bonne idée de l’ordre de grandeur du gain, mais ne remplace pas une mesure contrôlée. Le réseau, la région du serveur, la taille du contexte et la nature des appels peuvent sensiblement modifier le résultat.

Plus rapide ne signifie pas moins cher

Les flux de messages réduisent le volume de données retransmises, mais le modèle continue de traiter l’historique complet de la conversation. Le nombre de tokens facturés et les limites de l’API ne changent donc pas. Pour réduire les coûts, il faut recourir à un autre mécanisme : la mise en cache du prompt, qui évite de facturer au tarif normal le retraitement de la partie inchangée du contexte. Les flux et la mise en cache peuvent être utilisés ensemble : les premiers réduisent la latence réseau, la seconde aide à maîtriser les dépenses.

Il existe aussi des limites. Une requête isolée n’en tire presque aucun avantage, puisqu’aucun historique n’a encore besoin d’être retransmis. Selon l’article, après une pause de plus de cinq minutes, le client peut envoyer de nouveau l’intégralité du contenu. Les problèmes habituels des longues sessions ne disparaissent pas non plus : saturation du contexte, compression de l’historique et perte progressive de détails importants par le modèle.

Ce que les développeurs doivent vérifier

Si Claude Code est utilisé pour de courtes séquences de quelques requêtes, le changement peut passer totalement inaperçu. Si l’agent travaille pendant des heures sur un vaste dépôt, appelle constamment des outils ou retransmet des images, le gain résulte de dizaines de petites réductions de latence.

La conclusion pratique est simple : il faut évaluer cette fonction sur la durée totale de la tâche, et non sur le pourcentage mis en avant dans l’annonce. Enregistrez les journaux de plusieurs sessions représentatives, puis mesurez séparément le délai avant le premier token et le temps d’exécution total. Et n’intégrez aucune baisse des coûts à votre modèle financier : les flux accélèrent l’échange de données, mais ne réduisent pas à eux seuls la consommation de tokens.