Enrutamiento de Frontera Eficiente

¿Qué hace Enrutamiento de Frontera Eficiente?

Empareja el modelo con el trabajo en Claude Code, Codex u otro agente que pueda iniciar subagentes en un modelo elegido (por ejemplo, CLI de Gemini o CLI de Antigravity), independientemente del modelo de la sesión principal. Una sesión principal más barata puede coordinar trabajo rutinario y consultar a un agente más fuerte; una sesión principal más fuerte puede delegar trabajo rutinario a agentes más baratos. Mantén las tareas pequeñas localmente cuando un traspaso costaría más que hacer el trabajo.

Ayuda y Configuración

Cuando se invoque con help o --help, lee ayuda de configuración, explica los controles y ejemplos, luego detente. No inicies trabajo delegado ni cambies configuraciones para una solicitud de ayuda. Para preguntas de configuración, lee la misma referencia; para tareas ordinarias, omítela.

Aplica las preferencias de enrutamiento desde la solicitud del usuario y los archivos de instrucción aplicables. Para las preferencias de esta habilidad, usa primero las instrucciones explícitas de la tarea, luego las preferencias del proyecto, luego las preferencias globales, luego los valores predeterminados a continuación. Los permisos del host, la disponibilidad del modelo y los límites aplicables aún se aplican. Los usuarios pueden elegir los modelos de descubrimiento, implementación y revisión; el esfuerzo por agente; los desencadenantes de escalada y el número de reintentos; un número máximo de subagentes concurrentes; y si la escalada requiere aprobación. Respeta un límite de modelo configurado o una preferencia de no delegación. Si una revisión requerida no se puede ejecutar dentro de esos límites, informa la revisión no cumplida en lugar de sustituirla silenciosamente. Estas son instrucciones interpretadas por el asistente, no configuraciones JSON ni un límite de gasto duro. No edites preferencias persistentes a menos que se solicite.

Flujo de Trabajo

1. Identifica decisiones que requieren un juicio más fuerte: arquitectura, ambigüedad, riesgo, evidencia conflictiva y revisión técnica final. Manéjalas en la sesión principal cuando sea adecuada para la tarea; de lo contrario, delega hacia arriba.
2. Identifica trabajo delegable: escaneos de investigación, inventario del repositorio, búsqueda, extracción de documentación, pases de navegador/pruebas, reducción de registros, agrupamiento de fallos de prueba, codificación específica y ediciones mecánicas.
3. Genera subagentes para traspasos justificados, paralelizando partes independientes con propiedad clara, alcance acotado, puertas de verificación y evidencia.
4. Exige retornos compactos: hallazgos, archivos cambiados, comandos ejecutados, riesgo residual, condiciones de parada alcanzadas y decisiones que necesitan síntesis o escalada.
5. Integra y revisa de forma centralizada antes de presentar el resultado.

Paquetes de Traspaso

Escribe mensajes delegados como paquetes autocontenidos. Asume que el agente receptor no ha visto la conversación. Incluye la ruta del repositorio, el objetivo, el alcance, las áreas fuera del alcance, los archivos relevantes o los objetivos de búsqueda, el formato de retorno esperado, los comandos de verificación y las condiciones de parada.

Condiciones de parada útiles:

• El código en vivo no coincide con la suposición en el traspaso.
• Un comando de verificación alcanza el límite de reintentos configurado (predeterminado: dos intentos fallidos después de correcciones razonables).
• El trabajo parece requerir archivos fuera del alcance asignado.
• El agente no puede producir evidencia concreta para su afirmación.

Bucle de Revisión

Trata la salida delegada como evidencia a inspeccionar, no como un veredicto a reenviar. Vuelve a abrir archivos citados importantes, hojea diferencias de alto riesgo y vuelve a ejecutar o verifica por muestreo la verificación que importa antes de reclamar finalización. Si los agentes delegados no están de acuerdo en una cuestión técnica difícil, usa un revisor más fuerte con la evidence. Mantén las decisiones del producto y los cambios de alcance con el usuario.

Escenarios Comunes

Úsalos como sugerencias suaves:

• Investigación: delega escaneos amplios del repositorio, extracción de documentación y comparación de fuentes; la sesión principal prioriza los resultados y escala juicios difíciles.
• Codificación: delega parches acotados, refactorizaciones o ediciones mecánicas cuando la propiedad del archivo esté clara; integra y revisa de forma centralizada.
• Pruebas: elige la estrategia de validación en el nivel de razonamiento apropiado, luego usa agentes más baratos para ejecutar verificaciones unitarias, flujos de navegador, capturas de pantalla y reducción de registros. Pídeles que devuelvan comandos exactos, fallos, causas probables y si la señal parece inestable, ambiental o relevante para el producto.
• Depuración: envía agentes independientes tras teorías separadas, registros o rutas de reproducción; escala el diagnóstico cuando la evidencia sigue siendo conflictiva.

Ejemplo Práctico

Una sesión principal Sonnet recibe "arregla las pruebas de pago fallidas y ajusta la regla de reembolso mientras lo haces", con preferencias del proyecto de Haiku para descubrimiento, Sonnet para implementación, Opus con esfuerzo alto para revisiones arriesgadas, y como máximo dos subagentes concurrentes.

