Codex Sol puede dirigir Luna Max, pero las cuentas de cuota no están demostradas

Los usuarios de Codex Sol están probando una nueva división del trabajo: mantener al modelo insignia al mando y enviar la implementación a Luna Max. La configuración plantea un conflicto directo entre calidad y consumo. Sol planifica y revisa, mientras un trabajador Luna personalizado escribe código sin ocupar cada turno del hilo principal.

La idea procede de una publicación de AYi AI Notes. Propone crear luna-worker.toml en ~/.codex/agents/, seleccionar gpt-5.6-luna y establecer el esfuerzo de razonamiento en max. Codex Sol actúa entonces como orquestador, es decir, el agente que divide las tareas, delega el trabajo y evalúa los cambios devueltos.

El mecanismo de configuración es real y está documentado. El supuesto ahorro de cuota y la duplicación de la producción no han sido verificados de forma independiente. Esa distinción importa porque OpenAI advierte que los flujos de trabajo con subagentes pueden consumir más tokens que ejecuciones comparables con un solo agente. El resultado depende menos del nombre del archivo que del trabajo que se delegue.

El patrón de Codex Sol separa el criterio de la implementación

El cambio importante no es simplemente acceder a otro modelo. Es separar el criterio arquitectónico de la ejecución.

OpenAI describe los subagentes de Codex como agentes especializados que realizan el trabajo asignado en hilos independientes. El agente principal puede generarlos, esperar sus resultados, enviar instrucciones de seguimiento y combinar su trabajo en una única respuesta.

Esa estructura permite a Codex Sol conservar las decisiones con un amplio radio de impacto. Entre ellas se incluyen la descomposición de tareas, el diseño de interfaces, la elección de dependencias, los criterios de aceptación y la revisión final del código. Un trabajador Luna recibe un contrato más acotado y se encarga de la implementación dentro de ese límite.

La documentación sobre subagentes de OpenAI confirma que los clientes locales de Codex admiten archivos de agentes personales en ~/.codex/agents/. En cambio, las definiciones específicas de un proyecto pueden residir en .codex/agents/ dentro de un repositorio.

Cada archivo de agente independiente debe incluir tres campos:

• name, que identifica el rol del agente

• description, que ayuda a Codex a decidir cuándo encaja el rol

• developer_instructions, que definen su comportamiento de trabajo

El archivo también puede anular la configuración normal de la sesión. Esto incluye model, model_reasoning_effort, controles de sandbox, herramientas y configuración de habilidades.

Una versión representativa de la configuración comunicada tendría este aspecto:

Este ejemplo refleja el formato de configuración documentado. No reproduce un archivo verificado del autor de la publicación original, cuyas instrucciones completas no estaban disponibles en el material de origen.

La distinción importa porque la selección del modelo por sí sola no crea un trabajador fiable. La descripción influye en el enrutamiento, mientras que las instrucciones para desarrolladores definen el alcance, las obligaciones de prueba y las condiciones de detención. Un perfil impreciso puede convertir un agente de implementación enfocado en otra conversación de propósito general.

El archivo tampoco convierte automáticamente cada solicitud de programación en una tarea para Luna. Las versiones actuales de Codex delegan tras una petición directa o cuando las instrucciones o habilidades aplicables del proyecto requieren delegación. Los usuarios siguen necesitando una regla de enrutamiento que indique a Sol qué trabajo corresponde al trabajador.

Esa regla puede incluirse en el prompt, en un AGENTS.md del proyecto o en otra capa de instrucciones aplicable. Una política útil reserva la arquitectura y la revisión para Sol, y luego dirige unidades de implementación acotadas a Luna.

El patrón cuestiona el hábito predeterminado de mantener un único modelo insignia ligado a cada paso. Trata la capacidad de los modelos como una cartera, en lugar de como una única configuración.

Por qué Luna Max es una elección inusual como trabajador

Luna Max combina un modelo orientado a la eficiencia con el nivel de razonamiento documentado más alto, creando un experimento deliberado entre calidad y consumo.

OpenAI posiciona gpt-5.6-sol como el modelo insignia para trabajos exigentes. Describe gpt-5.6-terra como un equilibrio entre capacidad y eficiencia, mientras que gpt-5.6-luna se orienta a tareas claras, repetibles y de gran volumen.

Esa orientación convierte a Luna en un trabajador lógico para la implementación cuando Sol ya ha eliminado la ambigüedad. Una tarea pequeña, como añadir un endpoint validado, actualizar un componente o implementar una migración especificada, tiene un espacio de soluciones más claro que diseñar el sistema que la rodea.

