Claude Code : le plafond d’effort enfin configurable

La réponse en bref

Passez à Claude Code 2.1.267 ou à une version ultérieure, puis ajoutez "maxEffortLevel": "medium" au fichier de réglages correspondant aux personnes et aux projets à encadrer. Utilisez ~/.claude/settings.json pour définir votre propre plafond global, .claude/settings.json pour toutes les personnes qui travaillent dans un dépôt donné, ou les réglages administrés pour appliquer une règle à toute l’organisation.

Le paramètre accepte low, medium, high, xhigh ou max. La valeur max signifie que cette source n’impose aucun plafond d’effort. Ne pas définir la clé revient également à ne fixer aucune limite.

Il s’agit d’un limiteur de vitesse, pas d’une carte carburant. Ce réglage borne l’effort de raisonnement que Claude peut consacrer à une requête. Il ne définit ni quota de tokens, ni budget en dollars, ni limite d’utilisation de l’abonnement. Mesurez ces éléments séparément avec /usage, la Claude Console ou OpenTelemetry pour Claude Code.

Ce que maxEffortLevel change réellement dans Claude Code

effortLevel et maxEffortLevel n’ont pas le même rôle. Le niveau d’effort correspond au réglage demandé pour une session ou un modèle. Le niveau d’effort maximal constitue la frontière que cette requête ne peut pas franchir.

Avec un plafond fixé à medium, un développeur peut toujours choisir low ou medium. Une demande en high, xhigh ou max s’exécute en revanche au niveau medium. Le plafond intercepte aussi l’effort demandé via /effort, le sélecteur /model, --effort, CLAUDE_CODE_EFFORT_LEVEL et le réglage par défaut du modèle. Claude Code l’applique côté client avant chaque requête. La même politique fonctionne donc lorsque le trafic du modèle passe par Anthropic, Amazon Bedrock, Agent Platform de Google Cloud ou Microsoft Foundry.

La règle décisive se remarque facilement trop tard : le plafond le plus bas parmi toutes les sources chargées l’emporte. En temps normal, les réglages de Claude Code suivent une hiérarchie où les réglages administrés priment sur ceux de la ligne de commande, des fichiers du projet et de l’utilisateur. maxEffortLevel constitue une exception restrictive. Un plafond de projet plus bas reste prioritaire, même si une source administrée ou une source utilisateur autorise davantage d’effort.

Définir un plafond global, une exemption de modèle et une limite de projet plus stricte

Commencez par vérifier claude --version. Si la version est antérieure à 2.1.267, exécutez claude update avant d’ajouter la clé.

Pour appliquer un plafond personnel à tous les dépôts, placez ceci dans ~/.claude/settings.json :

{
  "maxEffortLevel": "medium",
  "modelSettings": {
    "claude-sonnet-4-6": {
      "maxEffortLevel": "max"
    }
  }
}

La valeur de premier niveau plafonne tous les modèles compatibles à medium. Dans ce fichier utilisateur uniquement, l’entrée Sonnet 4.6 remplace cette valeur pour Sonnet. Sa valeur max ne force pas Sonnet à fonctionner à l’effort maximal. Elle indique que cette source précise ne plafonne pas ce modèle.

Ajoutez ensuite une règle plus stricte pour un dépôt dans .claude/settings.json :

{
  "maxEffortLevel": "low"
}

Le résultat effectif est volontairement strict :

L’exemption du modèle ne traverse pas la règle du projet. Elle annule seulement, pour Sonnet, le plafond medium défini par la source utilisateur. C’est l’erreur la plus susceptible de donner à tort l’impression qu’une exemption s’applique partout.

Pour une politique d’entreprise, déployez la même clé de premier niveau au moyen des réglages administrés. Le plafond s’applique alors aux personnes couvertes par cette source administrée, quel que soit le fournisseur compatible. Si un rôle Enterprise comporte aussi une limite d’effort, Claude Code retient le plafond le plus bas.

Vérifier le plafond avant de s’y fier

Un fichier JSON valide ne prouve pas que le plafond voulu a gagné. Vérifiez à la fois les sources chargées et le niveau effectivement appliqué.

