Routage par frontière d'efficacité

Que fait Routage par frontière d'efficacité ?

Associez le modèle au travail dans Claude Code, Codex ou un autre agent pouvant lancer des sous-agents sur un modèle choisi (par exemple Gemini CLI ou Antigravity CLI), indépendamment du modèle de la session principale. Une session principale moins coûteuse peut coordonner un travail de routine et consulter un agent plus puissant ; une session principale plus puissante peut déléguer le travail de routine à des agents moins coûteux. Conservez les petites tâches en local lorsqu'une délégation coûterait plus cher que de faire le travail.

Aide et configuration

Lorsqu'elle est invoquée avec help ou --help, lisez l'aide à la configuration, expliquez les contrôles et exemples, puis arrêtez-vous. Ne commencez pas un travail délégué ni ne modifiez les paramètres pour une demande d'aide. Pour les questions de configuration, lisez la même référence ; pour les tâches ordinaires, ignorez-la.

Appliquez les préférences de routage de la demande de l'utilisateur et des fichiers d'instructions applicables. Pour les préférences de cette compétence, utilisez d'abord les instructions explicites de la tâche, puis les préférences du projet, puis les préférences globales, puis les valeurs par défaut ci-dessous. Les permissions de l'hôte, la disponibilité des modèles et les limites imposées s'appliquent toujours. Les utilisateurs peuvent choisir les modèles de découverte, d'implémentation et de revue ; l'effort par agent ; les déclencheurs d'escalade et le nombre de tentatives ; un nombre maximum de sous-agents simultanés ; et si l'escalade nécessite une approbation. Respectez un plafond de modèle configuré ou une préférence de non-délégation. Si une revue requise ne peut pas être exécutée dans ces limites, signalez la revue non effectuée au lieu de la remplacer silencieusement. Ces instructions sont interprétées par l'assistant, et non des paramètres JSON ou un plafond de dépenses strict. Ne modifiez pas les préférences persistantes sauf demande explicite.

Flux de travail

1. Identifiez les décisions nécessitant un jugement plus fort : architecture, ambiguïté, risque, preuves contradictoires et revue technique finale. Traitez-les dans la session principale lorsqu'elle est adaptée à la tâche ; sinon, déléguez vers le haut.
2. Identifiez le travail déléguable : analyses exploratoires, inventaire du dépôt, recherche, extraction de documentation, passages de navigation/tests, réduction de logs, regroupement d'échecs de test, codage ciblé et modifications mécaniques.
3. Lancez des sous-agents pour les délégations justifiées, en parallélisant les volets indépendants avec une propriété claire, un périmètre délimité, des portes de vérification et des preuves.
4. Exigez des retours compacts : conclusions, fichiers modifiés, commandes exécutées, risques résiduels, conditions d'arrêt atteintes et décisions nécessitant une synthèse ou une escalade.
5. Intégrez et révisez de manière centralisée avant de présenter le résultat.

Paquets de transmission

Rédigez les invites déléguées sous forme de paquets autonomes. Partez du principe que l'agent récepteur n'a pas vu la conversation. Incluez le chemin du dépôt, l'objectif, le périmètre, les éléments hors périmètre, les fichiers pertinents ou les cibles de recherche, le format de retour attendu, les commandes de vérification et les conditions d'arrêt.

Conditions d'arrêt utiles :

• Le code en direct ne correspond pas à l'hypothèse dans la transmission.
• Une commande de vérification atteint la limite de tentatives configurée (par défaut : deux tentatives échouées après des corrections raisonnables).
• Le travail semble nécessiter des fichiers en dehors du périmètre assigné.
• L'agent ne peut pas produire de preuves concrètes pour son affirmation.

Boucle de revue

Considérez les résultats délégués comme des preuves à inspecter, pas comme un verdict à transmettre. Rouvrez les fichiers cités importants, parcourez les diffs à haut risque, et réexécutez ou vérifiez par sondage la vérification qui importe avant de déclarer la tâche terminée. Si les agents délégués sont en désaccord sur une question technique difficile, utilisez un réviseur plus fort avec les preuves. Gardez les choix de produit et les changements de périmètre avec l'utilisateur.

Scénarios courants

Utilisez-les comme suggestions souples :

• Recherche : déléguez les analyses de dépôt larges, l'extraction de documentation et la comparaison de sources ; la session principale priorise les résultats et escalade les jugements difficiles.
• Codage : déléguez les correctifs limités, les refactorisations ou les modifications mécaniques lorsque la propriété du fichier est claire ; intégrez et révisez de manière centralisée.
• Tests : choisissez la stratégie de validation au niveau de raisonnement approprié, puis utilisez des agents moins coûteux pour exécuter les vérifications unitaires, les parcours de navigation, les captures d'écran et la réduction de logs. Demandez-leur de retourner les commandes exactes, les échecs, les causes probables et si le signal semble instable, environnemental ou lié au produit.
• Débogage : envoyez des agents indépendants sur des théories, des logs ou des chemins de reproduction séparés ; escaladez le diagnostic lorsque les preuves restent contradictoires.

Exemple travaillé

Une session principale Sonnet reçoit "corrige les tests d'achat qui échouent et resserre la règle de remboursement pendant que tu y es", avec les préférences de projet Haiku pour la découverte, Sonnet pour l'implémentation, Opus à effort élevé pour la revue risquée, et au maximum deux sous-agents simultanés.