El razonamiento máximo cambia ese perfil. El esfuerzo de razonamiento controla cuánto trabajo interno puede dedicar un modelo compatible a explorar y verificar una respuesta. OpenAI afirma que los ajustes más altos pueden mejorar el trabajo complejo, pero también incrementan el tiempo de respuesta y el uso de tokens.

La guía sobre GPT-5.6 de la empresa recomienda Luna para cargas de trabajo eficientes y de gran volumen. Recomienda max para tareas exigentes que requieren mayor exploración y verificación.

Por tanto, combinar ambas configuraciones no es la opción de eficiencia más evidente. Luna aporta el nivel de modelo inferior, mientras que Max pide a ese modelo que piense con mayor profundidad. La apuesta es que esta combinación conserve suficiente calidad de implementación sin pagar por el criterio de nivel Sol en cada turno del trabajador.

Esto puede funcionar cuando la descomposición ya ha reducido la incertidumbre. Considérese una migración de repositorio con diez adaptadores independientes. Sol puede identificar la interfaz compartida, definir invariantes y especificar pruebas. Los trabajadores Luna pueden implementar después adaptadores individuales con arreglo al mismo contrato.

La economía se debilita cuando los trabajadores deben redescubrir la arquitectura. Si cada agente Luna lee todo el repositorio, debate los requisitos, revisa su plan y vuelve a intentar cambios amplios, el razonamiento Max puede eliminar el ahorro esperado.

La configuración también ejerce una nueva presión sobre la calidad de los prompts. Una persona que utiliza un agente puede resolver la ambigüedad de forma interactiva. Un orquestador debe convertir esa ambigüedad en una orden de trabajo acotada antes de delegar.

Las mejores órdenes de trabajo identifican el objetivo exacto, los archivos relevantes, las restricciones, el comando de prueba, el resultado esperado y las condiciones que requieren escalamiento. También indican al trabajador qué no debe cambiar.

Aquí es donde Codex Sol se gana su lugar en el flujo de trabajo. Sol no debería limitarse a reenviar el prompt del usuario. Debería transformar la solicitud en unidades de implementación con una propiedad clara y criterios de finalización medibles.

Para los desarrolladores, esto se parece a un responsable técnico experimentado que asigna trabajo a colaboradores. El responsable protege la arquitectura e integra los resultados. Los colaboradores trabajan de forma independiente dentro de una superficie definida.

La analogía tiene límites porque los modelos no conservan una comprensión organizativa como compañeros de equipo a largo plazo. Cada agente sigue necesitando contexto suficiente, y cada paquete adicional de contexto conlleva costes de consumo y coordinación.

Los equipos que ya mantienen una base de conocimiento de ingeniería consultable tienen una ventaja en este caso. Las convenciones estables, las notas de arquitectura y las pautas de prueba proporcionan al orquestador mejor material para asignaciones acotadas.

Por tanto, Luna Max no es un trabajador barato universal. Es un perfil de ejecución especializado cuyo valor aumenta a medida que se aclaran los límites de las tareas.

El verdadero rival es la programación con un solo modelo

La competencia central es el enrutamiento orquestado de modelos frente a ejecutar cada paso de programación mediante un único modelo de alta capacidad.

Una sesión de Codex con un solo modelo es fácil de entender. Un agente explora el repositorio, hace preguntas, redacta el plan, edita archivos, ejecuta pruebas, diagnostica fallos y revisa su propio trabajo.

Esa continuidad tiene un valor real. El agente mantiene las decisiones en un único contexto y evita resumirlas para otro hilo. Las tareas pequeñas suelen beneficiarse de esta simplicidad, ya que la sobrecarga de delegación superaría el trabajo de implementación.

El coste aparece a medida que las tareas crecen. Los registros de exploración, la salida de pruebas, los enfoques abandonados y los detalles de implementación se acumulan en la misma conversación que contiene los requisitos y las decisiones arquitectónicas.

OpenAI denomina a estos efectos contaminación del contexto y degradación del contexto. La información importante se vuelve más difícil de recuperar a medida que el hilo se llena de material menos relevante. La empresa afirma que los subagentes ayudan al trasladar el trabajo ruidoso fuera de la conversación principal y devolver resultados depurados.