1. Exécutez /status dans Claude Code. La ligne Setting sources confirme le chargement des réglages utilisateur, projet et, le cas échéant, administrés. Elle n’indique pas quelle source fournit chaque clé.
2. Exécutez claude doctor si une source manque ou si une nouvelle clé semble ignorée. La commande recense les entrées de réglages rejetées. Le schéma JSON publié peut accuser un retard sur une nouvelle version du CLI : un avertissement de l’éditeur ne suffit donc pas à trancher.
3. Regardez l’en-tête de session à côté du nom du modèle. Claude Code y affiche l’effort courant, ainsi que brièvement dans le pied de page lorsqu’il change.
4. Dans le dépôt de l’exemple, demandez /effort max. Le plafond low défini au niveau du projet continue de s’appliquer. Une demande supérieure ne peut pas le relever.
5. Pour les parcs non interactifs, examinez l’attribut effort sur claude_code.cost.usage et claude_code.token.usage. Il consigne le niveau appliqué à chaque requête, avec le modèle et la source de la requête.

Cette dernière vérification est importante sur Bedrock, Google Cloud et Foundry. Claude Code applique la politique avant que le fournisseur ne reçoive la requête, tandis que la télémétrie indique ce que Claude Code a réellement utilisé.

Tester la qualité et la dépense sur deux axes distincts

Ne déployez pas un plafond medium ou low simplement parce que son libellé paraît économique. Partez d’une tâche courante que l’équipe maîtrise déjà et comparez des exécutions appariées.

Un bon scénario de test consiste en un petit dépôt contenant un test d’analyseur en échec. Conservez le même modèle, le même commit, le même prompt, les mêmes autorisations et le même accès aux outils à chaque exécution : corriger le cas limite, ajouter un test de non-régression, lancer la suite et indiquer les fichiers modifiés. Lancez d’abord une exécution de référence sans plafond, rétablissez le dépôt dans son état initial, puis lancez la condition plafonnée.

Évaluez le résultat avant de consulter le coût :

La bonne métrique de décision est le coût par tâche acceptée, pas le nombre de tokens par réponse. Une exécution à effort réduit qui nécessite une seconde revue ou une réparation peut coûter plus cher qu’une exécution propre à effort supérieur. Le même raisonnement vaut pour le comparatif plus large des niveaux d’effort de Claude, mais le nouveau paramètre permet de faire respecter dans Claude Code la limite supérieure retenue.

Sept situations où un plafond d’effort est rentable

Ces cas d’usage sont classés selon les équipes qui en tirent le bénéfice opérationnel le plus clair.

1. Les équipes plateforme qui encadrent les tâches courantes

Une équipe plateforme au service de 20 ou 200 développeurs pourrait définir medium dans les réglages administrés, laisser les niveaux inférieurs disponibles et réserver les changements de politique aux exceptions mesurées. Le gain ne se limite pas à une baisse du nombre de tokens. Une même frontière par défaut s’applique aux ordinateurs portables, aux sessions dans l’IDE et aux routages via les fournisseurs cloud, ce qui rend les comparaisons de coût et de qualité exploitables.

2. Les responsables FinOps de Claude Code facturé à l’API

Un responsable FinOps pourrait associer un plafond administré à OpenTelemetry, puis regrouper les données par effort, modèle, équipe et centre de coûts. Le workflow est simple : observer la référence sans plafond, introduire la limite auprès d’un groupe pilote et comparer le coût par tâche acceptée. Les débats sur le niveau d’effort qui « semble » cher laissent place à un rapport relié au travail livré.

3. Les entreprises sur Bedrock, Google Cloud ou Foundry

Une entreprise réglementée peut acheminer les modèles par le cloud retenu pour ses achats ou ses contrôles de données. Comme le client Claude Code applique maxEffortLevel avant chaque requête, l’organisation peut conserver une seule politique d’effort chez tous ces fournisseurs. Elle obtient ainsi une règle cohérente sans attendre que chaque console fournisseur propose la même commande.

