Anthropic a ajouté à la documentation développeur de Claude une fonction en bêta : le réglage de l'effort par message. Au milieu d'une conversation à plusieurs tours, les développeurs peuvent insérer un message system spécial pour modifier le niveau de raisonnement des réponses suivantes, de high à low ou l'inverse. Le réglage d'effort placé au niveau supérieur de la requête reste intact, de sorte que le début de conversation déjà mis en cache continue d'être réutilisé.
La syntaxe donnée dans la documentation est courte. Dans le tableau messages, on ajoute un message dont role vaut system et dont content est un tableau vide, contenant la nouvelle valeur de output_config.effort, et l'on envoie l'en-tête mid-conversation-output-config-2026-07-01. Dans l'exemple, l'effort de niveau supérieur est réglé sur high et le modèle planifie d'abord, à un niveau élevé, une migration en trois étapes de SQLite vers PostgreSQL. Un message system de niveau low est ensuite inséré ; l'utilisateur demande simplement de condenser le plan en une phrase, et ce tour est traité à un niveau bas.
À partir de quel tour le nouveau niveau s'applique
Le moment où le changement prend effet dépend de l'endroit où le message est placé, et les règles sont assez détaillées :
- S'il suit immédiatement un message user contenant une nouvelle entrée, Claude applique le nouveau niveau à la réponse de ce tour ;
- S'il se trouve ailleurs, par exemple entre la réponse de l'assistant et le message user suivant, le nouveau niveau s'applique à partir du prochain message user contenant une nouvelle entrée ;
- Un message user qui ne contient qu'un tool_result ne compte pas comme une nouvelle entrée, si bien que plusieurs allers-retours d'appels d'outils ne déclenchent pas de changement.
Le nouveau niveau reste en vigueur jusqu'à ce qu'un message ultérieur le modifie. La documentation insiste sur un point : ce message doit être placé à la fin du contenu déjà envoyé et conservé tel quel dans les requêtes suivantes ; on ne peut ni l'insérer avant des tours déjà envoyés, ni le déplacer ou le supprimer après coup. Sur les modèles qui prennent en charge la preserved thinking (réflexion conservée), chacune de ces modifications invalide les blocs de réflexion des tours de l'assistant situés après ce message.
Les cas d'erreur sont eux aussi listés clairement. Écrire output_config dans un message system sans l'en-tête bêta fait renvoyer à l'interface une erreur 400 avec le message Extra inputs are not permitted ; avec l'en-tête bêta mais sur un modèle non pris en charge, comme Claude Fable 5, c'est également une erreur 400. Quand Sonnet 5.5 fonctionne avec le mode de réflexion between_tools, ou que Haiku 5.5 a la réflexion désactivée, il est de même impossible de changer de niveau en cours de conversation ; la documentation conseille dans ces deux cas de recourir plutôt à la réflexion adaptative.
Comment on basculait avant, et ce qui disparaît
L'effort était jusqu'ici un paramètre au niveau de la requête, inscrit tout en haut de celle-ci. Pour qu'une même conversation réfléchisse sérieusement au début puis réponde vite ensuite, le développeur ne pouvait que modifier la valeur de niveau supérieur entre deux requêtes. La documentation porte un jugement sans détour sur cette pratique : dès que la valeur supérieure change, le cache du prompt repart de zéro, et le long contexte accumulé est facturé comme s'il n'avait pas été trouvé dans le cache.
"A per-message change leaves everything before it unchanged, so the cached prefix still matches." (Un changement par message laisse tout ce qui précède inchangé, si bien que le préfixe en cache correspond toujours.)
La documentation mentionne aussi un détail facile à négliger : sur Claude Fable 5.1, modifier la valeur de niveau supérieur oriente déjà peu fiablement le modèle, car les réponses précédentes ont été rédigées selon l'ancien niveau et le modèle a tendance à rester cohérent avec son propre style. Le changement par message inscrit dans la conversation elle-même la consigne « à partir d'ici, on change de vitesse », et le modèle voit ce point de bascule.
C'est surtout utile pour les boucles d'Agent qui tournent longtemps. Un agent de programmation peut consacrer un niveau élevé à la lecture du code et à l'arrêt du plan de modification, puis exécuter et confirmer pendant des dizaines de tours à un niveau bas, tandis que le préfixe de contexte reste identique et que le taux de réussite du cache n'est pas affecté. Il fallait auparavant choisir entre souplesse du niveau et économie du cache ; on peut désormais avoir les deux.
Les applications de service client et de questions-réponses peuvent aussi en profiter. Au début, l'utilisateur décrit une panne complexe et le modèle établit son diagnostic à un niveau élevé ; une fois le problème localisé, lorsque l'utilisateur demande simplement « où cliquer exactement à la deuxième étape », passer à un niveau bas rend la réponse nettement plus rapide. À l'inverse, si au milieu d'une discussion informelle l'utilisateur jette soudain un contrat à examiner clause par clause, l'application peut relever temporairement le niveau. Ces bascules obligeaient jusqu'ici à renoncer au cache, ou tout simplement à ne pas basculer.
Étendue de la prise en charge
Côté modèles, Fable 5.2, Mythos 5.2, Fable 5.1, Mythos 5.1, Opus 5.5, Opus 5, Sonnet 5.5 et Haiku 5.5 figurent tous sur la liste bêta, et les plateformes cloud couvertes ne sont pas les mêmes d'un modèle à l'autre. Côté plateformes, l'API Claude, Amazon Bedrock, Claude Platform on AWS, les deux modes d'hébergement sur Google Cloud et Microsoft Foundry sont tous signalés comme bêta. Les développeurs qui utilisent l'interface InvokeModel de Bedrock doivent inscrire la valeur bêta dans le tableau anthropic_beta du corps de la requête, et non dans un en-tête.
Managed Agents ne prend pas encore en charge cette fonction ; l'alternative proposée par la documentation consiste à remplacer, au niveau de la session, le paramétrage de modèle de l'Agent. La fonction est toujours en phase bêta, la date contenue dans le nom de l'en-tête bêta est un identifiant de version de l'interface, et la documentation ne précise pas si sa forme changera à la sortie de la version stable.
Sources : page Per-message effort de la documentation développeur de Claude (vérification du nom de l'en-tête bêta, de la liste des modèles et plateformes, des règles de prise d'effet et des messages d'erreur), CocoLoop, explication du paramètre effort dans la documentation développeur de Claude.