Codex Sol se convierte en el custodio de las decisiones duraderas en la configuración propuesta. Su hilo debería contener el objetivo, las restricciones del sistema, el mapa de tareas, las decisiones de integración, los hallazgos de la revisión y el estado final.

Los trabajadores Luna absorben el ruido local. Inspeccionan los archivos pertinentes, generan parches, ejecutan pruebas enfocadas y devuelven comprobantes concisos. Su investigación sin procesar no necesita ocupar el contexto principal de Sol.

Esto puede mejorar más que el uso de cuota. También puede reducir el riesgo de que un rastro de implementación largo desplace un requisito inicial fuera de la atención práctica. El orquestador ve resúmenes en lugar de cada comando fallido.

Sin embargo, la delegación crea otra forma de sobrecarga. Sol debe preparar los prompts de los trabajadores, supervisar el progreso, interpretar los resultados, inspeccionar los cambios y, en ocasiones, devolver una tarea para su revisión.

Las escrituras en paralelo añaden otro problema. OpenAI recomienda comenzar con trabajo de subagentes intensivo en lectura porque las ediciones simultáneas de código pueden entrar en conflicto e incrementar los costes de coordinación. Dos agentes que modifican el mismo módulo compartido pueden generar parches razonables por separado que fallen al combinarse.

Por ello, un flujo de trabajo sensato con Codex Sol separa el trabajo por propiedad. Un trabajador podría actualizar un controlador de backend, otro añadir pruebas aisladas y un tercero auditar la documentación. Los tipos compartidos y la configuración central deberían permanecer bajo un único responsable.

Los worktrees de Git o los archivos estrictamente separados pueden reducir la interferencia, pero no eliminan los conflictos semánticos. Dos cambios pueden compilar por separado y, aun así, asumir condiciones incompatibles sobre el mismo contrato.

El orquestador también debe distinguir la implementación de la revisión. Pedir a Luna que escriba código y aceptar después su propio resultado debilita la división del trabajo. Sol debería inspeccionar el diff frente a la tarea original, verificar las pruebas y buscar cambios que excedan el alcance.

Ese papel de revisión es el argumento más sólido para mantener a Sol en la cima. El modelo insignia dedica su capacidad a puntos de alto apalancamiento, en lugar de a ediciones repetitivas.

Una secuencia típica seguiría cinco etapas:

1. Sol investiga la solicitud y define el límite arquitectónico.

2. Sol convierte el plan en asignaciones independientes y comprobables.

3. Luna Max implementa las asignaciones seleccionadas en hilos separados.

4. Sol revisa los diffs devueltos, la evidencia de pruebas y los riesgos sin resolver.

5. Sol integra el trabajo aceptado y ejecuta una validación más amplia.

Esta secuencia no es automáticamente más rápida. Funciona mejor cuando varias asignaciones pueden avanzar de forma independiente o cuando la implementación genera grandes cantidades de contexto prescindible.

Para un error en un solo archivo con una solución evidente, el agente principal probablemente pueda terminar antes de que un trabajador reciba suficiente contexto. Para una función amplia que afecte a paquetes independientes, la orquestación tiene más margen para compensar su sobrecarga.

Por tanto, la comparación adecuada no es Sol frente a Luna. Es un hilo continuo y costoso frente a una jerarquía que dedica distintos tipos de atención en distintas etapas.

La afirmación de duplicar la producción aún necesita evidencia

Actualmente no existe ningún benchmark público que demuestre que esta configuración de Codex Sol reduce a la mitad el uso de cuota o duplica el trabajo completado.

La publicación social original presenta un resultado atractivo: ahorrar cuota y producir el doble. Esa afirmación debería tratarse como un informe de flujo de trabajo personal, no como una garantía de producto medida.

OpenAI afirma explícitamente que los flujos de trabajo con subagentes consumen más tokens que ejecuciones comparables con un único agente. Cada hijo realiza su propio trabajo de modelo y herramientas, mientras que el padre sigue consumiendo tokens para crear tareas y sintetizar resultados.

Esa advertencia no demuestra que la configuración descrita sea ineficiente. Muestra que la eficiencia no puede inferirse simplemente por usar Luna. El diseño de la carga de trabajo determina si la ejecución en un nivel inferior compensa la orquestación adicional.

Se necesitan al menos cuatro mediciones para evaluar la afirmación.

En primer lugar, los usuarios necesitan el consumo total del padre y de cada hijo. Mirar únicamente el hilo de Sol produciría un resultado engañoso, porque el uso de los trabajadores pertenece al mismo flujo de trabajo.

