Message threads dans l'API Claude : on n'envoie que les nouveaux messages

Anthropic a lancé en bêta les message threads de l’API Claude : la conversation reste un moment côté serveur, et chaque requête suivante n’envoie plus que les nouveaux messages. La nouveauté figure dans les Claude Release Notes depuis le 2 novembre et fonctionne avec l’en-tête bêta message-threads-2026-08-12.

Comment fonctionnent les message threads dans l’API Claude ?

Jusqu’ici, chaque tour d’une conversation avec la Messages API obligeait à renvoyer tout l’historique : le prompt système, les outils et tous les messages. D’après la documentation des message threads, l’API devait tout revalider et retokeniser à chaque fois. Avec un thread, l’essentiel de ce travail ne porte plus que sur le nouveau tour.

Tout le mécanisme tient en un nouveau paramètre, thread :

1. La première requête part comme d’habitude, avec la conversation complète, system et tools, plus "thread": {"type": "create"}. L’API enregistre la conversation avec la réponse de Claude sous l’id de cette réponse.
2. Les requêtes suivantes contiennent "thread": {"type": "continue", "previous_message_id": "<id>"} et uniquement les nouveaux messages, par exemple le message suivant de l’utilisateur ou les résultats d’outils (tool_result).
3. On omet system et tools, car le thread s’en souvient. Les envoyer dans une requête continue provoque une erreur 400.

Selon Anthropic, on obtient des requêtes plus petites et un temps jusqu’au premier token plus court et plus stable, même quand la conversation s’allonge. Ce sont les longues boucles d’agents qui y gagnent le plus : l’agent enchaîne des dizaines d’appels d’outils et devait à chaque fois renvoyer un historique toujours plus long (pour comprendre ces boucles, voir l’article qu’est-ce qu’un agent IA).

Que fait le SDK à notre place ?

Le SDK propose un nouvel assistant, client.beta.messages.thread(...). On le crée avec les mêmes champs qu’une requête normale, puis on envoie les tours suivants avec thread.send(...). L’assistant ajoute lui-même l’en-tête bêta, crée le thread au premier tour et le poursuit aux suivants.

Fait intéressant, le tool runner bêta du SDK utilise les threads par défaut : les agents construits dessus peuvent donc accélérer sans modifier le code (on peut le désactiver à la création du runner).

L’assistant gère aussi les cas d’échec : quand un thread expire, il renvoie toute la conversation dans une nouvelle requête create. Mais il ne conserve cette copie complète qu’en mémoire, tant que l’objet assistant existe.

À quoi faut-il faire attention ?

D’abord, à la courte durée de vie. Un thread expire 5 minutes après la dernière requête, et l’API le supprime au plus tard une heure après sa dernière utilisation. La documentation qualifie les threads de « best-effort » : notre application doit rester la source de vérité de la conversation et gérer dès le départ le renvoi complet après une erreur 404 thread_not_found.

Ensuite, à ce qu’on ne peut pas modifier. Des champs comme model, thinking, tool_choice ou context_management doivent garder les mêmes valeurs dans tout le thread, sinon l’API renvoie l’erreur thread_fingerprint_mismatch. Un thread ne peut que s’allonger, et chaque id de réponse ne peut être poursuivi qu’une fois. Pour modifier un message précédent ou changer le prompt système, on démarre un nouveau thread.

Troisièmement, au prompt caching. Un thread ne met rien en cache tout seul. Le cache fonctionne comme avant, et une requête avec thread accepte au maximum 4 points cache_control. Le plus simple est d’envoyer à chaque tour le même cache_control au niveau supérieur de la requête.

Quatrièmement, aux fonctionnalités incompatibles avec les threads :

1. Message Batches et Token Counting.
2. Compaction, y compris la compaction à la demande, et le context editing (avec une exception décrite dans la documentation).
3. Les organisations où HIPAA readiness ou Inference hooks sont activés.

Cinquièmement, aux données. Les threads ne sont pas éligibles au ZDR (zero data retention). D’après la documentation, la conversation, le prompt système et les outils sont conservés en mémoire, chiffrés avec une clé gérée par le serveur, et jamais écrits sur un disque persistant.

Où et avec quels modèles ça fonctionne ?

Les message threads sont en bêta sur l’API Claude, Claude Platform on AWS, Claude Models on Google Cloud (gérés par Anthropic) et Microsoft Foundry. Les modèles pris en charge incluent notamment Claude Fable 5.1 et Mythos 5.1, Opus 5.5, Sonnet 5.5 et Haiku 5.5, et parmi les plus anciens Opus 4.5, Sonnet 4.5 et Haiku 4.5.

Les threads ne changent ni les tarifs ni les limites de requêtes. On paie les tokens comme avant : le gain porte sur le temps et la taille des requêtes, et il vaut toujours la peine de suivre les coûts, par exemple avec la nouvelle API d’analyse des coûts de Claude. C’est un nouveau changement dans l’API elle-même ces derniers jours, après le passage de la taille maximale de requête à 128 Mo.

(À ne pas confondre avec les « session threads » de Claude Managed Agents. C’est une fonctionnalité distincte, comme le rappelle la documentation.)

FAQ

Que sont les message threads de l’API Claude ?

Une fonctionnalité bêta dans laquelle l’API conserve brièvement la conversation côté serveur. Après la première requête, on n’envoie que les nouveaux messages et l’id de la réponse précédente.

Les message threads réduisent-ils le coût de l’API Claude ?

Pas directement. D’après la documentation, les threads ne changent ni les tarifs ni les limites de requêtes. Le gain, ce sont des requêtes plus petites et un temps jusqu’au premier token plus court.

Combien de temps l’API Claude conserve-t-elle un thread ?

Un thread expire 5 minutes après la dernière requête, et l’API le supprime au plus tard une heure après sa dernière utilisation. Ensuite, il faut renvoyer toute la conversation.

Les message threads fonctionnent-ils sur Amazon Bedrock ?

La documentation cite l’API Claude, Claude Platform on AWS, Claude Models on Google Cloud (gérés par Anthropic) et Microsoft Foundry. Amazon Bedrock ne figure pas dans la liste.