4. Les responsables CI qui automatisent des corrections répétitives

Une équipe qui utilise Claude Code pour mettre à jour des dépendances, réparer le formatage, maintenir les tests ou modifier la documentation pourrait plafonner les dépôts concernés à low ou medium. Le niveau précis doit provenir de scénarios de test représentatifs. Une fois la qualité confirmée, le plafond empêche qu’une option, un skill ou le réglage par défaut d’un modèle fasse passer une automatisation courante dans un mode de raisonnement plus poussé.

5. Les responsables de monorepos qui séparent tâches courantes et travaux difficiles

Le responsable d’un monorepo pourrait conserver un plafond personnel medium, versionner une limite partagée plus basse dans un dépôt de documentation ou de code généré, et laisser un dépôt système plus complexe profiter de la limite plus large. Chaque dépôt porte sa propre frontière. La politique de coût suit ainsi le travail, sans compter sur la mémoire de chaque développeur pour exécuter une commande.

6. Les cabinets de conseil qui alternent entre les dépôts clients

Un consultant pourrait prendre un plafond personnel medium comme référence et laisser chaque dépôt client imposer un réglage partagé plus strict. Cette approche limite la dérive de configuration lorsqu’un même ordinateur passe d’un petit site de contenu à une application mature, puis à un contrat de maintenance attentif aux coûts. Le fichier du projet documente aussi le mode de fonctionnement prévu pour la personne suivante.

7. Les staff engineers qui préservent une exemption ciblée par modèle

Un staff engineer pourrait exempter un modèle du plafond global d’une source avec modelSettings, tout en conservant une limite distincte et plus basse dans un dépôt critique pour la sécurité. Le modèle dispose ainsi de latitude lorsque la source l’autorise, sans transformer l’exemption en passe-droit universel. Le bénéfice tient à une exception précise qui reste subordonnée aux règles plus strictes du projet ou de l’organisation.

Les produits qui méritent d’être construits autour de ce plafond

1. Un contrôle de régression de l’effort, la meilleure piste

Créez un outil CLI et un contrôle CI qui exécutent la suite de tâches acceptées d’un dépôt aux niveaux d’effort autorisés, puis rendent compte du taux de réussite, des défauts détectés en revue, de la durée, des tokens et du coût. Les équipes de plateforme d’ingénierie seraient prêtes à payer, car le plafond pose immédiatement une question de qualité : jusqu’où peut-on réduire l’effort des tâches courantes avant que les réparations n’annulent les économies ?

Le signal de demande est particulièrement commercial. ai code review totalise environ 1,300 recherches mensuelles aux États-Unis, avec un CPC de $62.38. La plus petite version commercialisable prendrait la forme d’un exécuteur local accompagné d’un contrôle GitHub, capable de comparer deux profils d’effort sur le même scénario propre et de bloquer un changement de politique lorsque les tests obligatoires ou les règles de revue régressent.

La difficulté réside dans le benchmark. Un score de programmation générique est facile à copier et peu représentatif du dépôt de l’acheteur. Ce qui rend le produit défendable, c’est le jeu de tâches privé de l’équipe, sa grille de revue et l’historique accumulé au fil des mises à jour des modèles. Sans ces données, ce n’est qu’un tableau de bord de plus.

2. Un linter de politique d’effort pour Claude Code

Créez un inspecteur de politique en lecture seule qui rassemble les sources utilisateur, projet partagé, projet local, ligne de commande et administration dans un tableau unique des plafonds par modèle. Les équipes plateforme et sécurité pourraient ainsi repérer une exemption max supposée globale, un plafond de projet plus bas qui s’impose de manière inattendue, ou un parc encore bloqué sur une version antérieure à 2.1.267.

claude code totalise environ 550,000 recherches mensuelles aux États-Unis, et la liste des questions actives comprend « Quel niveau d’effort utiliser avec Claude Code ? ». Ce volume est large plutôt que directement orienté vers l’achat, mais la confusion liée à la configuration est bien réelle. Un MVP n’a besoin que de détecter les sources et la version, de valider le JSON et d’expliquer pourquoi le plafond le plus bas l’emporte.

