Was macht Effizientes Frontier-Routing?
Passe das Modell an die Arbeit in Claude Code, Codex oder einem anderen Agenten an, der Subagenten auf einem gewählten Modell starten kann (z. B. Gemini CLI oder Antigravity CLI), unabhängig vom Modell der Hauptsitzung. Eine günstigere Hauptsitzung kann Routinearbeit koordinieren und ein stärkeres Modell konsultieren; eine stärkere Hauptsitzung kann Routinearbeit an günstigere Agenten delegieren. Halte kleine Aufgaben lokal, wenn eine Übergabe mehr kosten würde als die Arbeit selbst.
Hilfe und Konfiguration
Wenn mit help oder --help aufgerufen, lies die Konfigurationshilfe, erkläre die Steuerelemente und Beispiele und stoppe dann. Beginne keine delegierte Arbeit oder ändere keine Einstellungen für eine Hilfeanfrage. Für Konfigurationsfragen lies dieselbe Referenz; für normale Aufgaben überspringe sie.
Wende Routing-Präferenzen aus der Anfrage des Benutzers und den anwendbaren Anweisungsdateien an. Für die Präferenzen dieser Skill verwende zuerst explizite Aufgabenanweisungen, dann Projektpräferenzen, dann globale Präferenzen, dann die folgenden Standardeinstellungen. Host-Berechtigungen, Modellverfügbarkeit und erzwungene Grenzen gelten weiterhin. Benutzer können das Entdeckungs-, Implementierungs- und Überprüfungsmodell wählen; den Aufwand pro Agent; Eskalationsauslöser und Wiederholungsanzahl; eine maximale Anzahl gleichzeitiger Subagenten; und ob Eskalation eine Genehmigung erfordert. Ehre eine konfigurierte Modellobergrenze oder eine Nicht-Delegierungs-Präferenz. Wenn eine erforderliche Überprüfung nicht innerhalb dieser Grenzen durchgeführt werden kann, melde die unerfüllte Überprüfung, anstatt sie stillschweigend zu ersetzen. Dies sind Anweisungen, die vom Assistenten interpretiert werden, keine JSON-Einstellungen oder eine harte Ausgabenobergrenze. Bearbeite keine dauerhaften Einstellungen, es sei denn, du wirst darum gebeten.
Arbeitsablauf
- Identifiziere Entscheidungen, die ein stärkeres Urteilsvermögen erfordern: Architektur, Ambiguität, Risiko, widersprüchliche Beweise und abschließende technische Überprüfung. Behandle sie in der Hauptsitzung, wenn sie für die Aufgabe geeignet ist; delegiere andernfalls nach oben.
- Identifiziere delegierbare Arbeit: Recherchescans, Repository-Inventar, Suche, Dokumentextraktion, Browser-/Testdurchläufe, Log-Reduktion, Testfehler-Clustering, enge Codierung und mechanische Änderungen.
- Starte Subagenten für gerechtfertigte Übergaben, parallelisiere unabhängige Teile mit klarer Zuständigkeit, begrenztem Umfang, Verifikationsgates und Beweisen.
- Fordere kompakte Rückgaben an: Ergebnisse, geänderte Dateien, ausgeführte Befehle, verbleibendes Risiko, erreichte Stoppbedingungen und Entscheidungen, die Synthese oder Eskalation erfordern.
- Integriere und überprüfe zentral, bevor das Ergebnis präsentiert wird.
Übergabepakete
Schreibe delegierte Prompts als in sich geschlossene Pakete. Gehe davon aus, dass der empfangende Agent das Gespräch nicht gesehen hat. Füge den Repository-Pfad, das Ziel, den Umfang, den ausgeschlossenen Bereich, relevante Dateien oder Suchziele, das erwartete Rückgabeformat, Verifikationsbefehle und Stoppbedingungen ein.
Nützliche Stoppbedingungen:
- Der Live-Code stimmt nicht mit der Annahme in der Übergabe überein.
- Ein Verifikationsbefehl erreicht die konfigurierte Wiederholungsgrenze (Standard: zwei fehlgeschlagene Versuche nach angemessenen Korrekturen).
- Die Arbeit scheint Dateien außerhalb des zugewiesenen Bereichs zu erfordern.
- Der Agent kann keine konkreten Beweise für seine Behauptung liefern.
Überprüfungsschleife
Behandle delegierte Ausgaben als zu prüfende Beweise, nicht als zu übergebendes Urteil. Öffne wichtige zitierte Dateien erneut, überfliege risikoreiche Diffs und führe die relevante Verifikation erneut aus oder stichprobenartig durch, bevor du die Fertigstellung meldest. Wenn delegierte Agenten bei einer schwierigen technischen Frage unterschiedlicher Meinung sind, verwende einen stärkeren Reviewer mit den Beweisen. Behalte Produktentscheidungen und Umfangsänderungen beim Benutzer.
Häufige Szenarien
Verwende dies als weiche Vorschläge:
- Recherche: Delegiere breite Repository-Scans, Dokumentextraktion und Quellvergleiche; die Hauptsitzung priorisiert die Ergebnisse und eskaliert schwierige Urteile.
- Codierung: Delegiere begrenzte Patches, Refactorings oder mechanische Änderungen, wenn die Dateizuständigkeit klar ist; integriere und überprüfe zentral.
- Tests: Wähle die Validierungsstrategie auf der geeigneten Argumentationsebene, verwende dann günstigere Agenten für Unit-Tests, Browserflüsse, Screenshots und Log-Reduktion. Bitte sie, genaue Befehle, Fehler, wahrscheinliche Ursachen und ob das Signal flaky, umgebungs- oder produktrelevant aussieht, zurückzugeben.
- Debugging: Sende unabhängige Agenten auf separate Theorien, Logs oder Reproduktionspfade; eskaliere die Diagnose, wenn die Beweise widersprüchlich bleiben.
Bearbeitetes Beispiel
Eine Sonnet-Hauptsitzung erhält „behebe die fehlschlagenden Checkout-Tests und verschärfe dabei die Rückerstattungsregel“, mit Projektpräferenzen von Haiku für Entdeckung, Sonnet für Implementierung, Opus mit hohem Aufwand für risikoreiche Überprüfung und maximal zwei gleichzeitigen Subagenten.
- Entdeckung geht an einen Haiku-Subagenten: führe die Testsuite aus, clustere die Fehler und gib die fehlschlagenden Tests, die berührten Dateien und die genauen Befehle zurück. Ein zweiter Haiku-Subagent kartiert, wo die Rückerstattungslogik lebt.
- Die Fehler clustern um ein veraltetes Fixture. Das ist eine begrenzte, mechanische Korrektur, daher erledigt die Hauptsitzung sie lokal, anstatt für eine Übergabe zu bezahlen.
- Die Rückerstattungsregel betrifft die Abrechnung, was ein hohes Risiko darstellt. Vor der Bearbeitung sendet die Hauptsitzung Opus (explizit angefordert,
effort: high) ein Paket mit den Rückerstattungsdateien, der vorgeschlagenen Änderung, den aktuellen Tests und einer Frage: Bricht diese Änderung einen bestehenden Rückerstattungspfad? - Die Hauptsitzung wendet die Änderung an, führt die Tests selbst erneut aus, öffnet die beiden Dateien, die Opus markiert hat, und meldet, welches Modell jeden Schritt ausgeführt hat, damit der Benutzer sehen kann, dass die stärkere Überprüfung tatsächlich stattgefunden hat.
Stufenzuordnung
Verwende die verfügbaren Modelle des Hosts und die Zuordnungen des Benutzers, um die günstigste geeignete Stufe zu wählen, oberhalb oder unterhalb des Modells der Hauptsitzung:
| Arbeit | Erforderliche Fähigkeit | Claude-Beispiele | Codex und andere Hosts |
|---|---|---|---|
| Entdeckung, Zusammenfassungen, Faktenchecks | Schnelle, genaue Extraktion | Haiku | Ein schnelles verfügbares Modell, das für faktische Arbeit geeignet ist |
| Scoped-Implementierung und Tests | Zuverlässige Codierung innerhalb etablierter Muster | Sonnet | Ein verfügbares Codierungsmodell, das für den Umfang geeignet ist |
| Architektur, tiefes Debugging, risikoreiche Überprüfung | Starke systemübergreifende Argumentation | Opus oder Fable, wo verfügbar | Ein stärkeres verfügbares Argumentationsmodell |
Claude-Namen sind Beispiele für Claude-Sitzungen, keine Aliase, die an Codex übergeben werden. Erfinde keine Codex-Modell-IDs oder gehe von einer dauerhaften Eins-zu-Eins-Zuordnung zwischen Anbietern aus. Überprüfe die verfügbaren Modellauswahlen des Hosts und verwende explizite gültige Namen. Bleibe für gewöhnliches Routing beim aktuellen Anbieter, es sei denn, der Benutzer wünscht etwas anderes; wende bei Bedarf die separate Regel für Überprüfungen durch andere Anbieter an. Wähle den Aufwand unabhängig vom Modell und respektiere die Aufwandsgrenzen des Benutzers. Standardmäßig nicht alle Agenten auf den höchsten Aufwand setzen.
Eine stärkere Hauptsitzung kann schwierige Entscheidungen direkt treffen. Von einer günstigeren Sitzung aus delegiere die schwierige Entscheidung oder Überprüfung mit einem kompakten Beweispaket, integriere dann das Ergebnis und führe die erforderlichen Prüfungen durch. Wenn der Host nur ein Modell bereitstellt, behalte die Arbeit darauf und melde eine unerfüllte Anforderung einer stärkeren Überprüfung. Behaupte nicht, eine höhere Modellstufe zu sein, nur weil der Aufwand erhöht wurde.
Eskalation von einer günstigeren Hauptsitzung
Eskaliere vor der Implementierung einer unbekannten Architekturänderung oder einer Änderung an einem risikoreichen Invariant, vorbehaltlich der Eskalationsrichtlinie des Benutzers. Eskaliere auch, wenn Beweise widersprüchlich sind oder die Wiederholungsgrenze erreicht ist (Standard: zwei angemessene Versuche für dasselbe technische Problem). Verwende bereits gesammelte Beweise; bezahle nicht für eine weitere breite Untersuchung derselben Dateien.
Behandle Auth, Abrechnung, Berechtigungen, Sicherheit, Migrationen, Datenverlust, gemeinsam genutzten Zustand, Caching, Parallelität, modulübergreifendes Verhalten, öffentliche APIs und benutzersichtbare Workflows als hohes Risiko. Verwende die stärkste geeignete Stufe für die Entscheidung oder technische Überprüfung. Wenn der Benutzer eine Überprüfung durch ein Modell eines anderen Anbieters für risikoreiche Arbeiten verlangt, behalte diese Überprüfung bei; sie fügt die Perspektive eines anderen Modells hinzu.
In Claude Code fordere explizit das model des Subagenten im Agent-Aufruf an oder verwende einen benutzerdefinierten Agenten mit model: opus (und effort: high, wenn angemessen). Ein nicht angegebenes Modell kann das günstigere Hauptmodell erben. Verwende einen gewöhnlichen Subagenten mit einer fokussierten Übergabe; ein Conversation-Fork verwendet das Hauptmodell. Überprüfe das gemeldete Modell, verwende /tasks, wenn verfügbar. In Codex oder einem anderen Host setze das Modell und den Argumentationsaufwand explizit über den unterstützten Pro-Agent-Selektor des Hosts. Verwende eine fokussierte Aufgabenübergabe, wenn das Erben des gesamten Gesprächs eine Modellüberschreibung verhindern würde. Überprüfe die gemeldete Auswahl; wenn der Host keine Modelle pro Agent auswählen kann, melde diese Einschränkung, anstatt Routing zu simulieren.
Behalte die Hauptsitzung auf ihrem gewählten Modell. Dies ist eine Routing-Anweisung, kein automatischer Laufzeit-Router oder eine Garantie, dass das günstigere Modell jeden schwierigen Fall erkennt. Wenn das erforderliche Modell nicht verfügbar oder eingeschränkt ist, melde die Einschränkung, anstatt stillschweigend zu behaupten, dass eine stärkere Überprüfung stattgefunden hat.
Leitplanken
- Behandle einen sofortigen Blockierer lokal, es sei denn, stärkere Expertise oder Kontextisolierung rechtfertigt eine sequenzielle Übergabe. Erledige in der Zwischenzeit unabhängige Arbeit, wenn möglich.
- Lasse nicht mehrere Agenten gleichzeitig dieselben Dateien bearbeiten.
- Vertraue Subagenten-Schlussfolgerungen nicht blind, wenn das Risiko hoch ist; überprüfe die wichtigen Beweise selbst.
- Behaupte keine universellen Einsparungen. Das Muster funktioniert am besten, wenn Exploration und Implementierung, Tests oder Recherche parallelisiert werden können.
Standard-Rahmung
„Ich werde Routinearbeit auf dem aktuellen oder einem günstigeren Modell belassen und schwierige Entscheidungen oder risikoreiche Überprüfungen bei Bedarf an einen stärkeren Agenten delegieren.“