1. La découverte va à un sous-agent Haiku : exécute la suite de tests, regroupe les échecs et retourne les tests échoués, les fichiers qu'ils touchent et les commandes exactes. Un deuxième sous-agent Haiku cartographie où se trouve la logique de remboursement.
2. Les échecs se regroupent sur un correctif obsolète. C'est une correction mécanique circonscrite, donc la session principale la fait localement plutôt que de payer pour une transmission.
3. La règle de remboursement touche à la facturation, ce qui est à haut risque. Avant de modifier, la session principale envoie à Opus (demandé explicitement, effort: high) un paquet avec les fichiers de remboursement, le changement proposé, les tests actuels et une question : ce changement casse-t-il un chemin de remboursement existant ?
4. La session principale applique le changement, réexécute les tests elle-même, rouvre les deux fichiers qu'Opus a signalés et indique quel modèle a exécuté chaque étape, afin que l'utilisateur puisse voir que la revue plus forte a effectivement eu lieu.

Correspondance des niveaux

Utilisez les modèles disponibles de l'hôte et les mappages de l'utilisateur pour choisir le niveau le moins cher approprié, au-dessus ou en dessous du modèle de la session principale :

Travail	Capacité requise	Exemples Claude	Codex et autres hôtes
Découverte, résumés, vérifications factuelles	Extraction rapide et précise	Haiku	Un modèle rapide disponible adapté au travail factuel
Implémentation et tests circonscrits	Codage fiable dans les motifs établis	Sonnet	Un modèle de codage disponible adapté au périmètre
Architecture, débogage profond, revue risquée	Raisonnement fort entre les systèmes	Opus, ou Fable si disponible	Un modèle de raisonnement plus fort disponible

Les noms Claude sont des exemples pour les sessions Claude, pas des alias à passer à Codex. N'inventez pas d'ID de modèle Codex et ne supposez pas un mappage biunivoque permanent entre les fournisseurs. Inspectez les choix de modèles disponibles de l'hôte et utilisez des noms valides explicites. Restez avec le fournisseur actuel pour le routage ordinaire sauf si l'utilisateur demande autrement ; appliquez la règle de révision par un fournisseur différent lorsque nécessaire. Sélectionnez l'effort indépendamment du modèle et respectez les limites d'effort de l'utilisateur. Ne mettez pas tous les agents par défaut à l'effort le plus élevé.

Une session principale plus forte peut prendre des décisions difficiles directement. Depuis une session moins coûteuse, déléguez la décision difficile ou la revue avec un paquet de preuves compact, puis intégrez le résultat et exécutez les vérifications requises. Si l'hôte n'expose qu'un seul modèle, gardez le travail dessus et signalez toute exigence de revue plus forte non satisfaite. Ne prétendez pas à un niveau de modèle supérieur simplement parce que l'effort a augmenté.

Escalade depuis une session principale moins coûteuse

Escaladez avant d'implémenter un changement architectural inconnu ou un changement dans un invariant à haut risque, sous réserve de la politique d'escalade de l'utilisateur. Escaladez également lorsque les preuves sont contradictoires ou que la limite de tentatives est atteinte (par défaut : deux tentatives raisonnables sur le même problème technique). Réutilisez les preuves rassemblées ; ne payez pas pour une autre exploration large des mêmes fichiers.

Considérez l'authentification, la facturation, les autorisations, la sécurité, les migrations, la perte de données, l'état partagé, la mise en cache, la concurrence, le comportement inter-modules, les API publiques et les flux de travail visibles par l'utilisateur comme à haut risque. Utilisez le niveau le plus fort approprié pour la décision ou la revue technique. Lorsque l'utilisateur exige une revue par un modèle d'un fournisseur différent pour les travaux à haut risque, conservez cette revue ; elle ajoute une perspective de modèle différent.

Dans Claude Code, demandez explicitement le model du sous-agent dans l'appel d'Agent ou utilisez un agent personnalisé avec model: opus (et effort: high le cas échéant). Un modèle non spécifié peut hériter du modèle principal moins coûteux. Utilisez un sous-agent ordinaire avec une transmission ciblée ; une fourche de conversation utilise le modèle principal. Vérifiez le modèle signalé, en utilisant /tasks lorsqu'il est disponible. Dans Codex ou un autre hôte, définissez explicitement le modèle et l'effort de raisonnement via le sélecteur par agent pris en charge par l'hôte. Utilisez une transmission de tâche ciblée si l'héritage de la conversation complète empêcherait une substitution de modèle. Vérifiez la sélection signalée ; si l'hôte ne peut pas sélectionner des modèles par agent, signalez cette limitation au lieu de simuler le routage.

Gardez la session principale sur son modèle choisi. Ceci est une instruction de routage, pas un routeur d'exécution automatique ni une garantie que le modèle moins coûteux détectera chaque cas difficile. Si le modèle requis est indisponible ou restreint, signalez la limitation au lieu de prétendre silencieusement qu'une revue plus forte a eu lieu.

Garde-fous

• Pour un blocage immédiat, travaillez localement sauf si une expertise plus forte ou une isolation du contexte justifie une transmission séquentielle. Effectuez un travail indépendant en attendant lorsque c'est possible.
• Ne demandez pas à plusieurs agents de modifier les mêmes fichiers en même temps.
• Ne faites pas aveuglément confiance aux conclusions des sous-agents lorsque le risque est élevé ; inspectez vous-même les preuves importantes.
• Ne prétendez pas à des économies universelles. Le modèle fonctionne mieux lorsque l'exploration et l'implémentation, les tests ou la recherche peuvent être parallélisés.

Cadre par défaut

"Je garderai le travail de routine sur le modèle actuel ou un modèle moins coûteux et je déléguerai les décisions difficiles ou les revues risquées à un agent plus fort lorsque nécessaire."