1. El descubrimiento va a un subagente Haiku: ejecuta el conjunto de pruebas, agrupa los fallos y devuelve las pruebas fallidas, los archivos que tocan y los comandos exactos. Un segundo subagente Haiku mapea dónde reside la lógica de reembolsos.
2. Los fallos se agrupan en un fixture desactualizado. Es una corrección acotada y mecánica, por lo que la sesión principal la realiza localmente en lugar de pagar por un traspaso.
3. La regla de reembolso toca facturación, lo cual es de alto riesgo. Antes de editar, la sesión principal envía a Opus (solicitado explícitamente, effort: high) un paquete con los archivos de reembolso, el cambio propuesto, las pruebas actuales y una pregunta: ¿este cambio rompe alguna ruta de reembolso existente?
4. La sesión principal aplica el cambio, vuelve a ejecutar las pruebas por sí misma, vuelve a abrir los dos archivos que Opus señaló e informa qué modelo ejecutó cada paso, para que el usuario pueda ver que la revisión más fuerte realmente ocurrió.

Emparejamiento de Modelos

Usa los modelos disponibles del host y las asignaciones del usuario para elegir el nivel más barato adecuado, por encima o por debajo del modelo de la sesión principal:

Trabajo	Capacidad requerida	Ejemplos Claude	Codex y otros hosts
Descubrimiento, resúmenes, verificaciones factuales	Extracción rápida y precisa	Haiku	Un modelo rápido disponible adecuado para trabajo factual
Implementación acotada y pruebas	Codificación confiable dentro de patrones establecidos	Sonnet	Un modelo de codificación disponible adecuado para el alcance
Arquitectura, depuración profunda, revisión arriesgada	Razonamiento fuerte entre sistemas	Opus, o Fable donde esté disponible	Un modelo de razonamiento más fuerte disponible

Los nombres de Claude son ejemplos para sesiones de Claude, no alias para pasar a Codex. No inventes ID de modelo de Codex ni asumas una asignación uno a uno permanente entre proveedores. Inspecciona las opciones de modelo disponibles del host y usa nombres explícitos y válidos. Mantente con el proveedor actual para enrutamiento ordinario a menos que el usuario solicite lo contrario; aplica la regla separada de revisión de proveedor diferente cuando sea necesario. Selecciona el esfuerzo independientemente del modelo y respeta los límites de esfuerzo del usuario. No establezcas todos los agentes al esfuerzo más alto.

Una sesión principal más fuerte puede tomar decisiones difíciles directamente. Desde una sesión más barata, delega la decisión difícil o la revisión con un paquete de evidencia compacto, luego integra el resultado y ejecuta las comprobaciones requeridas. Si el host expone solo un modelo, mantén el trabajo en él e informa cualquier requisito de revisión más fuerte no cumplido. No reclames un nivel de modelo más alto solo porque el esfuerzo aumentó.

Escalada Desde una Sesión Principal Más Barata

Escala antes de implementar un cambio arquitectónico desconocido o un cambio en un invariante de alto riesgo, sujeto a la política de escalada del usuario. También escala cuando la evidencia es conflictiva o se alcanza el límite de reintentos (predeterminado: dos intentos razonables en el mismo problema técnico). Reutiliza la evidencia recopilada; no pagues por otra exploración amplia de los mismos archivos.

Trata autenticación, facturación, permisos, seguridad, migraciones, pérdida de datos, estado compartido, caché, concurrencia, comportamiento entre módulos, API públicas y flujos de trabajo visibles para el usuario como de alto riesgo. Usa el nivel adecuado más fuerte para la decisión o la revisión técnica. Cuando el usuario requiera una revisión por un modelo de un proveedor diferente para trabajo de alto riesgo, mantén esa revisión; agrega una perspectiva de un modelo diferente.

En Claude Code, solicita explícitamente el model del subagente en la llamada de Agente o usa un agente personalizado con model: opus (y effort: high cuando sea apropiado). Un modelo no especificado puede heredar el modelo principal más barato. Usa un subagente ordinario con un traspaso enfocado; una bifurcación de conversación usa el modelo principal. Verifica el modelo informado, usando /tasks cuando esté disponible. En Codex u otro host, establece explícitamente el modelo y el esfuerzo de razonamiento a través del selector por agente compatible con el host. Usa un traspaso de tarea enfocado si heredar la conversación completa impediría una anulación de modelo. Verifica la selección informada; si el host no puede seleccionar modelos por agente, informa esa limitación en lugar de simular enrutamiento.

Mantén la sesión principal en su modelo elegido. Esta es una instrucción de enrutamiento, no un enrutador automático en tiempo de ejecución ni una garantía de que el modelo más barato detectará cada caso difícil. Si el modelo requerido no está disponible o está restringido, informa la limitación en lugar de afirmar silenciosamente que ocurrió una revisión más fuerte.

Barreras de Protección

• Para un bloqueo inmediato, trabaja localmente a menos que la experiencia más fuerte o el aislamiento de contexto justifiquen un traspaso secuencial. Haz trabajo independiente mientras esperas cuando esté disponible.
• No pidas a múltiples agentes que editen los mismos archivos al mismo tiempo.
• No confíes ciegamente en las conclusiones de los subagentes cuando el riesgo sea alto; inspecciona la evidencia importante tú mismo.
• No reclames ahorros universales. El patrón funciona mejor cuando la exploración y la implementación, las pruebas o la investigación se pueden paralelizar.

Marco Predeterminado

"Mantendré el trabajo rutinario en el modelo actual o en uno más barato y delegaré decisiones difíciles o revisiones arriesgadas a un agente más fuerte cuando sea necesario."