En segundo lugar, necesitan la calidad de las tareas completadas. Un primer intento más barato no resulta más barato si Sol debe reescribir la mayor parte del parche. El retrabajo, las pruebas fallidas y los ciclos de revisión deben incluirse en el cálculo.

En tercer lugar, necesitan medir el tiempo de ejecución real. Los trabajadores en paralelo pueden reducir el tiempo transcurrido mientras consumen más tokens en total. Esa compensación aún puede valer la pena, pero no supone una reducción de cuota.

En cuarto lugar, necesitan una referencia comparable. El mismo conjunto de tareas debería ejecutarse solo con Sol, con Sol y Luna Max y, quizá, con Sol y Luna con un nivel de razonamiento inferior. De lo contrario, la dificultad de las tareas puede explicar la diferencia.

El esfuerzo de razonamiento merece un escrutinio especial. OpenAI afirma que un mayor esfuerzo incrementa el uso de tokens y la latencia. Max puede mejorar los resultados en trabajos difíciles, pero aplicarlo a ediciones rutinarias puede desperdiciar la eficiencia que se buscaba obtener con Luna.

Una política de enrutamiento basada en la dificultad de la tarea sería más creíble que una configuración permanente. Los cambios mecánicos claros podrían usar un razonamiento menor, mientras que Max seguiría disponible para tareas delimitadas con casos límite difíciles.

La afirmación social también plantea problemas de verificación en tiempo de ejecución. Un archivo personalizado puede especificar un modelo, pero los desarrolladores deberían confirmar que el hilo generado recibió realmente el rol, el modelo y el nivel de razonamiento solicitados.

Esta preocupación no es teórica. Un informe de error de la comunidad describió hijos que heredaban la configuración del padre durante un despliegue cambiante de múltiples agentes. Respuestas posteriores informaron soluciones alternativas de configuración, pero el comportamiento en tiempo de ejecución variaba según la compilación y la superficie de herramientas.

Otro problema de Codex documentó una discrepancia entre los archivos de agentes personalizados y las sesiones respaldadas por herramientas. El informe indicaba que los agentes de proyecto válidos no se exponían mediante la interfaz de generación disponible.

Estos informes no establecen que los agentes personalizados actuales estén rotos. La documentación actual de OpenAI indica que los valores de los archivos de agentes tienen prioridad sobre la configuración heredada. Los informes muestran por qué los usuarios deberían inspeccionar los metadatos reales de los hijos en lugar de confiar en la intención.

Una prueba fiable debería registrar lo siguiente para cada asignación:

• Rol de agente solicitado

• Modelo resuelto

• Esfuerzo de razonamiento resuelto

• Archivos modificados

• Comandos de prueba y resultados

• Resultado de la revisión del padre

• Número de ciclos de revisión

• Uso total en todos los hilos

• Tiempo transcurrido de extremo a extremo

La comparación resultante debería usar trabajo representativo. Un benchmark que contenga solo código repetitivo favorece al modelo trabajador, mientras que uno compuesto únicamente por ambigüedad arquitectónica favorece a Sol. El desarrollo real combina ambos.

Los equipos también deberían incluir mecanismos de contención de fallos. Un trabajador debe detenerse cuando su tarea requiere una decisión arquitectónica que no se le proporcionó. Improvisar esa decisión silenciosamente genera costes de revisión e inconsistencias ocultas.

La instrucción más segura para los desarrolladores no es “termina a toda costa”. Es “implementa dentro de este límite y escala cuando el límite sea insuficiente”.

Esto cambia el significado de productividad. Generar más código no equivale automáticamente a producir más. La unidad relevante son los cambios aceptados que superan las pruebas y preservan la intención del diseño.

Hasta que aparezcan mediciones controladas, “duplicar la producción” sigue siendo una hipótesis que vale la pena probar, no un resultado que los lectores puedan asumir.

Qué deberían vigilar ahora los usuarios de Codex Sol

Tres señales determinarán si los trabajadores Luna liderados por Sol se convierten en un flujo de trabajo duradero o siguen siendo un experimento de optimización.

La primera señal es el enrutamiento de modelos verificable. Los clientes de Codex deben facilitar la inspección del rol de hijo resuelto, el modelo, el esfuerzo de razonamiento y el modo de permisos.

La documentación de OpenAI indica que los valores definidos en un archivo de agente personalizado tienen prioridad. También explica que la configuración omitida puede proceder de un valor de generación explícito, de un valor predeterminado de [agents] o de la sesión del padre.

