Claude Code /advisor Command : Un Deuxième Cerveau pour les Modèles Bloqués
J'ai passé tout un samedi à essayer de casser le nouveau commande /advisor de Claude Code.
Pas dans le sens de « trouver le bug et ouvrir un ticket ». Plutôt dans le sens de : « Je me suis assez brûlé avec des slash commands nouveaux et brillants pour ne faire confiance à aucun d'eux avant d'y avoir jeté du code de production moche. » Mon terrain de test était un service de facturation que je refactorise depuis des semaines — une application Laravel 11 avec le genre de cas limites qui expose chaque faiblesse d'un modèle de codage IA. Des mises à niveau au prorata. Des rétrogradations en milieu de cycle. Une logique de dunning qui doit survivre à un échec partiel du webhook Stripe.
Le résultat m'a surpris. Pas parce que /advisor m'a sauvé d'une catastrophe — ce n'est pas le cas. Mais parce qu'il a repéré deux problèmes que je fixais depuis trois jours sans les voir. Un défaut logique dans la fenêtre de prorata et un bug de fuseau horaire subtil dans le calcul de renouvellement. Sonnet 4.6 tournait comme mon exécuteur principal. Quand il a atteint le schéma de blocage à mon troisième passage, il a appelé Opus 4.6 via /advisor et est revenu avec une analyse de deux paragraphes qui ressemblait à une revue de code d'un ingénieur senior.
C'est là que j'ai compris que cette commande ne parle pas vraiment de conseils. Il s'agit d'Anthropic qui construit des échafaudages pour Mythos.
Laisse-moi expliquer ce que j'entends — et pourquoi le slash command /advisor est peut-être la fonctionnalité la plus importante que Claude Code ait livrée ce trimestre, même si la plupart des développeurs la considèreront comme une mise à jour mineure de qualité de vie.
Ce que /advisor fait vraiment (et ce qu'il ne fait pas)
La commande /advisor te permet de configurer un modèle secondaire qui est invoqué quand ton modèle principal rencontre des difficultés. C'est le résumé. La réalité est plus nuancée, et la nuance a de l'importance.
Voici comment fonctionne la configuration actuelle. Tu exécutes /advisor dans Claude Code, tu choisis un modèle dans la liste (en ce moment Sonnet 4.6 ou Opus 4.6 — pas d'autres options, pas d'endpoints personnalisés, pas de Haiku), et à partir de là Claude Code a la capacité d'invoquer ce modèle de manière autonome quand il décide qu'il a besoin d'un deuxième avis. Tu n'appelles pas l'advisor manuellement. Tu ne tapes pas « demande à l'advisor à ce sujet ». Le modèle principal prend la décision de manière autonome en fonction des signaux contextuels.
Cette dernière partie m'a trébuché la première fois. Je continuais à attendre une invite ou un dialogue de confirmation. Il n'y en a pas. L'appel à l'advisor se produit silencieusement, au milieu d'une réponse, et le conseil est replié dans le contexte de session comme s'il avait toujours été là.
Trois choses que tu dois comprendre sur le fonctionnement réel :
L'advisor dispose du contexte conversationnel complet. Quand le modèle principal appelle /advisor, le modèle secondaire reçoit la transcription complète — ta demande originale, chaque appel d'outil, chaque fichier lu, chaque sortie de commande, chaque étape de raisonnement. Pas de paramètres. Pas de filtrage. Pas de cherry-picking. Il voit ce que ton modèle principal a vu, dans le même ordre, avec les mêmes contraintes.
L'advisor ne peut pas toucher le monde extérieur. Pas d'accès au système de fichiers. Pas de commandes shell. Pas de requêtes web. Pas de serveurs MCP. L'advisor existe purement pour raisonner sur l'historique de conversation et retourner des orientations. C'est une limite architecturale dure, pas une permission que tu peux modifier.
Le conseil fait partie de la mémoire partagée. Une fois que l'advisor répond, son analyse persiste dans le contexte de session. Les appels ultérieurs à l'advisor voient les conseils précédents. Si les résultats empiriques contredisent ce que l'advisor a recommandé, Claude Code remonte le conflit à la surface plutôt que de remplacer silencieusement l'orientation. Tu obtiens un moment explicite de « l'advisor a dit X, mais la sortie du test montre Y — faut-il consulter à nouveau ? »
Ce troisième comportement est celui que je n'avais pas anticipé, et c'est celui qui a changé mon avis sur la fonctionnalité.
Les quatre déclencheurs qui appellent l'advisor
J'ai passé la première heure de test à essayer de comprendre quand Claude Code fait vraiment appel à l'advisor. La documentation est légère. Le comportement est en partie émergent. Alors j'ai exécuté plein de scénarios contrôlés et j'ai regardé les logs.
Quatre schémas déclenchent un appel à l'advisor de manière fiable. Si tu comprends ceux-ci, tu sauras si /advisor vaut la peine d'être activé pour ton flux de travail ou s'il va juste consommer des tokens de contexte qu'il n'utilise jamais.
Déclencheur 1 : Avant une écriture ou une interprétation substantielle. Quand le modèle est sur le point d'écrire un bloc de code significatif, de générer un nouveau fichier, ou de faire un saut interprétatif des exigences vers l'implémentation, il marque une pause et demande d'abord à l'advisor une vérification de cohérence. C'est le schéma « mesurer deux fois, couper une ». Les tâches réactives simples — renommer une variable, corriger une faute de frappe, ajuster une marge — sautent entièrement cette étape.
Déclencheur 2 : À la ligne d'arrivée perçue. Quand le modèle principal croit que la tâche est terminée, il appelle l'advisor pour vérifier la sortie avant de déclarer le succès. Cela a capturé un bug dans mon code de facturation que Sonnet 4.6 s'était convaincu d'avoir résolu. L'advisor a signalé un cas limite manquant dans la logique de prorata, et Sonnet est revenu en arrière et l'a corrigé sans que je dise un mot.
Déclencheur 3 : Erreurs récurrentes ou boucles qui ne convergent pas. Si le modèle essaie le même correctif trois fois et que les tests continuent à échouer, ou s'il rebondit entre deux approches incompatibles, l'advisor est sollicité. C'est le schéma qui m'importe le plus parce que c'est celui qui me vidait tout mon après-midi auparavant. Tu connais la boucle — le modèle répare une chose, casse une autre, répare ça, régresse la première, et tu dois finalement intervenir manuellement et démêler tout le bazar.
Déclencheur 4 : Points de contrôle dans les tâches à plusieurs étapes. Pour toute tâche avec plusieurs phases (le genre où Claude Code construit une liste de tâches au début), l'advisor est appelé au moins deux fois. Une fois avant de valider un travail substantiel. Une fois à la complétion. C'est le filet de sécurité par défaut pour les flux de travail où les choses tournent le plus souvent mal.
Ce qui ne déclenche pas un appel à l'advisor ? Des ajustements mineurs d'UI. Des refactorisations ponctuelles. Des correctifs réactifs à des problèmes simples. Tout ce sur quoi le modèle principal est confiant. Le système est délibérément conservateur — il ne veut pas brûler des tokens sur des problèmes qui n'ont pas besoin d'un deuxième avis.
Mais il y a un hic avec ce conservatisme. Si ton modèle principal est trop confiant — et quiconque a utilisé Sonnet 4.6 assez longtemps sait qu'il peut l'être — l'advisor ne sera pas appelé quand il le devrait. Le jugement d'invoquer l'advisor vit à l'intérieur du même modèle dont tu essaies d'auditer le jugement. C'est une tension de conception que je ne pense pas être complètement résolue pour l'instant, et j'y reviendrai dans la section « franchise totale ».
Pour l'instant, laisse-moi te montrer à quoi ressemblent les combinaisons de modèles en pratique.
Les trois combinaisons que j'ai testées (et laquelle gagne)
Il n'y a vraiment que trois façons de configurer /advisor pour l'instant, et j'ai exécuté les trois sur la même refactorisation de facturation pendant le week-end. Voici ce que j'ai trouvé.
Combinaison 1 : Sonnet 4.6 principal + Opus 4.6 advisor
C'est la combinaison vers laquelle Anthropic semble orienter les utilisateurs, et après les tests, je comprends pourquoi. Sonnet 4.6 tourne comme ton modèle d'exécution. C'est rapide, c'est bon marché, c'est suffisamment bon pour 85% du travail de codage que je fais au quotidien. Quand il est bloqué, Opus 4.6 intervient comme advisor et applique son raisonnement plus profond au problème.
L'arithmétique des coûts ici est vraiment intéressante. Sonnet 4.6 coûte à peu près la moitié de ce que coûte Opus 4.6 par million de tokens. L'advisor n'est invoqué que sur des déclencheurs spécifiques, donc tu ne paies pas les tarifs Opus pour toute la session — juste pour les moments de blocage. Dans ma session du samedi, j'ai exécuté environ 42 tours de Sonnet 4.6 avec exactement 6 appels à l'advisor vers Opus 4.6. La répartition des tokens s'est avérée moins chère que d'exécuter Opus 4.6 comme modèle principal pour la même session, avec une marge qui compterait à l'échelle.
En termes de qualité ? J'ai obtenu des résultats comparables à ce qu'une session pure Opus 4.6 m'aurait donné, parce que chaque moment important avait Opus dans la boucle de toute façon.
Combinaison 2 : Opus 4.6 principal + Sonnet 4.6 advisor
C'est la combinaison inversée, que j'ai testée principalement par curiosité. Le résultat : pas génial. Sonnet 4.6 est un modèle capable, mais quand Opus 4.6 lutte déjà, demander à Sonnet d'auditer le raisonnement, c'est comme demander à un ingénieur junior de faire la revue de la décision d'architecture d'un ingénieur senior. Les appels à l'advisor revenaient avec soit de l'accord (« ton approche semble correcte ») soit des suggestions superficielles qu'Opus avait déjà considérées et écartées.
Je ne recommande pas cette configuration. Si Opus est ton modèle principal, il vaut mieux créer un sous-agent avec son propre context window pour gérer les moments de blocage — ce qui est, incidemment, l'approche que j'utilise par défaut quand j'exécute Opus comme exécuteur.
Combinaison 3 : Opus 4.6 principal + Opus 4.6 advisor
Oui, tu peux configurer le même modèle comme principal et advisor. Non, ce n'est pas inutile — mais ce n'est pas aussi puissant que les combinaisons qui utilisent des modèles distincts, parce que tu perds l'effet des yeux frais. L'avantage de l'advisor vient en partie d'aborder le problème sous un angle différent. Quand l'advisor est littéralement le même modèle avec les mêmes biais, la perspective nouvelle se réduit.
Cela dit, cette combinaison a quand même surpassé Opus sans supervision sur mon test d'erreurs récurrentes, parce que l'appel à l'advisor force une pause réflexive que le modèle principal n'aurait pas prise de lui-même. L'étape métacognitive compte même quand la cognition vient de la même source.
Le gagnant pour la plupart des développeurs : Sonnet 4.6 principal, Opus 4.6 advisor. Moins cher qu'Opus pur. Plus intelligent que Sonnet pur. Le flux de travail le plus propre que j'aie testé.
Parcourir un vrai appel à l'advisor, étape par étape
Laisse-moi te montrer exactement à quoi ça ressemble en pratique, parce que la description abstraite ne capture pas l'expérience. Je vais utiliser le scénario du bug de facturation parce que c'était mon cas de test le plus propre.
Étape 1 : Configurer l'advisor.
Dans Claude Code, j'ai exécuté la commande :
/advisor
L'invite est revenue en demandant quel modèle configurer. J'ai sélectionné Opus 4.6. Claude Code a confirmé : « Advisor configuré. Opus 4.6 sera consulté pour les décisions complexes et les vérifications de complétion de tâches. » C'est tout. Pas de configuration supplémentaire. Pas de paramètres d'échantillonnage. Pas de personnalisation du prompt.
Étape 2 : Lancer la tâche principale.
J'ai demandé à Claude Code (avec Sonnet 4.6 comme principal) d'auditer la logique de prorata dans ma classe SubscriptionBillingService et de corriger tous les bugs trouvés. Sonnet 4.6 a lu le fichier, a tracé le flux à travers trois classes dépendantes, et a proposé un correctif pour ce qu'il avait identifié comme une erreur de décalage par un dans le calcul des jours au prorata.
Étape 3 : Sonnet applique le correctif et exécute les tests.
Le correctif a passé 14 des 16 tests existants. Deux tests ont échoué — tous les deux liés à la gestion des fuseaux horaires aux limites de renouvellement. Sonnet a essayé un deuxième correctif. Les deux mêmes tests ont échoué. A essayé une troisième approche. Le même schéma d'échec.
C'est là que le déclencheur d'erreur récurrente se déclenche.
Étape 4 : Sonnet appelle /advisor.
La sortie console a rendu l'appel explicite :
[advisor invoked: recurring test failure on timezone-sensitive cases]
Pas d'interaction de ma part. Sonnet a fait l'appel de manière autonome. Opus 4.6 a reçu la transcription complète — ma demande originale, le contenu du fichier, les échecs de tests, les trois tentatives de correctif — et a retourné une analyse structurée.
Étape 5 : Le conseil revient.
La réponse d'Opus 4.6 a identifié deux problèmes que Sonnet avait manqués. D'abord : la logique de prorata utilisait le fuseau horaire local du serveur au lieu du fuseau horaire d'abonnement de l'utilisateur, ce qui signifiait que les renouvellements proches de minuit UTC étaient calculés dans la mauvaise période de facturation. Ensuite : les fixtures de test que Sonnet avait mis à jour étaient eux-mêmes incorrects, ce qui explique pourquoi les correctifs de Sonnet continuaient à paraître corrects mais les tests continuaient à échouer — les tests validaient le bug, pas le correctif.
Aucun des deux problèmes n'était évident à partir de l'analyse solo de Sonnet. Les deux étaient évidents avec le recul une fois qu'Opus les avait pointés.
Étape 6 : Sonnet intègre le conseil.
Sonnet 4.6 n'a pas juste copié la réponse de l'advisor mot pour mot. Il a pris l'orientation, réécrit la logique de prorata pour utiliser le fuseau horaire de l'utilisateur, puis a indépendamment signalé le problème de fixture de test pour ma revue — « L'advisor a noté que les fixtures valident peut-être un comportement incorrect. Je recommande de revoir tests/Unit/ProrationTest.php lignes 84-110 avant de les modifier, car cela change la sémantique des tests. »
Cette dernière partie est le comportement qui m'a convaincu du /advisor. Sonnet n'a pas appliqué le conseil aveuglément. Il s'est arrêté à l'endroit où le conseil avait des implications sur lesquelles je devais me prononcer.
Étape 7 : Vérification.
J'ai approuvé la revue des fixtures. Sonnet a mis à jour les tests, a réexécuté la suite, et les 16 tests ont passé. Temps total de la première correction échouée jusqu'à l'exécution des tests au vert : moins de quatre minutes. Temps de débogage manuel que j'aurais passé sur le même problème, en me basant sur le temps depuis lequel j'étais bloqué : probablement encore deux heures.
Les conseils pro dont personne ne parle encore
Quelques choses apprises lors des tests qui ne figurent pas dans la documentation de l'annonce.
Conseil 1 : Les appels à l'advisor apparaissent dans le registre de tokens, mais comme un poste séparé. Tu peux voir exactement combien l'advisor a coûté par rapport au modèle principal. C'est étonnamment utile pour calibrer si la fonctionnalité vaut son poids sur un projet donné. Je suis le ratio sur mes projets de test et je publierai probablement les données dans un article de suivi.
Conseil 2 : L'advisor persiste à travers les opérations /compact. Si tu compactes ta conversation pour libérer du contexte, l'orientation antérieure de l'advisor survit à la compaction. C'est un petit détail avec de grandes implications pour les sessions longues — ton advisor devient effectivement une couche de connaissance cumulative.
Conseil 3 : Tu peux réexécuter /advisor pour changer de modèles en milieu de session. Je ne m'en étais pas rendu compte au début, mais tu peux changer ta configuration d'advisor à mi-chemin d'une session sans redémarrer. Je l'ai utilisé pour passer d'Opus-comme-advisor à un Opus-comme-advisor frais après un /compact pour remettre à zéro l'état accumulé de l'advisor.
Conseil 4 : Le déclencheur de l'advisor peut être orienté. Bien que tu ne puisses pas forcer un appel, tu peux rendre le modèle principal plus susceptible d'invoquer l'advisor en étant explicite dans ton prompt. Des phrases comme « vérifie ça avec l'advisor avant de valider » ou « si tu es bloqué, consulte l'advisor » ont augmenté de manière mesurable le taux d'appel dans mes tests. Pas une garantie — mais un levier utile.
Conseil 5 : Surveille le comportement de boucle de l'advisor. Lors d'un test, Sonnet 4.6 a appelé Opus 4.6 trois fois de suite sur le même problème, recevant à chaque fois un conseil légèrement différent et se sentant à chaque fois moins sûr de sa direction. C'est le mode d'échec à surveiller. Si tu vois l'advisor appelé à plusieurs reprises sans progrès, interviens manuellement. La couche métacognitive est précieuse, mais ce n'est pas un substitut au jugement humain quand le modèle est vraiment perdu.
Franchise totale : Pourquoi je préfère toujours les sous-agents pour les flux de travail Opus
Voici la partie honnête. Pour mon vrai flux de travail quotidien — où j'exécute Opus 4.6 comme modèle principal sur des architectures d'agents complexes — je préfère toujours les sous-agents avec des context windows indépendants au /advisor. Laisse-moi expliquer pourquoi, parce que le compromis est important.
Quand je crée un sous-agent, cet agent commence avec un contexte propre. Pas de conversation accumulée. Pas de cadrage biaisé des tentatives précédentes du modèle principal. Juste le prompt que je lui donne et les outils que j'autorise. Cette propreté est souvent la différence entre une orientation utile et des conseils qui ne font que renvoyer en écho les angles morts du modèle principal.
La commande /advisor, en revanche, fournit la transcription complète à l'advisor à chaque fois. Si le modèle principal est bloqué parce qu'il cadre mal le problème, l'advisor voit le même mauvais cadrage et peut ou non s'en échapper. Opus est meilleur pour s'échapper des pièges de cadrage que Sonnet, ce qui explique pourquoi la combinaison Sonnet-principal + Opus-advisor fonctionne si bien — Opus apporte assez de puissance pour recadrer. Mais quand Opus est ton modèle principal et que le cadrage est le problème, l'advisor peut être entraîné dans le même piège.
J'ai testé ça directement. J'ai donné à Opus 4.6 un problème d'architecture délibérément mal cadré et j'ai configuré Opus 4.6 comme advisor. L'advisor a accepté le cadrage. J'ai ensuite créé un sous-agent Opus 4.6 frais avec seulement les exigences originales (pas de transcription) et j'ai posé la même question. Le sous-agent a immédiatement recadré le problème et proposé une solution différente.
Même modèle. Même problème. Résultats différents selon la fraîcheur du contexte.
Donc voici ma vraie règle empirique : utilise /advisor quand ton modèle principal est Sonnet et que tu veux un filet de sécurité Opus. Utilise des sous-agents quand ton modèle principal est Opus et que tu veux un vrai raisonnement parallèle. Utilise les deux quand tu travailles sur quelque chose à hauts enjeux.
Et sois honnête avec toi-même sur le mode dans lequel tu te trouves. Les paramètres par défaut de la fonctionnalité sont intelligents, mais ils ne sont pas magiques.
Pourquoi /advisor parle vraiment de Mythos
Maintenant la partie vers laquelle je construisais.
Je ne pense pas que /advisor existe parce que l'équipe Claude Code voulait livrer une couche métacognitive pour Sonnet et Opus. Je pense que /advisor existe parce qu'Anthropic prépare l'infrastructure pour Mythos — le modèle qui a commencé à fuiter dans les conversations publiques il y a quelques semaines et sur lequel j'ai déjà écrit dans l'analyse de la fuite Claude Mythos — et ils avaient besoin d'un moyen de rendre un modèle à coût élevé et haute puissance économiquement viable dans Claude Code.
Penses-y. Si Mythos arrive au point de prix que les fuites suggèrent — significativement au-dessus d'Opus 4.6 — l'exécuter comme modèle principal pour toute une session sera prohibitif pour la plupart des développeurs. Même pour le travail en agence, les marges ne fonctionneront pas pour chaque tâche. Alors comment donnes-tu aux utilisateurs accès à la puissance de Mythos sans les obliger à payer les tarifs Mythos pour chaque token ?
Tu les laisses le configurer comme advisor.
Imagine la combinaison : Sonnet 4.6 comme ton modèle d'exécution, fonctionnant rapidement et à moindre coût pour la majorité de tes tokens. Mythos comme ton advisor, invoqué uniquement aux moments critiques — avant les grands commits, quand les tests continuent à échouer, quand le modèle est sur le point de faire un saut interprétatif. Tu obtiens un jugement de niveau Mythos sur les décisions qui comptent le plus, à une fraction du coût d'exécuter Mythos comme modèle principal.
C'est le schéma. /advisor est l'échafaudage. La combinaison Sonnet/Opus que nous avons aujourd'hui est le test bêta de la combinaison Sonnet/Mythos qui arrive.
Je pourrais me tromper là-dessus. Il est possible que /advisor soit juste une fonctionnalité autonome et que l'intégration de Mythos ait l'air complètement différente. Mais les choix d'architecture racontent une histoire. La liste d'autorisation de modèles stricte (actuellement deux modèles). Le partage de contexte automatique. Le comportement de détection de conflits qui remonte les désaccords de l'advisor à la surface plutôt que de s'y déférer. Ce sont toutes des décisions de conception qui ont parfaitement du sens si ton objectif final est un système de modèles par niveaux où le modèle de niveau le plus élevé est assez cher pour que tu veuilles seulement le consulter sur les problèmes les plus difficiles.
Et si j'ai raison là-dessus, les développeurs qui apprendront /advisor maintenant auront une longueur d'avance considérable quand Mythos arrivera. Les schémas de flux de travail que tu construis autour de Sonnet-principal + Opus-advisor se transféreront presque directement à Sonnet-principal + Mythos-advisor, avec seulement la configuration qui change. Les habitudes de prompt, la conscience des déclencheurs, le cadre de décision sous-agent-versus-advisor — tout se transfère.
Si tu veux un regard plus approfondi sur ce que Mythos pourrait apporter, j'ai écrit sur les implications dans mon plongeon en profondeur sur Mythos et l'autonomie des modèles. Mais la version courte : quoi que Mythos s'avère être, ce sera coûteux, et /advisor est la façon dont tu y accèderas sans te ruiner.
Ce que je te recommanderais de faire aujourd'hui
Si tu es déjà sur Claude Code et que tu utilises Sonnet 4.6 pour la plupart de ton travail, active /advisor avec Opus 4.6 comme advisor maintenant. Fais-le tourner sur un vrai projet cette semaine. Fais attention à la fréquence à laquelle l'advisor est appelé et à quels types de problèmes le déclenchent. Cette reconnaissance de schémas est la vraie valeur — pas les premières fois où il te sauve d'un bug, mais la compréhension progressive de quand ton modèle a probablement besoin d'un deuxième avis.
Si tu exécutes Opus 4.6 comme modèle principal, je recommanderais quand même d'activer /advisor avec Opus comme advisor, mais en parallèle avec tes flux de travail de sous-agents existants. Ne remplace pas les sous-agents. Augmente-les. Utilise /advisor pour les deuxièmes avis légers et inline et les sous-agents pour le raisonnement parallèle plus lourd.
Si tu n'as pas encore mis à jour vers Sonnet 4.6 ou Opus 4.6, fais ça d'abord. La commande advisor les requiert. Les modèles plus anciens ne sont pas sur la liste d'autorisation et ne le seront pas — la fonctionnalité est explicitement conçue pour la génération actuelle.
Encore une chose. Si tu es sur ma liste de diffusion ou que tu suis mon blog, je vais suivre les schémas d'utilisation de /advisor au cours des prochaines semaines et publier les données. Ratios de coûts, fréquences de déclenchement, vrais résultats sur de vrais projets. Le genre de données qui te dit si cette fonctionnalité gagne sa place dans ton flux de travail ou si c'est un nice-to-have que tu peux ignorer. Si tu veux ces données avant qu'elles soient publiques, la meilleure façon de les obtenir est de commencer tes propres tests maintenant — parce qu'au moment où je publierai mes conclusions, Mythos sera probablement à quelques semaines de changer complètement l'équation.
La commande /advisor n'est pas la plus grande fonctionnalité que Claude Code ait livrée cette année. Ce n'est peut-être même pas la plus utile un jour donné. Mais c'est la plus structurellement importante, parce que c'est la première fois qu'Anthropic a construit une infrastructure explicite pour la collaboration multi-modèles au sein d'une seule session, et cette infrastructure va compter énormément une fois que le niveau de modèles au-dessus d'Opus existera réellement.
Le bug de facturation que j'ai mis trois jours à trouver ? Sonnet et Opus l'ont trouvé en quatre minutes d'analyse assistée par advisor. Ce n'est pas la fin de l'histoire. C'est le début d'un schéma de flux de travail que j'utiliserai pendant des années.
Commence à construire l'habitude maintenant. Tu seras content de l'avoir fait quand le prochain modèle sortira.
Questions fréquemment posées
Qu'est-ce que le slash command /advisor de Claude Code ?
Le slash command /advisor te permet de configurer un modèle Claude secondaire qui est automatiquement invoqué par ton modèle principal quand il rencontre des décisions complexes, des erreurs récurrentes ou des points de contrôle de complétion de tâches. Il supporte actuellement uniquement Sonnet 4.6 et Opus 4.6. L'advisor reçoit la transcription complète de la conversation et retourne des orientations qui sont repliées dans le contexte partagé de la session.
Quelle combinaison de modèles dois-je utiliser avec /advisor ?
Pour la plupart des développeurs : utilise Sonnet 4.6 comme modèle principal et Opus 4.6 comme advisor. Cette combinaison te donne la vitesse et l'efficacité de coût de Sonnet pour le travail de routine tout en réservant le raisonnement plus profond d'Opus pour les moments qui comptent. J'ai testé les trois combinaisons viables et celle-ci a produit le meilleur rapport coût-qualité sur de vraies tâches de refactorisation.
Est-ce que /advisor fonctionne avec les sous-agents ?
Oui, mais ils servent des objectifs différents. /advisor fournit la transcription complète à un modèle secondaire en ligne, tandis que les sous-agents fonctionnent avec des context windows propres et indépendants. Utilise /advisor quand ton modèle principal est Sonnet. Utilise des sous-agents quand ton modèle principal est Opus et que tu as besoin d'une perspective fraîche, libre du cadrage du modèle principal.
L'advisor peut-il accéder aux fichiers ou exécuter des commandes ?
Non. L'advisor n'a pas accès au système de fichiers, au shell, au web ou aux serveurs MCP. Il raisonne uniquement sur l'historique de conversation qu'il reçoit du modèle principal. C'est une limite architecturale dure dans l'implémentation actuelle, pas une permission configurable.
Est-ce que /advisor est moins cher qu'exécuter Opus 4.6 comme modèle principal ?
Dans mes tests, oui — une session Sonnet 4.6 de 42 tours avec 6 appels à l'advisor Opus 4.6 s'est avérée moins chère qu'exécuter Opus 4.6 comme modèle principal pour la même charge de travail. Les économies proviennent de l'utilisation du modèle moins cher pour la majorité des tokens et du paiement de tarifs premium uniquement sur les invocations de l'advisor.
Travaillons ensemble
Tu cherches à construire des systèmes IA, automatiser des flux de travail ou faire monter en charge ton infrastructure tech ? Je serais ravi de t'aider.
- Fiverr (builds et intégrations personnalisés) : fiverr.com/s/EgxYmWD
- Portfolio : mejba.me
- Ramlit Limited (solutions entreprise) : ramlit.com
- ColorPark (design & branding) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
