Quand on discute avec un agent IA pendant des heures, il se passe un truc un peu absurde en coulisses : à chaque tour, l'application renvoie toute la conversation depuis le début. Le prompt système, les outils, les centaines de messages précédents. Un peu comme si vous deviez relire tout un roman à voix haute avant d'ajouter une phrase. Le 2 novembre 2026, Anthropic a ouvert une bêta publique pour mettre fin à ce rituel. Cela s'appelle les message threads.
Ce qui change concrètement
Jusqu'ici, sur la Messages API de Claude, un agent devait envoyer l'historique complet à chaque requête : le prompt système, la liste des outils et tous les messages échangés. Désormais, le fonctionnement se fait en deux temps.
- La première requête envoie la conversation entière, avec le paramètre
thread. L'API la stocke côté serveur, sous l'ID de la réponse. - Les requêtes suivantes n'envoient que les nouveaux messages et l'ID de la réponse précédente. Plus besoin de répéter
systemnitools.
Pour vos propres agents, il faut donc ajouter le paramètre thread et l'en-tête bêta correspondant. Claude Code, lui, l'a déjà activé par défaut pour la plupart de ses utilisateurs. La fonction marche avec tous les modèles Claude, sur la plateforme Anthropic, AWS, Microsoft Foundry et Google Cloud.
Un gain de vitesse, pas d'économies
Attention à ne pas confondre. Le gain porte sur la latence, c'est-à-dire le temps d'attente avant que la première réponse n'arrive. Anthropic annonce environ 35 % de moins, sur des requêtes de 500 000 à 1 million de tokens (un token, c'est un morceau de mot, l'unité avec laquelle l'IA lit et compte le texte).
À garder en tête : ce chiffre vient des mesures internes d'Anthropic. À ce jour, aucun test indépendant ne l'a confirmé.
Côté facture, rien ne bouge. Claude voit toujours toute la conversation à chaque tour : les tokens sont donc facturés comme avant, et les tarifs comme les limites de débit restent identiques. Le gain sera surtout visible sur les longues sessions : agents de code, agents de recherche, workflows autonomes qui tournent pendant des heures. Sur des échanges courts, il sera faible.
Les contraintes à connaître
Le stockage côté serveur a ses règles, et elles comptent.
| Point | Ce qu'il faut savoir |
|---|---|
| Stockage | En mémoire, chiffré, jamais écrit sur disque |
| Durée de vie | Le thread expire 5 minutes après la dernière requête |
| Récupération | Impossible de relire l'historique via l'API |
| Conformité | Incompatible avec la rétention zéro des données (ZDR) et avec HIPAA |
Conséquence directe : votre application doit garder sa propre copie de la conversation et prévoir un mécanisme de rejeu. Autrement dit, si le thread a expiré, il faut être capable de renvoyer l'historique complet pour repartir. Et pour les clients en secteur réglementé, l'incompatibilité avec le ZDR et HIPAA peut tout simplement fermer la porte.
Notre point de vue
Voilà une amélioration utile, sans effet de manche. Elle ne rend pas Claude plus intelligent, ne baisse pas la facture, et personne ne prétend le contraire. Elle supprime simplement un gaspillage de transport. Sur un agent qui travaille pendant des heures, 35 % d'attente en moins avant la première réponse, c'est le genre de gain qu'on sent au quotidien, si le chiffre se confirme en conditions réelles.
Le piège, c'est le délai de 5 minutes. Un agent qui attend une validation humaine, un appel externe un peu long ou une file d'attente peut très bien dépasser ce délai. Sans logique de rejeu solide, le workflow plante ou repart de zéro. La fonction est donc un accélérateur, pas un point de stockage : la mémoire de référence reste chez vous.
Ce mouvement dépasse d'ailleurs Anthropic. OpenAI propose déjà une logique de conversation côté serveur avec previous_response_id dans sa Responses API. La gestion d'état par le serveur devient un standard des API d'agents, et il vaut mieux s'y habituer.
Ce que nous allons faire chez TRAIVIS
- Tester sur nos agents à longues sessions, et mesurer la latence réelle avant d'adopter la fonction.
- Prévoir la logique de rejeu après expiration dans les workflows n8n et les agents sur mesure.
- Vérifier la compatibilité avec les exigences de confidentialité de chaque client, ZDR et HIPAA en tête.
- Comparer avec l'approche équivalente d'OpenAI.
Pour aller plus loin
- Anthropic's message threads let Claude agents skip resending chats – The Next Web
- Anthropic Launches Message Threads Beta for Long-Running Agents – Unite.AI
- Claude adds public beta for message threads to cut agent latency – Blockchain.News
- Anthropic launches message threads, cutting Claude Code wait time by 35% – Pasquale Pillitteri
Et vous, vos agents tiennent-ils plus de 5 minutes sans bouger, ou votre mécanisme de rejeu est-il déjà prêt à reprendre la main ?