Aufgabenmodell-Router
Ziel ist es, die vom Benutzer geforderte Qualität zu erreichen und die Gesamtkosten einer vollständigen Aufgabe zu senken, einschließlich Fehlplanung, Nacharbeit, Kontextwiederherstellung und Delegationsaufwand. Es wird nicht behauptet, die individuellen Kontingentverhältnisse beider Modelle zu kennen, und es werden keine Ausfallwahrscheinlichkeiten oder Einsparprozentsätze erfunden.
Vor der Ausführung
Zunächst routing-policy.md lesen. Nur eine kurze Klassifizierung vornehmen, nicht die gesamte Aufgabe lösen, um ein Modell auszuwählen. Entscheidungen auf Basis von vorhandenem Kontext, Aufgabenumfang und überprüfbaren Fakten treffen; Textlänge, Zeitaufwand und Dateianzahl allein bestimmen nicht das Modell. Wenn der Benutzer ein Modell explizit vorgibt, hat dies Vorrang. Wenn die Diskussion lediglich den Routing-Mechanismus betrifft, nur die Frage beantworten, ohne die Ausführung zu starten.
Eine Zeile ausgeben: "Empfohlenes Modell: …; Nacharbeitsrisiko: …; Begründung: …". Nur wenn der Host das tatsächliche Modell bestätigt, darf "Aktuelles Ausführungsmodell" geschrieben werden. Wenn die Aufgabe bereits über das CLI als geroutet markiert wurde, direkt ausführen, kein erneutes Aufrufen des Verteilers oder rekursives Routing.
Desktop-Aufgaben
Dieses Skill führt die Beurteilung erst durch, nachdem es aufgerufen wurde – es ist kein globaler Interceptor vor dem Absenden einer Benutzernachricht. Es unterstützt implizite Erkennung, garantiert jedoch nicht, dass es bei jeder Nachricht automatisch geladen wird. Der zuverlässige Einstieg ist $task-model-router Aufgabenbeschreibung.
Wenn das aktuelle Modell mit der Empfehlung übereinstimmt, wird fortgefahren. Bei Abweichung wird vor der eigentlichen Ausführung eine Empfehlung gegeben; der Benutzer wird gebeten, im Eingabefeld unten auf das gewählte Modell umzuschalten und dann "Weiter" zu senden. Der aktuelle Aufgabenkontext bleibt erhalten; es wird nicht verlangt, das gesamte Material erneut einzufügen. Es werden keine globalen Einstellungen geändert, keine selbstreferenziellen Nachrichten an die aktuelle Aufgabe gesendet und nicht behauptet, dass eine textuelle Empfehlung den Modellwechsel durchgeführt hat. Wenn das aktuelle Modell nicht überprüft werden kann, wird dies explizit als unbekannt angegeben; es wird nicht wiederholt blockiert: Nachdem der Benutzer die Auswahl bestätigt oder explizit die Verwendung des aktuellen Modells gefordert hat, wird fortgefahren.
Nur wenn der Benutzer explizit eine neue Desktop-Aufgabe anfordert, wird über den Host mittels create_thread unter Angabe des Modells eine neue erstellt, wobei die Projekt-/Arbeitsverzeichnisregeln eingehalten werden. Native Sub-Agents sind kein Vorwand, um das Desktop-Hauptmodell zu ersetzen.
Ausführung und Luna-Delegation
Beide Hauptmodelle folgen luna-delegation-policy.md. Wenn es unabhängige, klar abgegrenzte und delegierenswerte repetitive Arbeiten gibt, wird ein gpt-5.6-luna Sub-Agent erstellt; andernfalls führt das Hauptmodell direkt aus. Das Hauptmodell ist verantwortlich für Planung, kritische Schlussfolgerungen, Integration und risikogerechte Verifikation.
Wenn Sols Kernannahmen widerlegt werden, Kettenauswirkungen auftreten oder ein nicht erklärbarer signifikanter Nacharbeitsaufwand entsteht, wird anhand der verbleibenden Aufgabenkosten neu bewertet, ob ein Upgrade auf Astra erforderlich ist. Netzwerkfehler, fehlende Berechtigungen und API-Drosselung bedeuten nicht automatisch unzureichende Reasoning-Fähigkeiten. Bereits validierte Arbeit, gescheiterte Annahmen, aktueller Dateistatus und offene Fragen bleiben erhalten; es ist verboten, Aufgaben mit bereits erzeugten Seiteneffekten automatisch von Grund auf neu zu starten. Auf dem Desktop wird ein Hinweis zum Wechseln angezeigt; im CLI wird das Upgrade und Übergabeinformationen gemeldet, die Aufgabe wird nicht selbstständig wiederholt.
CLI-Automatikeinstieg
Das Skript scripts/route-codex.ps1 -Prompt 'Aufgabe' -WorkingDirectory 'Projektpfad' aus demselben Verzeichnis ausführen; standardmäßig wird zuerst eine leichte semantische Klassifizierung mit Sol durchgeführt, dann die Ausführung mit dem ausgewählten Modell. Die Klassifizierung verbraucht Kontingent. -RouteOnly führt nur die Klassifizierung durch (ruft trotzdem ein Modell auf); -Model sol|astra ist eine explizite Benutzerüberschreibung, die die Klassifizierung überspringen kann. Die standardmäßige Ausführungsumgebung ist read-only; wenn Änderungen autorisiert sind, explizit -Sandbox workspace-write übergeben. Der Einstieg bietet keine Optionen zur Umgehung von Genehmigungen oder Sandbox-Einstellungen. Normale Benutzerkonfiguration, Authentifizierung und Projektanweisungen bleiben in Kraft.
Für große Aufgaben eine UTF-8-Datei mit -PromptFile verwenden; für vorhandene Pläne/Hintergrundinformationen -ContextFile. Hintergrundtests, Nutzung und Implementierungsgrenzen sind in usage.md dokumentiert. Fehlendes CLI, nicht verfügbare Modelle, fehlgeschlagene Klassifizierung oder ungültiges JSON werden gemeldet, ohne die Ausführung zu starten; es erfolgt kein stilles Downgrade und keine unendlichen Wiederholungsversuche.