Anthropic propose désormais aux développeurs de ne plus renvoyer toute la conversation à Claude à chaque tour. Lancés en bêta publique le 2 novembre 2026, les message threads permettent à une application d'envoyer l'historique une seule fois, puis uniquement les nouveaux messages accompagnés de l'identifiant de la réponse précédente. La fonction vise les longues boucles d'agents : d'après Anthropic, le fait de recharger sans cesse des centaines de milliers de tokens retarde sensiblement le moment où le modèle commence à répondre.
Le chiffre mis en avant provient de l'outil de programmation maison. Anthropic indique que les threads sont déjà activés par défaut pour la plupart des utilisateurs de Claude Code et que, sur les requêtes de 500 000 à 1 million de tokens, le temps médian jusqu'au premier token a baissé d'environ 35 %. Aucun résultat n'a été publié pour les conversations plus courtes ; l'éditeur se contente d'expliquer que le bénéfice croît avec le contexte transporté et cite en priorité les agents de code, les agents qui pilotent un ordinateur et qui renverraient sinon leurs captures d'écran, ainsi que les traitements riches en documents.
Côté mise en œuvre, il suffit d'ajouter un champ thread aux requêtes de l'API Messages et d'envoyer l'en-tête bêta message-threads-2026-08-12. Le premier appel, de type création, contient l'historique complet, le prompt système et les outils. Les suivants, de type continuation, renseignent previous_message_id et doivent omettre prompt système et outils, que le thread garde en mémoire. D'autres réglages, dont le modèle et la configuration du raisonnement, ne peuvent pas varier en cours de route. Les SDK d'Anthropic fournissent un assistant qui construit ces requêtes et gère les relances, et le tool runner en bêta utilise désormais les threads par défaut.
Le gain porte sur ce qui transite par le réseau, pas sur ce que lit le modèle. Claude analyse toujours l'intégralité de l'échange à chaque tour : la consommation de tokens, les tarifs standard et les plafonds d'utilisation ne bougent pas, affirme Anthropic. La documentation précise qu'un thread n'est pas un cache de prompt ; pour éviter de recalculer les tours précédents, il faut toujours placer des points cache_control, dans la limite de quatre par requête. Entre deux tours, chaque thread est conservé en mémoire, chiffré et jamais écrit sur disque, selon l'entreprise.
Ces threads sont volontairement éphémères. Ils expirent cinq minutes après la dernière requête et sont supprimés au plus tard une heure après leur dernière utilisation. Lorsque la reprise devient impossible, l'API renvoie une erreur 404 avec le code thread_not_found, et le client doit renvoyer toute la conversation pour en ouvrir un nouveau ; d'où la consigne de garder sa propre copie de chaque message. Il n'existe aucune API pour lister, lire ou effacer un thread, on ne peut pas le compacter, et les réponses produites par un modèle de secours côté serveur n'y sont pas enregistrées. La documentation exclut aussi la fonction des dispositifs de conservation zéro des données et HIPAA.
La bêta couvre tous les modèles Claude, sur la Claude API, Claude Platform on AWS, Claude in Microsoft Foundry et Claude Models on Google Cloud (géré par Anthropic), et figure dans les notes de version de la plateforme datées du 2 novembre. The Next Web, qui a relayé l'annonce le jour même, a souligné le compromis reconnu par Anthropic : on gagne du temps d'attente, pas de l'argent.
Pour les équipes qui bâtissent des agents sur Claude, l'intérêt est une latence plus faible et plus régulière à mesure que la session s'allonge, sans toucher aux prompts. La contrepartie tient à la gestion d'état : suivre les identifiants de réponse, anticiper expirations et relances, figer les paramètres imposés. Les 35 % annoncés sont une mesure interne réalisée sur une cohorte de Claude Code, pas un banc d'essai indépendant, et l'effet réel dépendra de la taille du contexte, du réglage du cache et de la fréquence à laquelle les threads expirent entre deux tours.