Claude Code /advisor Command: Ein zweites Gehirn für feststeckende Modelle
Ich habe einen ganzen Samstag damit verbracht, den neuen /advisor-Command von Claude Code zu brechen.
Nicht im Sinne von „Bug finden und Ticket aufmachen." Eher im Sinne von: „Ich habe mich schon oft genug an glänzenden neuen Slash Commands die Finger verbrannt, dass ich keinem davon mehr traue, bevor ich nicht hässlichen Produktionscode darauf losgelassen habe." Mein Testfeld war ein Abrechnungsservice, den ich seit Wochen refaktoriere – eine Laravel 11-App mit den Arten von Grenzfällen, die jede Schwäche in einem KI-Coding-Modell aufdecken. Anteilige Upgrades. Downgrades mitten im Zyklus. Dunning-Logik, die einen partiellen Stripe-Webhook-Fehler überleben muss.
Das Ergebnis hat mich überrascht. Nicht weil /advisor mich vor einer Katastrophe gerettet hat – das hat es nicht. Sondern weil es zwei Probleme aufgedeckt hat, die ich drei Tage lang angestarrt hatte, ohne sie zu sehen. Ein Logikfehler im Prorata-Fenster und ein subtiler Zeitzonen-Bug in der Verlängerungsberechnung. Sonnet 4.6 lief als mein Hauptausführungsmodell. Als es beim dritten Durchgang das Stillstandsmuster zeigte, rief es Opus 4.6 über /advisor auf und kam mit einer zweiseitigen Analyse zurück, die sich las wie ein Code-Review eines Senior-Engineers.
In diesem Moment wurde mir klar, dass es bei diesem Command gar nicht wirklich um Ratschläge geht. Es geht darum, dass Anthropic ein Gerüst für Mythos baut.
Lass mich erklären, was ich meine – und warum der /advisor-Slash-Command möglicherweise das wichtigste Feature ist, das Claude Code dieses Quartal geliefert hat, auch wenn die meisten Entwickler es als geringfügiges Quality-of-Life-Update abtun werden.
Was /advisor wirklich tut (und was nicht)
Der /advisor-Command lässt dich ein sekundäres Modell konfigurieren, das aufgerufen wird, wenn dein primäres Modell auf Schwierigkeiten stößt. Das ist der Elevator Pitch. Die Realität ist nuancierter, und die Nuance spielt eine Rolle.
So funktioniert das aktuelle Setup. Du führst /advisor innerhalb von Claude Code aus, wählst ein Modell aus der Liste (derzeit Sonnet 4.6 oder Opus 4.6 – keine anderen Optionen, keine benutzerdefinierten Endpoints, kein Haiku), und von da an hat Claude Code die Fähigkeit, dieses Modell selbstständig aufzurufen, wenn es entscheidet, dass es eine zweite Meinung braucht. Du rufst den Advisor nicht manuell auf. Du tippst nicht „frag den Advisor dazu." Das primäre Modell trifft die Entscheidung autonom anhand von Kontextsignalen.
Dieser letzte Punkt hat mich beim ersten Mal gestolpert. Ich erwartete ständig eine Eingabeaufforderung oder einen Bestätigungsdialog. Den gibt es nicht. Der Advisor-Aufruf geschieht still, mitten in einer Antwort, und der Rat wird in den Sitzungskontext zurückgefaltet, als wäre er schon immer da gewesen.
Drei Dinge, die du verstehen musst, wie das wirklich funktioniert:
Der Advisor hat den vollständigen Gesprächskontext. Wenn das primäre Modell /advisor aufruft, erhält das sekundäre Modell das gesamte Transkript – deine ursprüngliche Anfrage, jeden Tool-Aufruf, jede gelesene Datei, jede Befehlsausgabe, jeden Denkschritt. Keine Parameter. Keine Filterung. Kein Cherry-Picking. Es sieht, was dein Hauptmodell gesehen hat, in derselben Reihenfolge, mit denselben Einschränkungen.
Der Advisor kann die Außenwelt nicht berühren. Kein Zugriff auf das Dateisystem. Keine Shell-Befehle. Keine Web-Anfragen. Keine MCP-Server. Der Advisor existiert rein dazu, über den Gesprächsverlauf nachzudenken und Orientierung zu geben. Das ist eine harte architektonische Grenze, keine Berechtigung, die du umschalten kannst.
Der Rat wird Teil des gemeinsamen Gedächtnisses. Sobald der Advisor antwortet, bleibt seine Analyse im Sitzungskontext erhalten. Spätere Advisor-Aufrufe sehen frühere Ratschläge. Wenn empirische Ergebnisse dem widersprechen, was der Advisor empfohlen hat, bringt Claude Code den Konflikt ans Licht, anstatt die Anleitung stillschweigend zu überschreiben. Du bekommst einen expliziten „der Advisor hat X gesagt, aber die Testausgabe zeigt Y – sollen wir nochmal nachfragen?"-Moment.
Dieses dritte Verhalten hatte ich nicht erwartet, und es ist das Verhalten, das meine Meinung über das Feature geändert hat.
Die vier Auslöser, die den Advisor aufrufen
Ich habe die erste Stunde des Testens damit verbracht, herauszufinden, wann Claude Code tatsächlich zum Advisor greift. Die Dokumentation ist dünn. Das Verhalten ist teilweise emergent. Also habe ich eine Reihe kontrollierter Szenarien durchgeführt und die Logs beobachtet.
Vier Muster lösen einen Advisor-Aufruf zuverlässig aus. Wenn du diese verstehst, weißt du, ob /advisor es wert ist, für deinen Workflow zu aktivieren, oder ob es einfach Kontext-Tokens verbraucht, die es nie benutzt.
Auslöser 1: Vor substantiellem Schreiben oder Interpretation. Wenn das Modell kurz davor ist, einen bedeutenden Codeblock zu schreiben, eine neue Datei zu generieren oder einen Interpretationssprung von Anforderungen zur Implementierung zu wagen, hält es inne und bittet den Advisor zuerst um einen Sanity Check. Das ist das „zweimal messen, einmal schneiden"-Muster. Einfache reaktive Aufgaben – eine Variable umbenennen, einen Tippfehler beheben, einen Abstand anpassen – überspringen dies vollständig.
Auslöser 2: An der vermeintlichen Ziellinie. Wenn das Hauptmodell glaubt, dass die Aufgabe abgeschlossen ist, ruft es den Advisor auf, um die Ausgabe vor der Erfolgserklärung zu überprüfen. Das hat einen Bug in meinem Abrechnungscode aufgedeckt, von dem Sonnet 4.6 sich selbst überzeugt hatte, dass er behoben sei. Der Advisor markierte einen fehlenden Grenzfall in der Prorata-Logik, und Sonnet ging zurück und behob ihn, ohne dass ich ein Wort sagte.
Auslöser 3: Wiederkehrende Fehler oder nicht konvergierende Schleifen. Wenn das Modell dieselbe Lösung dreimal versucht und die Tests weiterhin scheitern, oder wenn es zwischen zwei inkompatiblen Ansätzen hin und her springt, wird der Advisor hinzugezogen. Das ist das Muster, das mich am meisten interessiert, weil es früher meinen ganzen Nachmittag in Anspruch genommen hat. Du kennst die Schleife – das Modell behebt das eine, bricht das andere, behebt das, regressiert das erste, und schließlich musst du manuell eingreifen und das ganze Durcheinander entwirren.
Auslöser 4: Checkpoints bei mehrstufigen Aufgaben. Bei jeder Aufgabe mit mehreren Phasen (der Art, bei der Claude Code zu Beginn eine Todo-Liste erstellt) wird der Advisor mindestens zweimal aufgerufen. Einmal vor dem Festschreiben substantieller Arbeit. Einmal bei Abschluss. Das ist das Standard-Sicherheitsnetz für die Workflows, bei denen am häufigsten etwas schiefgeht.
Was löst keinen Advisor-Aufruf aus? Kleinere UI-Anpassungen. Einmalige Refaktorierungen. Reaktive Korrekturen für unkomplizierte Probleme. Alles, worüber das primäre Modell zuversichtlich ist. Das System ist bewusst konservativ – es will keine Tokens für Probleme verbrennen, die keine zweite Meinung brauchen.
Aber bei dieser Konservativität gibt es einen Haken. Wenn dein primäres Modell überselbstbewusst ist – und wer Sonnet 4.6 lange genug verwendet hat, weiß, dass es das sein kann – wird der Advisor nicht aufgerufen, wenn er es sollte. Das Urteil, den Advisor aufzurufen, lebt innerhalb desselben Modells, dessen Urteil du zu prüfen versuchst. Das ist eine Design-Spannung, die ich nicht für vollständig gelöst halte, und ich komme im Abschnitt „Klartext" darauf zurück.
Nun lass mich zeigen, wie die tatsächlichen Modellkombinationen in der Praxis aussehen.
Die drei Kombinationen, die ich getestet habe (und welche gewinnt)
Es gibt derzeit wirklich nur drei Möglichkeiten, /advisor zu konfigurieren, und ich habe alle drei an derselben Abrechnungsrefaktorierung übers Wochenende durchgeführt. Das habe ich gefunden.
Kombination 1: Sonnet 4.6 Haupt + Opus 4.6 Advisor
Das ist die Kombination, zu der Anthropic die Nutzer anscheinend lenkt, und nach dem Testen verstehe ich warum. Sonnet 4.6 läuft als dein Ausführungsmodell. Es ist schnell, es ist günstig, es ist gut genug für 85% der Coding-Arbeit, die ich täglich erledige. Wenn es feststeckt, steigt Opus 4.6 als Advisor ein und bringt sein tieferes Denkvermögen auf das Problem.
Die Kostenrechnung ist wirklich interessant. Sonnet 4.6 kostet pro Million Tokens ungefähr die Hälfte von Opus 4.6. Der Advisor wird nur bei bestimmten Auslösern aufgerufen, sodass du nicht Opus-Preise für die gesamte Sitzung zahlst – nur für die Moment des Feststeckens. In meiner Samstagssitzung habe ich etwa 42 Runden Sonnet 4.6 mit genau 6 Advisor-Aufrufen an Opus 4.6 durchgeführt. Die Token-Aufschlüsselung war günstiger als Opus 4.6 als Hauptmodell für dieselbe Sitzung laufen zu lassen, mit einem Unterschied, der in großem Maßstab wichtig wäre.
Qualitätsmäßig? Ich erzielte Ergebnisse, die mit einer reinen Opus 4.6-Sitzung vergleichbar waren, weil in jedem Moment, der zählte, Opus sowieso in der Schleife war.
Kombination 2: Opus 4.6 Haupt + Sonnet 4.6 Advisor
Das ist die umgekehrte Kombination, die ich hauptsächlich aus Neugier getestet habe. Das Ergebnis: nicht großartig. Sonnet 4.6 ist ein fähiges Modell, aber wenn Opus 4.6 bereits kämpft, Sonnet um eine Überprüfung der Argumentation zu bitten ist wie einen Junior-Engineer zu bitten, die Architekturentscheidung eines Senior-Engineers zu reviewen. Die Advisor-Aufrufe kamen entweder mit Zustimmung zurück („dein Ansatz sieht korrekt aus") oder mit oberflächlichen Vorschlägen, die Opus bereits erwogen und verworfen hatte.
Ich empfehle diese Konfiguration nicht. Wenn Opus dein Hauptmodell ist, ist es besser, einen Subagenten mit eigenem context window für die Momente des Feststeckens zu spawnen – was zufällig der Ansatz ist, den ich standardmäßig verwende, wenn ich Opus als Ausführungsmodell nutze.
Kombination 3: Opus 4.6 Haupt + Opus 4.6 Advisor
Ja, du kannst dasselbe Modell als Haupt- und Advisor konfigurieren. Nein, das ist nicht nutzlos – aber es ist nicht so leistungsstark wie die Kombinationen, die unterschiedliche Modelle verwenden, weil du den Frischaugen-Effekt verlierst. Der Vorteil des Advisors kommt teilweise daher, das Problem aus einem anderen Blickwinkel anzugehen. Wenn der Advisor buchstäblich dasselbe Modell mit denselben Vorurteilen ist, schrumpft die neue Perspektive.
Das gesagt, übertraf diese Kombination trotzdem unkontrolliertes Opus bei meinem Test mit wiederkehrenden Fehlern, weil der Advisor-Aufruf eine reflektierte Pause erzwingt, die das Hauptmodell von selbst nicht gemacht hätte. Der metakognitive Schritt zählt, selbst wenn die Kognition aus derselben Quelle kommt.
Der Gewinner für die meisten Entwickler: Sonnet 4.6 Haupt, Opus 4.6 Advisor. Günstiger als reines Opus. Klüger als reines Sonnet. Sauberster Workflow, den ich getestet habe.
Schritt für Schritt durch einen echten Advisor-Aufruf
Lass mich dir genau zeigen, wie das in der Praxis aussieht, denn die abstrakte Beschreibung erfasst die Erfahrung nicht. Ich verwende das Abrechnungs-Bug-Szenario, weil es mein sauberster Testfall war.
Schritt 1: Advisor konfigurieren.
Innerhalb von Claude Code habe ich den Befehl ausgeführt:
/advisor
Die Eingabeaufforderung fragte zurück, welches Modell konfiguriert werden soll. Ich wählte Opus 4.6. Claude Code bestätigte: „Advisor konfiguriert. Opus 4.6 wird für komplexe Entscheidungen und Aufgabenabschluss-Überprüfungen konsultiert." Das war's. Keine weitere Konfiguration. Keine Sampling-Parameter. Keine Prompt-Anpassung.
Schritt 2: Hauptaufgabe starten.
Ich bat Claude Code (mit Sonnet 4.6 als Haupt), die Prorata-Logik in meiner SubscriptionBillingService-Klasse zu überprüfen und gefundene Bugs zu beheben. Sonnet 4.6 las die Datei, verfolgte den Fluss durch drei abhängige Klassen und schlug eine Lösung für das vor, was es als Off-by-One-Fehler in der Berechnung der Prorata-Tage identifizierte.
Schritt 3: Sonnet wendet die Lösung an und führt Tests durch.
Die Lösung bestand 14 von 16 vorhandenen Tests. Zwei Tests schlugen fehl – beide im Zusammenhang mit der Zeitzonenbehandlung an Verlängerungsgrenzen. Sonnet versuchte eine zweite Lösung. Dieselben zwei Tests schlugen fehl. Versuchte einen dritten Ansatz. Dasselbe Fehlermuster.
Das ist der Punkt, an dem der wiederkehrende-Fehler-Auslöser auslöst.
Schritt 4: Sonnet ruft /advisor auf.
Die Konsolenausgabe machte den Aufruf explizit:
[advisor invoked: recurring test failure on timezone-sensitive cases]
Keine Interaktion meinerseits. Sonnet traf den Anruf autonom. Opus 4.6 erhielt das vollständige Transkript – meine ursprüngliche Anfrage, den Dateiinhalt, die Testfehler, alle drei versuchten Lösungen – und gab eine strukturierte Analyse zurück.
Schritt 5: Der Rat kommt zurück.
Opus 4.6s Antwort identifizierte zwei Probleme, die Sonnet übersehen hatte. Erstens: Die Prorata-Logik verwendete die lokale Zeitzone des Servers anstelle der Abonnementzeitzone des Nutzers, was bedeutete, dass Verlängerungen nahe der UTC-Mitternacht in der falschen Abrechnungsperiode berechnet wurden. Zweitens: Die Test-Fixtures, die Sonnet aktualisiert hatte, waren selbst falsch, weshalb Sonnet's Lösungen weiterhin korrekt aussahen, aber die Tests weiterhin scheiterten – die Tests validierten den Bug, nicht die Lösung.
Keines der Probleme war aus Sonnets alleiniger Analyse offensichtlich. Beide waren im Nachhinein offensichtlich, sobald Opus sie aufzeigte.
Schritt 6: Sonnet integriert den Rat.
Sonnet 4.6 kopierte die Antwort des Advisors nicht einfach wortwörtlich. Es nahm die Anleitung, schrieb die Prorata-Logik um, um die Zeitzone des Nutzers zu verwenden, und markierte dann unabhängig das Test-Fixture-Problem zur Überprüfung durch mich – „Der Advisor hat darauf hingewiesen, dass die Fixtures möglicherweise falsches Verhalten validieren. Ich empfehle, tests/Unit/ProrationTest.php Zeilen 84-110 zu überprüfen, bevor ich sie ändere, da dies die Test-Semantik verändert."
Dieser letzte Teil ist das Verhalten, das mich für /advisor gewonnen hat. Sonnet hat den Rat nicht blind angewendet. Es hielt an dem Punkt inne, an dem der Rat Implikationen hatte, über die ich mitentscheiden sollte.
Schritt 7: Verifikation.
Ich genehmigte die Fixture-Überprüfung. Sonnet aktualisierte die Tests, führte die Suite erneut aus, und alle 16 Tests bestanden. Gesamtzeit vom ersten fehlgeschlagenen Fix bis zum grünen Testlauf: unter vier Minuten. Manuelle Debugging-Zeit, die ich für dasselbe Problem aufgewendet hätte, basierend darauf, wie lange ich bereits feststeckte: wahrscheinlich noch zwei Stunden.
Die Pro-Tipps, über die noch niemand spricht
Einige Dinge, die ich beim Testen gelernt habe und die nicht in der Ankündigungsdokumentation stehen.
Tipp 1: Advisor-Aufrufe erscheinen im Token-Ledger, aber als separater Posten. Du kannst genau sehen, wie viel der Advisor im Vergleich zum Hauptmodell gekostet hat. Das ist überraschend nützlich, um zu kalibrieren, ob das Feature bei einem bestimmten Projekt seinen Wert verdient. Ich verfolge das Verhältnis über meine Testprojekte hinweg und werde die Daten wahrscheinlich in einem Folgeartikel veröffentlichen.
Tipp 2: Der Advisor bleibt über /compact-Operationen hinaus bestehen. Wenn du dein Gespräch verdichtest, um Kontext freizugeben, überlebt die frühere Anleitung des Advisors die Verdichtung. Das ist ein kleines Detail mit großen Auswirkungen auf lange Sitzungen – dein Advisor wird effektiv zu einer kumulativen Wissensschicht.
Tipp 3: Du kannst /advisor erneut ausführen, um Modelle mitten in einer Sitzung zu wechseln. Das habe ich anfangs nicht erkannt, aber du kannst deine Advisor-Konfiguration mitten in einer Sitzung wechseln, ohne neu zu starten. Ich nutzte das, um nach einem /compact von Opus-als-Advisor zu einem frischen Opus-als-Advisor zu wechseln, um den angesammelten Zustand des Advisors zurückzusetzen.
Tipp 4: Der Advisor-Auslöser kann beeinflusst werden. Obwohl du einen Aufruf nicht erzwingen kannst, kannst du das Hauptmodell wahrscheinlicher dazu bringen, den Advisor aufzurufen, indem du in deinem Prompt explizit bist. Phrasen wie „überprüf das mit dem Advisor, bevor du festschreibst" oder „wenn du feststeckst, konsultiere den Advisor" erhöhten die Aufrufrate in meinen Tests messbar. Keine Garantie – aber ein nützlicher Hebel.
Tipp 5: Achte auf Advisor-Schleifenverhalten. Bei einem Test rief Sonnet 4.6 Opus 4.6 drei Mal hintereinander für dasselbe Problem auf, jedes Mal mit leicht unterschiedlichem Rat und jedes Mal mit weniger Sicherheit über die Richtung. Das ist das Fehlermuster, auf das du achten musst. Wenn du siehst, dass der Advisor wiederholt aufgerufen wird ohne Fortschritt, greif manuell ein. Die metakognitive Schicht ist wertvoll, aber kein Ersatz für menschliches Urteil, wenn das Modell wirklich verloren ist.
Klartext: Warum ich für Opus-Workflows immer noch standardmäßig Subagenten bevorzuge
Hier kommt der ehrliche Teil. Für meinen tatsächlichen täglichen Workflow – bei dem ich Opus 4.6 als Hauptmodell für komplexe Agentenarchitekturen nutze – bevorzuge ich immer noch Subagenten mit unabhängigen context windows gegenüber /advisor. Lass mich erklären warum, denn die Abwägung ist wichtig.
Wenn ich einen Subagenten spawne, startet dieser Agent mit einem sauberen Kontext. Kein angesammeltes Gespräch. Kein voreingenommenes Framing von den früheren Versuchen des Hauptmodells. Nur der Prompt, den ich gebe, und die Tools, die ich autorisiere. Diese Sauberkeit ist oft der Unterschied zwischen nützlicher Anleitung und Rat, der nur die blinden Flecken des Hauptmodells zurückwirft.
Der /advisor-Command hingegen übergibt das gesamte Transkript jedes Mal an den Advisor. Wenn das Hauptmodell feststeckt, weil es das Problem falsch framt, sieht der Advisor dasselbe falsche Framing und kann es möglicherweise umgehen oder auch nicht. Opus ist besser darin, Framing-Fallen zu entkommen als Sonnet, weshalb die Sonnet-Haupt + Opus-Advisor-Kombination so gut funktioniert – Opus bringt genug Leistung zum Umframen. Aber wenn Opus dein Hauptmodell ist und das Framing das Problem ist, kann der Advisor in dieselbe Falle gezogen werden.
Ich habe das direkt getestet. Ich gab Opus 4.6 ein absichtlich falsch geframtes Architekturproblem und konfigurierte Opus 4.6 als Advisor. Der Advisor stimmte dem Framing zu. Ich spawnte dann einen frischen Opus 4.6-Subagenten mit nur den ursprünglichen Anforderungen (kein Transkript) und stellte dieselbe Frage. Der Subagent fragte das Problem sofort um und schlug eine andere Lösung vor.
Dasselbe Modell. Dasselbe Problem. Unterschiedliche Ergebnisse basierend auf der Kontextfrische.
Also hier ist meine tatsächliche Faustregel: Verwende /advisor, wenn dein Hauptmodell Sonnet ist und du ein Opus-Sicherheitsnetz möchtest. Verwende Subagenten, wenn dein Hauptmodell Opus ist und du echtes paralleles Denken möchtest. Verwende beides, wenn du an etwas Hochriskantes arbeitest.
Und sei ehrlich zu dir selbst darüber, in welchem Modus du dich befindest. Die Standardeinstellungen des Features sind klug, aber sie sind keine Magie.
Warum /advisor wirklich um Mythos geht
Jetzt zu dem Teil, auf den ich hingesteuert habe.
Ich glaube nicht, dass /advisor existiert, weil das Claude Code-Team eine metakognitive Schicht für Sonnet und Opus ausliefern wollte. Ich glaube, /advisor existiert, weil Anthropic die Infrastruktur für Mythos vorbereitet – das Modell, das vor einigen Wochen in öffentliche Gespräche durchzusickern begann und das ich bereits in der Claude-Mythos-Leak-Analyse behandelt habe – und sie einen Weg brauchten, ein teures, leistungsstarkes Modell innerhalb von Claude Code wirtschaftlich tragfähig zu machen.
Denk mal drüber nach. Wenn Mythos zu dem Preisniveau landet, das die Leaks nahelegen – deutlich über Opus 4.6 – wird es für die meisten Entwickler unerschwinglich sein, es als Hauptmodell für eine gesamte Sitzung zu nutzen. Selbst für Agenturarbeit werden die Margen nicht für jede Aufgabe funktionieren. Wie also gibst du Nutzern Zugang zu Mythos' Leistung, ohne sie zu zwingen, Mythos-Preise für jedes Token zu zahlen?
Du lässt sie es als Advisor konfigurieren.
Stell dir die Kombination vor: Sonnet 4.6 als dein Ausführungsmodell, schnell und günstig für den Großteil deiner Tokens. Mythos als dein Advisor, nur an den kritischen Momenten aufgerufen – vor großen Commits, wenn die Tests weiterhin scheitern, wenn das Modell kurz davor ist, einen Interpretationssprung zu wagen. Du bekommst Mythos-Qualitätsurteil bei den wichtigsten Entscheidungen, zu einem Bruchteil der Kosten für das Betreiben von Mythos als Hauptmodell.
Das ist das Muster. /advisor ist das Gerüst. Die Sonnet/Opus-Kombination, die wir heute haben, ist der Beta-Test für die Sonnet/Mythos-Kombination, die kommt.
Ich könnte damit falsch liegen. Es ist möglich, dass /advisor einfach ein eigenständiges Feature ist und die Mythos-Integration völlig anders aussehen wird. Aber die Architekturentscheidungen erzählen eine Geschichte. Die harte Modell-Positivliste (derzeit zwei Modelle). Das automatische Teilen des Kontexts. Das Konflikterkennungsverhalten, das Advisor-Meinungsverschiedenheiten an die Oberfläche bringt, anstatt ihnen nachzugeben. Das sind alles Designentscheidungen, die perfekt Sinn ergeben, wenn dein Endziel ein abgestuftes Modellsystem ist, bei dem das hochwertigste Modell teuer genug ist, dass du es nur bei den schwierigsten Problemen konsultieren möchtest.
Und wenn ich damit richtig liege, werden Entwickler, die /advisor jetzt lernen, einen enormen Vorsprung haben, wenn Mythos kommt. Die Workflow-Muster, die du rund um Sonnet-Haupt + Opus-Advisor aufbaust, werden fast direkt auf Sonnet-Haupt + Mythos-Advisor übertragen, wobei sich nur die Konfiguration ändert. Die Prompt-Gewohnheiten, das Trigger-Bewusstsein, das Subagent-versus-Advisor-Entscheidungsframework – alles überträgt sich.
Wenn du einen tieferen Blick auf das werfen möchtest, was Mythos bringen könnte, habe ich über die Implikationen in meinem Mythos-Deep-Dive über Modellautonomie geschrieben. Aber die Kurzversion: Was auch immer Mythos sich herausstellt zu sein, es wird teuer sein, und /advisor ist der Weg, wie du darauf zugreifst, ohne pleite zu gehen.
Was ich dir heute empfehlen würde
Wenn du bereits Claude Code nutzt und für den Großteil deiner Arbeit Sonnet 4.6 verwendest, aktiviere /advisor mit Opus 4.6 als Advisor jetzt sofort. Führe es diese Woche auf einem echten Projekt durch. Achte darauf, wie oft der Advisor aufgerufen wird und welche Art von Problemen ihn auslöst. Diese Mustererkennung ist der eigentliche Wert – nicht die ersten Male, wenn es dich vor einem Bug rettet, sondern das schrittweise Verstehen, wann dein Modell wahrscheinlich eine zweite Meinung braucht.
Wenn du Opus 4.6 als Hauptmodell verwendest, würde ich immer noch empfehlen, /advisor mit Opus als Advisor zu aktivieren, aber parallel zu deinen bestehenden Subagenten-Workflows. Ersetze keine Subagenten. Ergänze sie. Verwende /advisor für die leichten, inline zweiten Meinungen und Subagenten für das schwerere parallele Denken.
Wenn du noch nicht auf Sonnet 4.6 oder Opus 4.6 aktualisiert hast, tu das zuerst. Der Advisor-Command erfordert sie. Ältere Modelle stehen nicht auf der Positivliste und werden es nicht sein – das Feature ist explizit für die aktuelle Generation konzipiert.
Noch eine Sache. Wenn du auf meiner E-Mail-Liste bist oder meinem Blog folgst, werde ich /advisor-Nutzungsmuster über die nächsten Wochen verfolgen und die Daten veröffentlichen. Kostenverhältnisse, Auslöserfrequenzen, echte Ergebnisse bei echten Projekten. Die Art von Daten, die dir sagen, ob dieses Feature seinen Platz in deinem Workflow verdient oder ob es ein Nice-to-Have ist, das du ignorieren kannst. Wenn du diese Daten haben möchtest, bevor sie öffentlich sind, ist der beste Weg, jetzt mit deinen eigenen Tests zu beginnen – denn bis ich meine Ergebnisse veröffentliche, wird Mythos wahrscheinlich nur noch Wochen davon entfernt sein, die Gleichung vollständig zu verändern.
Der /advisor-Command ist nicht das größte Feature, das Claude Code dieses Jahr geliefert hat. Es ist vielleicht nicht mal das nützlichste Feature an einem beliebigen Tag. Aber es ist das strukturell wichtigste Feature, weil es das erste Mal ist, dass Anthropic explizite Infrastruktur für die Zusammenarbeit mehrerer Modelle innerhalb einer einzigen Sitzung gebaut hat, und diese Infrastruktur wird enorm wichtig sein, sobald die Modellebene über Opus tatsächlich existiert.
Der Abrechnungs-Bug, den ich drei Tage gebraucht habe zu finden? Sonnet und Opus haben ihn in vier Minuten Advisor-gestützter Analyse gefunden. Das ist nicht das Ende der Geschichte. Das ist der Beginn eines Workflow-Musters, das ich jahrelang verwenden werde.
Begin jetzt damit, die Gewohnheit aufzubauen. Du wirst froh sein, dass du das getan hast, wenn das nächste Modell kommt.
Häufig gestellte Fragen
Was ist der Claude Code /advisor Slash Command?
Der /advisor-Slash-Command lässt dich ein sekundäres Claude-Modell konfigurieren, das automatisch von deinem primären Modell aufgerufen wird, wenn es auf komplexe Entscheidungen, wiederkehrende Fehler oder Aufgabenabschluss-Checkpoints trifft. Es unterstützt derzeit nur Sonnet 4.6 und Opus 4.6. Der Advisor erhält das gesamte Gesprächstranskript und gibt Anleitung zurück, die in den gemeinsamen Kontext der Sitzung eingefaltet wird.
Welche Modellkombination sollte ich mit /advisor verwenden?
Für die meisten Entwickler: Verwende Sonnet 4.6 als Hauptmodell und Opus 4.6 als Advisor. Diese Kombination gibt dir Sonnets Geschwindigkeit und Kosteneffizienz für Routineaufgaben, während Opus' tieferes Denkvermögen für die wichtigen Momente reserviert bleibt. Ich habe alle drei brauchbaren Kombinationen getestet und diese lieferte das beste Kosten-Qualitäts-Verhältnis bei echten Refaktorierungsaufgaben.
Funktioniert /advisor mit Subagenten?
Ja, aber sie dienen unterschiedlichen Zwecken. /advisor übergibt das gesamte Transkript inline an ein sekundäres Modell, während Subagenten mit sauberen, unabhängigen context windows laufen. Verwende /advisor, wenn dein Hauptmodell Sonnet ist. Verwende Subagenten, wenn dein Hauptmodell Opus ist und du eine frische Perspektive benötigst, die frei vom Framing des Hauptmodells ist.
Kann der Advisor auf Dateien zugreifen oder Befehle ausführen?
Nein. Der Advisor hat keinen Zugriff auf das Dateisystem, die Shell, das Web oder MCP-Server. Er denkt nur über den Gesprächsverlauf nach, den er vom Hauptmodell erhält. Das ist eine harte architektonische Grenze in der aktuellen Implementierung, keine konfigurierbare Berechtigung.
Ist /advisor günstiger als Opus 4.6 als Hauptmodell zu betreiben?
In meinen Tests ja – eine 42-Runden-Sonnet 4.6-Sitzung mit 6 Opus 4.6-Advisor-Aufrufen war günstiger als Opus 4.6 als Hauptmodell für dieselbe Arbeitslast zu betreiben. Die Einsparungen kommen daher, das günstigere Modell für den Großteil der Tokens zu verwenden und Premiumpreise nur für die Advisor-Aufrufe zu zahlen.
Lass uns zusammenarbeiten
Möchtest du KI-Systeme aufbauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe dir gerne.
- Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (Unternehmenslösungen): ramlit.com
- ColorPark (Design & Branding): colorpark.io
- xCyberSecurity (Sicherheitsdienste): xcybersecurity.io
