Le réglage « max effort » de Claude Opus 5 fait grimper le prix d'une requête de routine de 0,76 $ à 19,21 $, tout en fournissant essentiellement le même résultat fonctionnel. Ce surcoût permet d'obtenir une passe d'audit interne, et non une meilleure solution, et ne montre des gains mesurables que sur les tâches présentant initialement une faible couverture de tests.
Ce que le test a révélé
L'expérience a comparé le niveau d'effort par défaut de Claude Opus 5 avec le réglage « max effort » sur deux types de prompts : les tâches de codage quotidiennes et les problèmes délibérément complexes.
- Pour une tâche typique, l'exécution à faible effort s'est terminée en deux minutes pour un coût de 0,76 $. Le passage du réglage au maximum a porté la facture à 19,21 $, pourtant le score de couverture des exigences — la métrique que le modèle rapporte pour indiquer à quel point il a respecté le brief — est resté identique.
- La transcription montre un passage de la création à la révision. Le modèle a cessé de générer du nouveau code pour commencer à peaufiner ce qu'il avait déjà écrit. Les modifications ont dépassé les nouvelles écritures selon un ratio de 2,4 pour 1. Les appels à l'outil « read » ont été multipliés par dix-huit, et les invocations de l'outil « bash » ont été multipliées par six. En pratique, le modèle a relu les modules, réexécuté ses propres tests, effectué du linting et même des tests de mutation sans qu'on lui demande.
Le réglage « max effort » n'introduit pas de nouvel algorithme ; il augmente simplement le budget que le modèle peut dépenser. Une fois le budget suffisamment élevé, le modèle passe en mode auto-audit, cherchant la moindre petite amélioration qu'il peut justifier de financer.
Pourquoi les coûts explosent
Lorsque le modèle décide de procéder à un audit, chaque appel supplémentaire à « read » ou « bash » s'ajoute à la facture, et les effets multiplicateurs font rapidement gonfler le coût total.
Le mode audit est un choix de conception explicite. Le modèle considère le budget plus important comme une autorisation à « chercher quelque chose qui mérite d'être corrigé ». Si rien ne semble pouvoir être amélioré, le surcoût n'apporte aucun avantage fonctionnel.
Quand un effort plus élevé est pertinent
Le mode audit ne s'avère utile que lorsque le résultat initial laisse une marge de progression. Dans un projet Go avec une couverture de tests de 0,73, le passage de l'effort au maximum a porté la couverture à 0,88.
À l'inverse, une tâche Python ayant déjà atteint une couverture de 0,98 n'a connu aucun changement lorsque le budget a été augmenté. Le modèle s'est contenté de revérifier le même code de haute qualité, gonflant le coût sans ajouter de valeur.
Inconvénients potentiels
- Explosion du budget – Les utilisateurs habitués au tarif de l'effort faible pourraient être surpris par une augmentation de vingt-cinq fois pour le même livrable.
Conseils pratiques pour les développeurs
- Maintenez les prompts de routine au niveau d'effort par défaut. Vous obtenez le même résultat fonctionnel pour une fraction du prix.
- Réservez le « max effort » pour le code qui ne respecte pas un seuil de qualité clair : faible couverture de tests, avertissements de linting manquants ou autres lacunes mesurables.
- Considérez ce réglage comme un mode distinct : une passe d'auto-révision optionnelle plutôt qu'un bouton de réglage pour obtenir de meilleures réponses.
À retenir
Le commutateur « max effort » de Claude Opus 5 échange de l'argent contre un contrôle qualité interne, et non contre un meilleur code. Utilisez-le avec parcimonie, uniquement lorsque vos résultats de base présentent une lacune quantifiable à combler ; sinon, le réglage par défaut peu coûteux offre le même résultat sans la facture du mode audit.
Discussion communautaire : https://t.me/GyaanSetuAi