Ese orden de resolución es flexible, pero la flexibilidad puede ocultar errores. Un desarrollador que solicita Luna Max debería poder confirmar Luna Max sin buscar en registros de sesión sin procesar ni aplicar ingeniería inversa a una llamada de herramienta.

Si las próximas versiones de Codex hacen que esa verificación sea consistente en la aplicación, la CLI, el IDE y las sesiones respaldadas por herramientas, el patrón liderado por Sol ganará credibilidad. Si el enrutamiento sigue dependiendo de un comportamiento específico del cliente, los ahorros declarados seguirán siendo difíciles de reproducir.

La segunda señal es la medición a nivel de carga de trabajo. Los usuarios necesitan paneles que atribuyan consumo, latencia, reintentos y resultados aceptados en todo un árbol de agentes.

Un hilo padre puede parecer eficiente porque la implementación se trasladó a otro lugar. Sin informes agregados, es imposible saber si la delegación ahorró cuota o simplemente la redistribuyó.

La métrica más útil combinaría el uso total con las tareas aceptadas. Los equipos podrían entonces comparar el trabajo solo con Sol frente al trabajo de Luna orquestado por Sol en el mismo repositorio y conjunto de evaluación.

La calidad debe seguir siendo visible junto al consumo. Un perfil de trabajador que reduce el uso pero duplica el tiempo de revisión no ofrece una ventaja clara. Tampoco lo hace un flujo de trabajo paralelo que termina antes pero produce parches conflictivos.

La tercera señal es la aparición de convenciones de enrutamiento estables. Hoy, los usuarios pueden definir agentes personalizados e indicar a Codex que delegue. El problema más difícil es decidir cuándo debe producirse la delegación.

La configuración descrita ofrece una regla: Sol planifica y revisa, mientras Luna Max implementa. Es fácil de recordar, pero los equipos de producción necesitarán límites más precisos.

Una política madura podría enrutar:

• Arquitectura, depuración ambigua y decisiones de integración a Sol

• Exploración de repositorios y análisis de documentos a Terra

• Implementación acotada, migraciones repetitivas y pruebas aisladas a Luna

• Revisión sensible a la seguridad o transversal de vuelta a Sol

• Tareas conflictivas o insuficientemente especificadas de vuelta al padre antes de editar

Esos límites deberían evolucionar a partir de mediciones, no de la marca del modelo. Un trabajador Luna que funciona bien en una base de código puede tener dificultades en otra con pruebas escasas o convenciones no documentadas.

Los desarrolladores deberían comenzar con tareas fáciles de verificar. Entre los buenos candidatos se incluyen adiciones de pruebas aisladas, adaptadores basados en esquemas, migraciones mecánicas de API y componentes con criterios de aceptación explícitos.

Deberían evitar comenzar con rediseños de autenticación, migraciones de datos sin planes de reversión o cambios que abarquen varios subsistemas compartidos. Estas tareas depositan demasiado criterio oculto dentro de la asignación al trabajador.

El siguiente paso práctico es una prueba interna controlada. Seleccionen un pequeño conjunto de incidencias ya completadas, preserven sus requisitos originales y ejecútenlas mediante ambos flujos de trabajo. Comparen la producción aceptada, el consumo total, el tiempo transcurrido y el esfuerzo de revisión.

Mantengan el perfil luna-worker.toml limitado durante esa prueba. Exijan resúmenes de archivos, evidencia de pruebas y escalamiento explícito. Pidan a Codex Sol que revise cada diff con los mismos criterios de aceptación utilizados para la referencia.

Si el trabajador devuelve repetidamente cambios limpios y acotados, amplíen gradualmente su rango de tareas. Si Sol dedica un tiempo considerable a reparar o redescubrir decisiones, mejoren la descomposición antes de cambiar de modelos.

El patrón de Codex Sol y Luna Max apunta hacia un futuro creíble para la programación con IA: un modelo no necesita desempeñar todos los roles. Sin embargo, la orquestación no es una capa de eficiencia gratuita. Intercambia contexto continuo por enrutamiento, verificación y coordinación.

La pregunta útil no es si Luna puede escribir más código. Es si Sol puede definir el trabajo con suficiente claridad para que el código de Luna sobreviva a la revisión. Midan ese resultado en tareas reales y dejen que la evidencia decida cuánto de su cola de desarrollo delegar.