Le 2 novembre, Anthropic a ouvert sur Claude Platform la bêta publique des message threads. Le développeur ajoute un paramètre thread à sa requête Messages API, envoie la conversation complète au premier tour, puis, aux tours suivants, uniquement les nouveaux messages et l'ID de la réponse précédente ; le serveur se charge de reconstituer la conversation.
Le chiffre officiel provient de Claude Code. La fonction y est déjà activée par défaut pour la plupart des utilisateurs, et pour les requêtes de 500k à 1M de tokens, le délai médian avant le premier token a baissé d'environ 35 %. Le blog ne donne pas de résultats pour d'autres tranches de longueur.
La bêta couvre l'API Claude, Claude Platform on AWS, Microsoft Foundry ainsi que Claude hébergé par Anthropic sur Google Cloud. Les modèles listés dans la documentation vont de Sonnet 4.5 et Opus 4.5 jusqu'à Fable 5.1 et Mythos 5.1.
Ce qui est économisé, c'est la validation et la tokenisation
Sans thread, l'agent doit renvoyer toute la conversation à chaque tour, et l'API doit la valider et la retokeniser à chaque fois. Plus la session est longue, plus cette préparation prend du temps. Les agents de contrôle d'ordinateur sont les plus pénalisés, car les captures d'écran de l'historique doivent être renvoyées à chaque tour.
Les threads conservent ce contenu dans la mémoire du serveur, si bien que le volume à traiter se réduit pratiquement au seul tour qui vient d'être ajouté.
Claude doit toujours lire la conversation entière à chaque tour : les tokens côté modèle ne diminuent donc pas, et la facturation comme les limites de débit suivent les règles existantes. Un calcul grossier : pour une session de 800 000 tokens avec 2 000 nouveaux tokens par tour, ce qui est transmis dans la requête avec un thread représente environ un quatre-centième de l'ancien volume, mais les tokens d'entrée facturés restent supérieurs à 800 000. Pour réellement économiser, il faut toujours recourir au cache de prompts, qui est un autre interrupteur : une requête de thread peut inclure cache_control au niveau supérieur ; sans cela, même en n'envoyant que les nouveaux messages, rien n'est mis en cache.
À l'intégration, prévoir une porte de sortie
La documentation définit le thread comme fonctionnant « au mieux » (best effort), ce qui conditionne la manière de l'intégrer.
- Expiration : le thread expire 5 minutes après la dernière requête, chaque réponse stockée relance le décompte, et il est supprimé au plus tard 1 heure après la dernière utilisation.
- Invalidation : si une requête de poursuite renvoie 404, il faut renvoyer la conversation complète et ouvrir un nouveau thread. Le résultat n'indique pas si le tour en cours a bien été stocké ; on ne le découvre qu'à la requête de poursuite suivante.
- Copie : la version de référence de la conversation reste côté application. Les utilitaires des SDK officiels en gardent une copie en mémoire et la rejouent automatiquement ; elle disparaît à la fin du processus, et il faut la sauvegarder soi-même pour l'utiliser entre plusieurs processus.
- Champs figés :
systemettoolsne s'envoient qu'à la création ; les inclure dans une requête de poursuite, même avec la valeur null, provoque une erreur 400. Les champsmodel,thinking,tool_choice,mcp_serverset autres doivent être renvoyés à l'identique à chaque tour, faute de quoi l'erreurthread_fingerprint_mismatchest renvoyée. Pour changer le prompt système ou les outils, il faut ouvrir un nouveau thread.
Il existe aussi une limite côté conformité. Le contenu des threads est chiffré en mémoire et n'est pas écrit dans un stockage persistant, mais la fonction ne répond pas aux conditions de la rétention zéro des données (ZDR). Les entreprises ayant signé un accord ZDR peuvent utiliser normalement les autres fonctions, mais pas les threads.
Par ailleurs, les développeurs doivent distinguer deux notions : Claude Managed Agents possède aussi des session threads, qui n'ont rien à voir avec ces message threads.
Une pièce qui manquait
L'API Responses d'OpenAI propose depuis longtemps previous_response_id, qui consiste là aussi à passer un ID pour reprendre le contexte précédent. Anthropic exigeait de longue date que le client envoie l'historique complet à chaque tour : l'avantage est l'absence d'état et une mise en œuvre directe, le prix à payer étant la latence quand la session s'allonge. L'approche retenue ici est un compromis : l'état ne reste que brièvement sur le serveur, on rejoue en cas de perte, et la copie côté client reste indispensable.
D'après les cas d'usage cités par Anthropic, les cibles principales sont les agents de programmation à exécution longue, les agents de contrôle d'ordinateur et les flux de travail riches en documents et en images. Anthropic a aussi commencé par activer la fonction par défaut dans son propre Claude Code, avant de l'ouvrir aux utilisateurs de l'API.
Pour les conversations ordinaires de moins de quelques centaines de milliers de tokens, Anthropic ne donne aucun chiffre sur le gain ; la documentation indique seulement que les threads aident surtout dans les longues boucles d'agents. Les équipes qui construisent leurs propres agents gagneraient à faire d'abord une mesure avec la distribution de longueur de leurs sessions, avant de décider s'il vaut la peine d'écrire une couche de code supplémentaire pour le chemin de rejeu après un 404.
Sources : blog officiel de Claude, CocoLoop, documentation développeur de Claude Platform ; la baisse de latence s'appuie sur la médiane de Claude Code publiée par Anthropic, et le calcul grossier est une estimation de la rédaction.