Les message threads de Claude sont entrés en bêta publique sur la Claude Platform le 2 novembre. Dans son blog officiel, Anthropic explique que les agents de longue durée n'ont plus qu'à envoyer ce qui est nouveau à chaque tour, au lieu de renvoyer tout l'historique de la conversation. Plus le contexte porté par une session est long, plus la baisse du temps d'attente avant que le modèle commence à répondre est nette, et c'est la valeur la plus directe de cette mise à jour.
L'ancien goulot d'étranglement est facile à comprendre : un agent de programmation peut émettre des centaines de requêtes au cours d'une session, et chaque requête devait renvoyer tous les messages et résultats d'outils précédents. Une fois qu'une conversation atteignait des centaines de milliers de tokens, ce renvoi allongeait le temps avant que le modèle commence à répondre. Les message threads ajoutent un paramètre thread aux requêtes. La première requête envoie la conversation complète et ouvre un thread ; chaque requête suivante n'envoie que les nouveaux messages et l'identifiant de la réponse précédente. Entre les tours, le thread est conservé en mémoire, chiffré et non écrit sur disque.
Le délai médian avant le premier token baisse d'environ 35 %, sans changement du mode de comptage
Le chiffre d'Anthropic est une baisse médiane d'environ 35 % du délai avant le premier token (TTFT) pour les requêtes de 500 000 à 1 million de tokens, et les message threads sont déjà activés par défaut pour la plupart des utilisateurs de Claude Code. Claude continue toutefois de lire la conversation complète à chaque tour, de sorte que la consommation de tokens reste la même, et les tarifs standard ainsi que les limites de débit existantes s'appliquent. La bêta publique couvre la Claude Platform native, Claude Platform sur AWS, Claude dans Microsoft Foundry et les modèles Claude sur Google Cloud (gérés par Anthropic). Les développeurs peuvent suivre la documentation pour commencer.
Les threads expirent après 5 minutes d'inactivité, les sessions courtes n'exigent aucun changement particulier
Un thread expire 5 minutes après sa dernière requête, et après expiration, le client doit renvoyer la conversation complète pour en ouvrir un nouveau. La fonction convient le mieux aux sessions qui tournent en continu : les agents de programmation qui ajoutent des résultats d'outils ou des modifications de fichiers à chaque tour, les agents d'utilisation d'ordinateur dont les captures d'écran restent dans le thread au lieu d'être téléversées à nouveau, et les flux de travail riches en documents et en images. Les sessions courtes avec de longues pauses en profitent peu, et une pause de plus de 5 minutes ramène le temps d'attente du premier tour à son niveau antérieur. L'adoption doit dépendre du fait que les sessions sont réellement longues, et non du simple fait qu'il s'agit d'une nouveauté.
