L’une des évolutions les plus discrètes de la release d’Opus 4.7 hier, jeudi 16 avril 2026, est aussi l’une des plus structurantes pour qui utilisait Claude en API ou en intégration custom. Le manual thinking, qui permettait de fixer un budget de raisonnement à la main, disparaît. L’adaptive thinking devient le seul mode supporté. Décryptage de ce que ça change.
Ce qu’était le manual thinking
Sur Opus 4.6 et les versions précédentes, le modèle acceptait un paramètre thinking_budget exprimé en tokens. Tu pouvais fixer par exemple 8000 tokens pour un problème simple, 32000 pour un refactor, 65000 pour un audit complexe. Le modèle utilisait ce budget pour son raisonnement interne avant de produire la réponse finale.
L’idée était de te donner un contrôle explicite sur le trade-off entre profondeur et coût. En théorie, c’était élégant. Tu réfléchis en amont à la difficulté de ta tâche, tu fixes un budget proportionné, tu paies ce que tu demandes.
Pourquoi ça marchait mal
En pratique, ce contrôle manuel posait trois problèmes.
La majorité des utilisateurs calibraient mal leur budget. Trop bas, le modèle étranglait son raisonnement et produisait une sortie superficielle. Trop haut, tu payais pour du reasoning qui n’apportait rien. Sans benchmark rigoureux, la plupart des devs fixaient leur budget au doigt mouillé.
Le bon budget variait énormément selon la tâche. Un refactor touchant à 3 fichiers interdépendants ne demandait pas le même budget qu’un refactor touchant à 1 fichier isolé, même si tous deux étaient nominalement “du refactor”. Un budget unique par projet, qu’on trouvait souvent dans les intégrations API, était par nature sous-optimal.
Le budget était un paramètre exposé au mauvais endroit. Devoir le fixer dans chaque appel API polluait le code d’intégration. Certains teams finissaient par laisser un default et ne plus y toucher, perdant au passage le bénéfice supposé du réglage.
Comment fonctionne l’adaptive thinking
L’adaptive thinking renverse la logique. Au lieu de demander à l’utilisateur de fixer un budget, le modèle évalue lui-même la complexité de la tâche au fil du reasoning et ajuste sa profondeur en temps réel.
Techniquement, la partie reasoning du modèle démarre une analyse légère, détecte les zones d’incertitude ou de complexité, et alloue plus de compute à ces zones spécifiques. Sur une tâche simple, le modèle clôt son raisonnement rapidement. Sur une tâche complexe, il creuse les parties qui le méritent.
Le bénéfice est que le modèle investit ses tokens de reasoning là où ils sont utiles, pas uniformément sur la tâche. Sur mes propres benchs avant migration, l’adaptive thinking a produit des sorties de qualité équivalente à un manual thinking bien calibré, avec une consommation de tokens de reasoning inférieure de 10 à 15 % en moyenne.
Le fait qu’il n’y ait plus d’alternative change la philosophie
Avant, l’adaptive thinking existait en option. Manual thinking existait aussi. Tu choisissais. Sur 4.7, c’est adaptive thinking, et basta. Les anciens paramètres thinking_budget sont simplement ignorés.
Ce choix est un parti pris. Anthropic dit : “vous calibriez mal, on reprend la main”. C’est cohérent avec la logique produit globale de la release, qui pousse à traiter Claude comme un ingénieur autonome plutôt qu’un outil finement configurable. Tu donnes l’objectif, le modèle décide du comment.
Certains power users regretteront la perte de contrôle. Pour la majorité, c’est un gain net parce qu’ils bénéficient d’un réglage que peu savaient calibrer correctement.
Ce que tu dois faire dans tes scripts
Si tu as des intégrations API qui utilisaient thinking_budget, voici ta check-list.
Supprime tous les thinking_budget hardcodés. Un grep -r "thinking_budget" . sur ton repo localise les zones. Supprimer ces paramètres n’a aucun effet fonctionnel négatif, le modèle les ignore simplement.
Revois les prompts qui faisaient des hypothèses sur le reasoning. Certaines équipes prompt-engineeraient autour d’un budget fixe connu. Par exemple en disant “n’utilise pas plus de X tokens de reasoning”. Ces instructions restent valides mais leur effet est moins prévisible avec adaptive thinking, à tester.
Mets à jour ta doc interne. Si tu avais des guidelines sur les budgets par type de tâche, ces guidelines sont obsolètes. Remplace-les par des guidelines sur les niveaux d’effort (low, medium, high, xhigh, max) qui, eux, restent actifs et utiles.
Les cas où adaptive thinking peut décevoir
Aucun système adaptatif n’est parfait. Deux cas où tu verras ses limites.
Tâches très cadrées avec contraintes fortes de latence. Si tu construis un service qui doit répondre en moins de X secondes et que tu veux borner précisément le reasoning, l’adaptive thinking te prive de ce contrôle. Contournement : utiliser un niveau d’effort bas (low ou medium) pour réduire globalement le budget adaptatif alloué.
Tâches que le modèle évalue mal. Parfois, une tâche paraît simple au modèle mais demande en fait un reasoning profond. L’adaptive thinking peut le rater et produire une sortie superficielle. Dans ce cas, pousse explicitement : “cette tâche demande un raisonnement détaillé, prends le temps de décomposer”.
Mon verdict
L’adaptive thinking est une bonne évolution. La suppression du manual thinking est un parti pris plus qu’une simplification, mais c’est un parti pris défendable compte tenu de la façon dont la plupart des utilisateurs usaient (mal) du contrôle manuel. Pour ceux qui maîtrisaient le manual thinking, la perte est réelle mais limitée.
Nettoie tes scripts, bascule tes intégrations, et laisse le modèle faire son travail.
FAQ
L’adaptive thinking fonctionne-t-il sur tous les niveaux d’effort ? Oui, il s’applique quel que soit le niveau d’effort choisi. Le niveau d’effort fixe l’enveloppe globale de tokens, adaptive thinking répartit ces tokens au sein de cette enveloppe.
Peut-on encore forcer un reasoning long via le prompt ? Oui. Dire “prends le temps de décomposer étape par étape” ou “analyse en profondeur avant de répondre” augmente la profondeur de reasoning. C’est moins précis qu’un budget chiffré, mais ça marche.
Est-ce que ça impacte la facturation ? Le coût reste basé sur les tokens consommés (entrée, sortie, reasoning). Adaptive thinking optimise la consommation mais ne change pas le modèle de facturation.
Je dirige Linkuma, plateforme de netlinking avec 40 000 sites au catalogue, 15 000 clients accompagnés, backlinks à partir de 5 euros. Retours terrain sur linkuma.com, promos hebdo sur deals.linkuma.com.