Le risque vient de la plateforme. Anthropic pourrait ajouter un inspecteur natif des réglages effectifs. Pour durer, le produit devrait proposer des alertes de dérive des politiques, un inventaire du parc et des preuves d’audit, plutôt qu’un simple écran de réglages plus élégant.

3. Un suivi des dépenses Claude Code sensible au niveau d’effort

Créez un tableau de bord OpenTelemetry ciblé qui rapproche l’attribut effort appliqué des tokens, du coût, du modèle, de la source de la requête, du dépôt et des contrôles qualité, aussi bien chez Anthropic que dans les déploiements via des fournisseurs cloud. Les équipes FinOps et d’expérience développeur paieraient pour relier politique et résultat, pas pour un nouveau total de tokens.

llm observability totalise environ 590 recherches mensuelles aux États-Unis, avec un CPC de $37.45. Les offres existantes confirment l’existence d’un budget : Agent Observability de Datadog est gratuit jusqu’à 40,000 spans LLM, tandis que l’offre Pro commence à $160 par mois pour 100,000 spans. Un MVP ciblé pourrait prendre la forme d’un préréglage de collecteur OpenTelemetry, d’un inventaire des plafonds et de trois vues : effort appliqué, coût par tâche acceptée et régressions après un changement de modèle ou de politique.

La difficulté tient à la concurrence et à la causalité. Les éditeurs d’observabilité collectent déjà les tokens et les coûts, et une facture plus basse après l’ajout d’un plafond ne prouve pas que celui-ci en est la cause. Le produit doit s’appuyer sur des évaluations appariées ou sur l’analyse de points de rupture pour gagner la confiance des équipes.

Le contrôle de régression de l’effort est la meilleure de ces trois pistes. Sa demande est la plus proche d’une décision d’achat en ingénierie, tandis que son historique d’évaluations privées gagne en valeur à chaque changement de modèle ou de calibrage de l’effort par Anthropic.

Ce que le plafond ne résout pas

Un plafond d’effort ne garantit pas une facture moins élevée. L’effort influe sur les tokens de sortie, le comportement des outils et le raisonnement, mais le choix du modèle, la taille de la base de code, le fonctionnement du cache et les automatisations parallèles comptent toujours. Pour les abonnés Claude Max et Pro, l’utilisation est incluse dans le forfait : le coût de session indiqué par /usage ne correspond donc pas à leur facture.

Il ne rend pas low sûr pour toutes les tâches de développement. Anthropic recommande explicitement de tester la charge de travail, et un même niveau d’effort est calibré différemment selon les modèles. Une exécution medium sur un modèle ne représente pas une quantité fixe de raisonnement que l’on pourrait comparer mécaniquement à medium sur un autre.

Il ne crée pas de passe-droit absolu pour un modèle. Une entrée max propre à un modèle supprime uniquement le plafond de premier niveau dans la même source. Une autre source peut encore imposer une limite inférieure, tout comme une limite d’effort définie par l’organisation.

Enfin, /status confirme les fichiers chargés, mais pas le fichier gagnant pour chaque clé. Dans une automatisation, l’attribut télémétrique effort appliqué constitue une trace plus fiable.

L’action à lancer lundi

Choisissez une tâche courante dans un dépôt la semaine prochaine. Mesurez une référence sans plafond, ajoutez un plafond utilisateur medium, configurez l’exemption Sonnet documentée, puis placez low dans le fichier partagé du projet. Confirmez les sources chargées et l’effort affiché dans l’en-tête de session, répétez la tâche à partir du même dépôt réinitialisé, puis évaluez la qualité au regard des critères d’acceptation avant de consulter le coût dans /usage. Si la qualité tient, appliquez le plafond testé au bon périmètre partagé ou administré. Si elle baisse, relevez ou supprimez le plafond le plus strict pour cette charge de travail, tout en conservant les preuves.

Pour faire construire une politique d’effort, un contrôle d’évaluation et une télémétrie des coûts adaptés à votre workflow d’ingénierie, découvrez les systèmes d’IA en production.