L'ESSENTIEL EN 30 SECONDES

  • Avec un thread, le développeur envoie une seule fois la conversation complète, puis uniquement les nouveaux messages et l'identifiant de la réponse précédente ; le prompt système et les outils sont conservés.
  • Anthropic fait état d'un délai avant le premier token réduit d'environ 35 % pour des requêtes de 500 000 à un million de tokens, selon The Decoder.
  • Un thread expire cinq minutes après la dernière requête, ne modifie ni les tarifs ni les limites de débit et n'est pas compatible avec la conservation zéro des données.

Anthropic lance Message Threads, une fonctionnalité en bêta publique de son API Messages pensée pour les agents qui tournent longtemps. Jusqu'ici, chaque appel devait transporter tout l'historique de la conversation, que le service validait et découpait en tokens à nouveau à chaque tour. Un thread permet au serveur de garder cet historique quelques minutes, si bien que chaque nouvelle requête ne contient que ce qui a changé.

Comment fonctionnent les threads

D'après la documentation d'Anthropic, le développeur ouvre un thread en envoyant la première requête comme d'habitude, avec la conversation complète, le prompt système et les outils, en y ajoutant un nouveau paramètre thread réglé sur la création. Les tours suivants ne transmettent que les nouveaux messages et l'identifiant de la réponse précédente. Le prompt système et les outils ne sont pas renvoyés : le thread garde ceux du premier appel, et certains réglages, comme le modèle, doivent rester identiques sous peine d'erreur. Les SDK d'Anthropic proposent un assistant qui construit ces requêtes.

Le principal gain annoncé concerne la latence. Selon The Decoder, l'entreprise a mesuré un délai avant le premier token en baisse d'environ 35 % pour des requêtes comprises entre 500 000 et un million de tokens. La consommation de tokens ne diminue pas pour autant, puisque le modèle lit toujours l'historique entier, et la documentation précise que les threads ne changent ni les tarifs ni les limites de débit. La mise en cache des prompts doit toujours être demandée à part.

Limites et traitement des données

Le fonctionnement est « best-effort ». Un thread expire cinq minutes après sa dernière requête ; s'il ne peut plus être prolongé, l'API renvoie une erreur 404. Les développeurs doivent donc conserver leur propre copie de la conversation et pouvoir la renvoyer en entier, un mécanisme que la documentation recommande de prévoir dès le départ.

La fonctionnalité est incompatible avec Message Batches, le comptage de tokens, la compaction et la plupart des options d'édition du contexte, et elle n'est pas accessible aux organisations ayant activé la conformité HIPAA. Anthropic indique que le contenu d'un thread reste en mémoire, chiffré par une clé gérée côté serveur, n'est jamais écrit sur un stockage durable et est supprimé au plus tard une heure après sa dernière utilisation. Les threads ne sont toutefois pas éligibles à la conservation zéro des données, ce qui peut compter pour les clients liés par des accords stricts.

La bêta fonctionne sur l'API d'Anthropic ainsi que sur AWS, Google Cloud et Microsoft Foundry, et vise notamment les agents de programmation et ceux qui pilotent un ordinateur.