Claude Code /advisor Command: Een Tweede Brein voor Vastgelopen Modellen
Ik bracht een volledige zaterdag door met het proberen te breken van het nieuwe /advisor command van Claude Code.
Niet in de zin van "zoek de bug en maak een ticket aan." Eerder in de zin van: "Ik heb me al zo vaak gebrand aan glanzende nieuwe slash commands dat ik er geen enkel meer vertrouw totdat ik er lelijke productiecode op heb losgelaten." Mijn testomgeving was een facturatieservice die ik al weken aan het refactoren ben — een Laravel 11-app met het soort randgevallen dat elke zwakte in een AI-codeermodel blootlegt. Proportionele upgrades. Downgrades midden in een cyclus. Dunning-logica die een gedeeltelijke Stripe webhook-storing moet overleven.
Het resultaat verraste me. Niet omdat /advisor me van een catastrofe redde — dat deed het niet. Maar omdat het twee problemen opving die ik al drie dagen aanstaarde zonder ze te zien. Een logicafout in het proratavenster en een subtiele tijdzonebug in de verlengingsberekening. Sonnet 4.6 draaide als mijn hoofduitvoerder. Toen het op mijn derde doorkijk het stalpatroon bereikte, riep het Opus 4.6 aan via /advisor en keerde terug met een tweealinea-analyse die aanvoelde als een code review van een senior engineer.
Op dat moment besefte ik dat dit command niet echt over advies gaat. Het gaat over Anthropic die steigers bouwt voor Mythos.
Laat me uitleggen wat ik bedoel — en waarom het /advisor slash command misschien de belangrijkste feature is die Claude Code dit kwartaal heeft uitgebracht, ook al zullen de meeste ontwikkelaars het afdoen als een kleine kwaliteitsverbetering.
Wat /advisor Werkelijk Doet (En Wat Niet)
Het /advisor command laat je een secundair model instellen dat wordt aangeroepen wanneer je primaire model in de problemen komt. Dat is de elevator pitch. De werkelijkheid is genuanceerder, en de nuance doet ertoe.
Zo werkt de huidige setup. Je voert /advisor uit binnen Claude Code, kiest een model uit de lijst (momenteel Sonnet 4.6 of Opus 4.6 — geen andere opties, geen aangepaste endpoints, geen Haiku), en vanaf dat moment heeft Claude Code de mogelijkheid om dat model zelfstandig aan te roepen wanneer het besluit dat het een tweede mening nodig heeft. Je roept de advisor niet handmatig aan. Je typt niet "vraag de advisor hierover." Het primaire model maakt die beslissing autonoom op basis van contextsignalen.
Dat laatste deel struikelde ik over de eerste keer. Ik bleef een prompt of een bevestigingsdialoog verwachten. Die is er niet. De advisor-aanroep gebeurt stilletjes, midden in een reactie, en het advies wordt terug in de sessiecontext gevouwen alsof het er altijd al was.
Drie dingen die je moet begrijpen over hoe dit werkelijk werkt:
De advisor heeft volledige conversatiecontext. Wanneer het primaire model /advisor aanroept, ontvangt het secundaire model het volledige transcript — je oorspronkelijke verzoek, elke tool-aanroep, elk gelezen bestand, elke commandouitvoer, elke redenerstap. Geen parameters. Geen filtering. Geen cherry-picking. Het ziet wat jouw hoofdmodel zag, in dezelfde volgorde, met dezelfde beperkingen.
De advisor kan de buitenwereld niet aanraken. Geen toegang tot het bestandssysteem. Geen shell-commando's. Geen webverzoeken. Geen MCP-servers. De advisor bestaat puur om over de gespreksgeschiedenis te redeneren en begeleiding te bieden. Dit is een harde architectonische grens, geen toestemming die je kunt omzetten.
Het advies wordt deel van gedeeld geheugen. Zodra de advisor reageert, blijft zijn analyse in de sessiecontext aanwezig. Latere advisor-aanroepen zien eerder advies. Als empirische resultaten in tegenspraak zijn met wat de advisor aanbeval, brengt Claude Code het conflict in beeld in plaats van de begeleiding stilzwijgend te overschrijven. Je krijgt een expliciet "de advisor zei X, maar de testuitvoer toont Y — zullen we opnieuw raadplegen?" moment.
Dat derde gedrag was het gedrag dat ik niet verwachtte, en het is het gedrag dat mijn mening over de feature veranderde.
De Vier Triggers Die de Advisor Aanroepen
Ik bracht het eerste uur van het testen door met uitzoeken wanneer Claude Code daadwerkelijk naar de advisor grijpt. De documentatie is schaars. Het gedrag is deels emergent. Dus ik voerde een heleboel gecontroleerde scenario's uit en bekeek de logs.
Vier patronen activeren een advisor-aanroep betrouwbaar. Als je deze begrijpt, weet je of /advisor het waard is om in te schakelen voor je workflow of dat het gewoon contexttokens gaat verbruiken die het nooit gebruikt.
Trigger 1: Vóór substantieel schrijven of interpretatie. Wanneer het model op het punt staat een aanzienlijk stuk code te schrijven, een nieuw bestand te genereren of een interpretatiesprong te maken van vereisten naar implementatie, pauzeert het en vraagt het de advisor eerst om een sanity check. Dit is het "twee keer meten, één keer snijden" patroon. Eenvoudige reactieve taken — een variabele hernoemen, een typefout corrigeren, een marge aanpassen — slaan dit volledig over.
Trigger 2: Op de vermeende finishlijn. Wanneer het hoofdmodel gelooft dat de taak voltooid is, roept het de advisor aan om de uitvoer te controleren voordat het succes verklaart. Dit ving een bug in mijn factureringscode die Sonnet 4.6 zichzelf had wijsgemaakt dat die opgelost was. De advisor signaleerde een ontbrekend randgeval in de proratalogica, en Sonnet ging terug en herstelde het zonder dat ik een woord zei.
Trigger 3: Terugkerende fouten of niet-convergerende loops. Als het model dezelfde oplossing drie keer probeert en de tests blijven falen, of als het heen en weer stuitert tussen twee incompatibele benaderingen, wordt de advisor ingeschakeld. Dit is het patroon dat me het meest interesseert omdat het het patroon is dat vroeger mijn hele middag opslokte. Je kent de loop — het model repareert het ene, breekt het andere, repareert dat, regressiont het eerste, en uiteindelijk moet je handmatig ingrijpen en de hele boel ontwarren.
Trigger 4: Checkpoints bij meerfasige taken. Voor elke taak met meerdere fasen (het soort waarbij Claude Code aan het begin een takenlijst opbouwt), wordt de advisor minstens twee keer aangeroepen. Eén keer vóór het vastleggen van substantieel werk. Eén keer bij voltooiing. Dit is het standaard vangnet voor de workflows waarbij het vaakst misgaat.
Wat activeert een advisor-aanroep niet? Kleine UI-aanpassingen. Eenmalige refactors. Reactieve oplossingen voor eenvoudige problemen. Alles waar het primaire model zeker over is. Het systeem is bewust conservatief — het wil geen tokens verbranden aan problemen die geen tweede mening nodig hebben.
Maar er is een addertje onder het gras bij die conservatisme. Als je primaire model overmoedig is — en iedereen die Sonnet 4.6 lang genoeg heeft gebruikt weet dat het zo kan zijn — wordt de advisor niet aangeroepen wanneer dat zou moeten. Het oordeel om de advisor aan te roepen leeft binnenin hetzelfde model waarvan je het oordeel probeert te controleren. Dat is een ontwerpspanning die ik denk dat nog niet volledig opgelost is, en ik kom er op terug in het "eerlijke verhaal" gedeelte.
Laat me nu laten zien hoe de werkelijke modelkoppelingen er in de praktijk uitzien.
De Drie Koppelingen Die Ik Testte (En Welke Wint)
Er zijn eigenlijk maar drie manieren om /advisor te configureren op dit moment, en ik heb alle drie uitgevoerd op dezelfde factureringsrefactor gedurende het weekend. Dit is wat ik vond.
Koppeling 1: Sonnet 4.6 Hoofd + Opus 4.6 Advisor
Dit is de koppeling die Anthropic gebruikers naar lijkt te sturen, en na het testen begrijp ik waarom. Sonnet 4.6 draait als je uitvoeringsmodel. Het is snel, het is goedkoop, het is goed genoeg voor 85% van het codeerwerk dat ik dagelijks doe. Wanneer het vastloopt, valt Opus 4.6 in als advisor en brengt zijn diepere redenering toe op het probleem.
De kostenrekenkunde hiervan is werkelijk interessant. Sonnet 4.6 kost ruwweg de helft van wat Opus 4.6 kost per miljoen tokens. De advisor wordt alleen aangeroepen bij specifieke triggers, dus je betaalt geen Opus-tarieven voor de hele sessie — alleen de vastgelopen momenten. In mijn zaterdagsessie draaide ik ongeveer 42 beurten van Sonnet 4.6 met precies 6 advisor-aanroepen naar Opus 4.6. De tokenopsplitsing bleek goedkoper dan het uitvoeren van Opus 4.6 als hoofdmodel voor dezelfde sessie, met een marge die op schaal telt.
Qua kwaliteit? Ik kreeg resultaten vergelijkbaar met wat een pure Opus 4.6-sessie me zou hebben gegeven, omdat elk moment dat ertoe deed Opus sowieso in de loop had.
Koppeling 2: Opus 4.6 Hoofd + Sonnet 4.6 Advisor
Dit is de omgekeerde koppeling, en ik heb het voornamelijk uit nieuwsgierigheid getest. Het resultaat: niet geweldig. Sonnet 4.6 is een capabel model, maar wanneer Opus 4.6 al moeite heeft, is Sonnet vragen om de redenering te controleren als een junior engineer vragen om de architectuurbeslissing van een senior engineer te code-reviewen. De advisor-aanroepen kwamen terug met ofwel instemming ("je aanpak ziet er correct uit") of oppervlakkige suggesties die Opus al had overwogen en verworpen.
Ik raad deze configuratie niet aan. Als Opus je hoofdmodel is, kun je beter een subagent spawnen met zijn eigen context window om de vastgelopen momenten te behandelen — wat toevallig de aanpak is die ik standaard gebruik wanneer ik Opus als uitvoerder gebruik.
Koppeling 3: Opus 4.6 Hoofd + Opus 4.6 Advisor
Ja, je kunt hetzelfde model instellen als zowel hoofd als advisor. Nee, het is niet nutteloos — maar het is niet zo krachtig als de koppelingen die verschillende modellen gebruiken, omdat je het frisse-ogen-effect verliest. Het voordeel van de advisor komt deels van het benaderen van het probleem vanuit een andere hoek. Wanneer de advisor letterlijk hetzelfde model is met dezelfde vooroordelen, krimpt het nieuwe perspectief.
Dat gezegd hebbende, presteerde deze koppeling nog steeds beter dan onbegeleide Opus op mijn terugkerende-fout-test, omdat de advisor-aanroep een reflectieve pauze afdwingt die het hoofdmodel uit zichzelf niet zou hebben genomen. De metacognitieve stap is waardevol, zelfs wanneer de cognitie uit dezelfde bron komt.
De winnaar voor de meeste ontwikkelaars: Sonnet 4.6 hoofd, Opus 4.6 advisor. Goedkoper dan pure Opus. Slimmer dan pure Sonnet. Schoonste workflow die ik heb getest.
Stap voor Stap door een Echte Advisor-Aanroep Lopen
Laat me je precies laten zien hoe dit er in de praktijk uitziet, want de abstracte beschrijving vangt de ervaring niet. Ik gebruik het factureringsscenario omdat het mijn schoonste testgeval was.
Stap 1: Configureer de advisor.
Binnen Claude Code voerde ik het commando uit:
/advisor
De prompt vroeg terug welk model te configureren. Ik selecteerde Opus 4.6. Claude Code bevestigde: "Advisor geconfigureerd. Opus 4.6 zal worden geraadpleegd voor complexe beslissingen en taakvoltooiingscontroles." Dat is het. Geen verdere configuratie. Geen samplingparameters. Geen prompt-aanpassing.
Stap 2: Start de hoofdtaak.
Ik vroeg Claude Code (Sonnet 4.6 als hoofd) om de proratalogica in mijn SubscriptionBillingService-klasse te controleren en eventuele bugs te repareren. Sonnet 4.6 las het bestand, volgde de flow door drie afhankelijke klassen, en stelde een oplossing voor voor wat het identificeerde als een off-by-one fout in de berekening van de proratadagen.
Stap 3: Sonnet past de oplossing toe en voert tests uit.
De oplossing slaagde voor 14 van de 16 bestaande tests. Twee tests faalden — beide gerelateerd aan tijdzoneafhandeling op verlengingsgrenzen. Sonnet probeerde een tweede oplossing. Dezelfde twee tests faalden. Probeerde een derde aanpak. Hetzelfde faalpatroon.
Dit is waar de terugkerende-fout-trigger afgaat.
Stap 4: Sonnet roept /advisor aan.
De consoleuitvoer maakte de aanroep expliciet:
[advisor invoked: recurring test failure on timezone-sensitive cases]
Geen interactie van mijn kant. Sonnet maakte de aanroep autonoom. Opus 4.6 ontving het volledige transcript — mijn oorspronkelijke verzoek, de bestandsinhoud, de testfouten, alle drie geprobeerde oplossingen — en retourneerde een gestructureerde analyse.
Stap 5: Het advies komt terug.
Opus 4.6's reactie identificeerde twee problemen die Sonnet had gemist. Ten eerste: de proratalogica gebruikte de lokale tijdzone van de server in plaats van de abonnementstijdzone van de gebruiker, wat betekende dat verlengingen nabij UTC middernacht werden berekend in de verkeerde factureringsperiode. Ten tweede: de testfixtures die Sonnet had bijgewerkt waren zelf verkeerd, waardoor Sonnet's oplossingen er correct bleven uitzien maar de tests bleven falen — de tests valideerden de bug, niet de oplossing.
Geen van beide problemen was duidelijk vanuit Sonnet's solo-analyse. Beide waren duidelijk in retrospect zodra Opus ze aanwees.
Stap 6: Sonnet integreert het advies.
Sonnet 4.6 kopieerde het antwoord van de advisor niet zomaar woordelijk. Het nam de begeleiding, herschreef de proratalogica om de tijdzone van de gebruiker te gebruiken, en markeerde vervolgens onafhankelijk het testfixture-probleem voor mijn beoordeling — "De advisor merkte op dat de fixtures mogelijk onjuist gedrag valideren. Ik raad aan om tests/Unit/ProrationTest.php regels 84-110 te bekijken voordat ik ze aanpas, aangezien dit de testsemantiek verandert."
Dat laatste deel is het gedrag dat me voor /advisor gewon. Sonnet paste het advies niet blind toe. Het pauzeerde op de plek waar het advies implicaties had waarover ik mee moest beslissen.
Stap 7: Verificatie.
Ik keurde de fixture-beoordeling goed. Sonnet werkte de tests bij, voerde de suite opnieuw uit, en alle 16 tests slaagden. Totale tijd van de eerste mislukte oplossing tot de groene testrun: minder dan vier minuten. Handmatige debugtijd die ik aan hetzelfde probleem zou hebben besteed, gebaseerd op hoe lang ik er al mee bezig was: waarschijnlijk nog twee uur.
De Pro Tips Die Niemand Nog Bespreekt
Een paar dingen die ik leerde tijdens het testen die niet in de aankondigingsdocumentatie staan.
Tip 1: Advisor-aanroepen verschijnen in het tokenoverzicht, maar als een apart regelitem. Je kunt precies zien hoeveel de advisor kostte versus het hoofdmodel. Dit is verrassend nuttig voor het kalibreren of de feature zijn waarde verdient op een bepaald project. Ik volg de verhouding over mijn testprojecten en zal de data waarschijnlijk publiceren in een vervolgpost.
Tip 2: De advisor blijft bestaan na /compact bewerkingen. Als je je conversatie compact om context vrij te maken, overleeft de eerdere begeleiding van de advisor de compactie. Dit is een klein detail met grote gevolgen voor lange sessies — je advisor wordt effectief een cumulatieve kennislaag.
Tip 3: Je kunt /advisor opnieuw uitvoeren om modellen te wisselen midden in een sessie. Ik realiseerde dit niet meteen, maar je kunt je advisor-configuratie halverwege een sessie wisselen zonder opnieuw te starten. Ik gebruikte dit om van Opus-als-advisor naar een verse Opus-als-advisor te gaan na een /compact om de geaccumuleerde staat van de advisor te resetten.
Tip 4: De advisor-trigger kan worden aangestuurd. Hoewel je een aanroep niet kunt forceren, kun je het hoofdmodel eerder de advisor laten aanroepen door expliciet te zijn in je prompt. Zinnen als "controleer dit met de advisor voordat je vastlegt" of "als je vastloopt, raadpleeg de advisor" verhoogden de aanroepfrequentie meetbaar in mijn tests. Geen garantie — maar een nuttige hendel.
Tip 5: Let op advisor-loop-gedrag. In één test riep Sonnet 4.6 Opus 4.6 drie keer achter elkaar aan voor hetzelfde probleem, elke keer met iets ander advies en elke keer minder zeker over zijn richting. Dit is het faalmodus om op te letten. Als je de advisor herhaaldelijk ziet worden aangeroepen zonder voortgang, grijp handmatig in. De metacognitieve laag is waardevol, maar het is geen vervanging voor menselijk oordeel wanneer het model werkelijk verloren is.
Eerlijk Verhaal: Waarom Ik Nog Steeds Standaard Naar Subagents Ga voor Opus-Workflows
Hier is het eerlijke deel. Voor mijn werkelijke dagelijkse workflow — waarbij ik Opus 4.6 als mijn hoofdmodel gebruik op complexe agent-architecturen — geef ik nog steeds de voorkeur aan subagents met onafhankelijke context windows boven /advisor. Laat me uitleggen waarom, want de afweging is belangrijk.
Wanneer ik een subagent spawn, begint die agent met een schone context. Geen geaccumuleerde conversatie. Geen bevooroordeelde framing van de eerdere pogingen van het hoofdmodel. Alleen de prompt die ik hem geef en de tools die ik autoriseer. Die schoonheid is vaak het verschil tussen nuttige begeleiding en advies dat alleen de blinde vlekken van het hoofdmodel terugkaatst.
Het /advisor command daarentegen stuurt het volledige transcript elke keer naar de advisor. Als het hoofdmodel vastloopt omdat het het probleem verkeerd framt, ziet de advisor dezelfde verkeerde framing en kan al dan niet ontsnappen. Opus is beter in het ontsnappen uit framingsvallen dan Sonnet, wat is waarom de Sonnet-hoofd + Opus-advisor koppeling zo goed werkt — Opus brengt genoeg kracht om te herkadreren. Maar wanneer Opus je hoofdmodel is en de framing het probleem is, kan de advisor in dezelfde val worden getrokken.
Ik heb dit direct getest. Ik gaf Opus 4.6 een bewust verkeerd geframed architectuurprobleem en configureerde Opus 4.6 als de advisor. De advisor stemde in met de framing. Vervolgens spawnte ik een verse Opus 4.6-subagent met alleen de oorspronkelijke vereisten (geen transcript) en stelde dezelfde vraag. De subagent herkaderde het probleem onmiddellijk en stelde een andere oplossing voor.
Hetzelfde model. Hetzelfde probleem. Verschillende resultaten op basis van de versheid van de context.
Dus hier is mijn werkelijke vuistregel: gebruik /advisor wanneer je hoofdmodel Sonnet is en je een Opus vangnet wilt. Gebruik subagents wanneer je hoofdmodel Opus is en je echte parallelle redenering wilt. Gebruik beide wanneer je aan iets met hoge inzet werkt.
En wees eerlijk tegen jezelf over in welke modus je je bevindt. De standaardwaarden van de feature zijn slim, maar ze zijn geen magie.
Waarom /advisor Werkelijk Over Mythos Gaat
Nu het deel waar ik naartoe aan het bouwen was.
Ik denk niet dat /advisor bestaat omdat het Claude Code-team een metacognitieve laag voor Sonnet en Opus wilde uitbrengen. Ik denk dat /advisor bestaat omdat Anthropic de infrastructuur voorbereidt voor Mythos — het model dat een paar weken geleden begon door te sijpelen in publieke gesprekken en dat ik al heb behandeld in de Claude Mythos lek-analyse — en ze hadden een manier nodig om een high-cost, high-power model economisch levensvatbaar te maken binnen Claude Code.
Denk er over na. Als Mythos landt op het prijspunt dat de lekken suggereren — aanzienlijk boven Opus 4.6 — zal het draaien als je hoofdmodel voor een hele sessie voor de meeste ontwikkelaars onbetaalbaar zijn. Zelfs voor bureauwerk zullen de marges niet kloppen voor elke taak. Dus hoe geef je gebruikers toegang tot Mythos's kracht zonder hen te dwingen Mythos-tarieven te betalen voor elk token?
Je laat ze het configureren als een advisor.
Stel je de koppeling voor: Sonnet 4.6 als je uitvoeringsmodel, snel en goedkoop draaiend voor de meerderheid van je tokens. Mythos als je advisor, alleen aangeroepen op de kritieke momenten — vóór grote commits, wanneer de tests blijven falen, wanneer het model op het punt staat een interpretatiesprong te maken. Je krijgt oordeel op Mythos-niveau op de beslissingen die het meest tellen, tegen een fractie van de kosten van het draaien van Mythos als het hoofdmodel.
Dit is het patroon. /advisor is de steigers. De Sonnet/Opus-koppeling die we vandaag hebben is de betatest voor de Sonnet/Mythos-koppeling die eraan komt.
Ik kan hier mis over zitten. Het is mogelijk dat /advisor gewoon een op zichzelf staande feature is en Mythos-integratie er volledig anders uit zal zien. Maar de architectuurkeuzes vertellen een verhaal. De harde model-toegestane lijst (momenteel twee modellen). Het automatisch delen van context. Het conflictdetectiegedrag dat advisor-meningsverschillen in beeld brengt in plaats van er aan toe te geven. Dit zijn allemaal ontwerpbeslissingen die perfect logisch zijn als je einddoel een gelaagd modelsysteem is waarbij het hoogste model duur genoeg is dat je het alleen wilt raadplegen op de moeilijkste problemen.
En als ik hier gelijk in heb, zullen de ontwikkelaars die /advisor nu leren een enorme voorsprong hebben wanneer Mythos landt. De workflow-patronen die je opbouwt rondom Sonnet-hoofd + Opus-advisor zullen bijna direct overdragen naar Sonnet-hoofd + Mythos-advisor, waarbij alleen de configuratie verandert. De promptgewoonten, het trigger-bewustzijn, het subagent-versus-advisor beslissingskader — dat alles gaat mee.
Als je een diepere blik wilt op wat Mythos zou kunnen brengen, heb ik geschreven over de implicaties in mijn Mythos deep dive over modelautonomie. Maar de korte versie: wat Mythos ook blijkt te zijn, het zal duur zijn, en /advisor is hoe je er toegang toe krijgt zonder bankroet te gaan.
Wat Ik Je Vandaag Zou Aanraden
Als je al op Claude Code zit en Sonnet 4.6 gebruikt voor het meeste van je werk, schakel /advisor in met Opus 4.6 als de advisor nu meteen. Gebruik het op één echt project deze week. Let op hoe vaak de advisor wordt aangeroepen en welke soorten problemen het activeren. Die patroonherkenning is de echte waarde — niet de eerste paar keer dat het je van een bug redt, maar het geleidelijke begrip van wanneer je model waarschijnlijk een tweede mening nodig heeft.
Als je Opus 4.6 als je hoofdmodel gebruikt, zou ik nog steeds aanraden om /advisor in te schakelen met Opus als de advisor, maar parallel aan je bestaande subagent-workflows. Vervang subagents niet. Verbeter ze. Gebruik /advisor voor de lichte, inline tweede meningen en subagents voor het zwaardere parallelle redeneren.
Als je nog niet hebt geüpgraded naar Sonnet 4.6 of Opus 4.6, doe dat eerst. Het advisor-command vereist ze. Oudere modellen staan niet op de toegestane lijst en zullen dat niet worden — de feature is expliciet ontworpen voor de huidige generatie.
Nog één ding. Als je op mijn e-maillijst staat of mijn blog volgt, ga ik /advisor-gebruikspatronen volgen gedurende de komende weken en de data publiceren. Kostenverhoudingen, triggerfrequenties, echte uitkomsten op echte projecten. Het soort data dat je vertelt of deze feature zijn plek verdient in je workflow of dat het een nice-to-have is die je kunt negeren. Als je die data wilt voordat ze openbaar is, is de beste manier om die te krijgen nu je eigen tests te starten — want tegen de tijd dat ik mijn bevindingen publiceer, is Mythos waarschijnlijk weken verwijderd van het volledig veranderen van de vergelijking.
Het /advisor command is niet de grootste feature die Claude Code dit jaar heeft uitgebracht. Het is misschien niet eens de meest nuttige feature op een willekeurige dag. Maar het is wel de meest structureel belangrijke feature, omdat het de eerste keer is dat Anthropic expliciete infrastructuur heeft gebouwd voor samenwerking tussen meerdere modellen binnen één sessie, en die infrastructuur zal enorm belangrijk zijn zodra de modellaag boven Opus daadwerkelijk bestaat.
De factureringsbug die me drie dagen kostte om te vinden? Sonnet en Opus vonden hem in vier minuten advisor-ondersteunde analyse. Dat is niet het einde van het verhaal. Dat is het begin van een workflow-patroon dat ik jaren zal gebruiken.
Begin nu de gewoonte op te bouwen. Je zult blij zijn dat je dat deed wanneer het volgende model uitkomt.
Veelgestelde Vragen
Wat is het Claude Code /advisor slash command?
Het /advisor slash command laat je een secundair Claude-model configureren dat automatisch wordt aangeroepen door je primaire model wanneer het complexe beslissingen, terugkerende fouten of voltooiingscontrolepunten van taken tegenkomt. Het ondersteunt momenteel alleen Sonnet 4.6 en Opus 4.6. De advisor ontvangt het volledige gespreksTranscript en geeft begeleiding terug die wordt gevouwen in de gedeelde context van de sessie.
Welke modelkoppeling moet ik gebruiken met /advisor?
Voor de meeste ontwikkelaars: gebruik Sonnet 4.6 als je hoofdmodel en Opus 4.6 als de advisor. Deze koppeling geeft je de snelheid en kostenefficiëntie van Sonnet voor routinematig werk terwijl je Opus's diepere redenering reserveert voor de momenten die ertoe doen. Ik heb alle drie levensvatbare koppelingen getest en deze produceerde de beste kosten-kwaliteitsverhouding op echte refactoringstaken.
Werkt /advisor met subagents?
Ja, maar ze dienen verschillende doelen. /advisor stuurt het volledige transcript naar een secundair model inline, terwijl subagents draaien met schone, onafhankelijke context windows. Gebruik /advisor wanneer je hoofdmodel Sonnet is. Gebruik subagents wanneer je hoofdmodel Opus is en je een fris perspectief nodig hebt dat vrij is van de framing van het hoofdmodel.
Heeft de advisor toegang tot bestanden of kan hij commando's uitvoeren?
Nee. De advisor heeft geen toegang tot het bestandssysteem, de shell, het web of MCP-servers. Hij redeneert alleen over de gespreksgeschiedenis die hij ontvangt van het hoofdmodel. Dit is een harde architectonische grens in de huidige implementatie, geen configureerbare toestemming.
Is /advisor goedkoper dan Opus 4.6 als hoofdmodel draaien?
In mijn tests wel — een Sonnet 4.6-sessie van 42 beurten met 6 Opus 4.6 advisor-aanroepen bleek goedkoper dan het draaien van Opus 4.6 als hoofdmodel voor dezelfde werklast. De besparingen komen voort uit het gebruik van het goedkopere model voor de meerderheid van de tokens en het betalen van premiumtarieven alleen voor de advisor-aanroepen.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.
- Fiverr (aangepaste builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (zakelijke oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
