Con GPT-5.6 ya no tenemos un único modelo para programar, sino tres familias con perfiles distintos: Luna, Terra y Sol. Además, cada una puede trabajar con diferentes niveles de razonamiento —Low, Medium, High, XHigh, etc.—, por lo que la elección ya no consiste simplemente en buscar “el modelo más potente”. En herramientas como OpenCode, lo interesante es asignar cada modelo a la parte del trabajo donde realmente aporta más valor.

Una forma sencilla de resumirlo sería:

Sol piensa. Luna y Terra construyen. Sol revisa.

🌙 Luna: el modelo para programar

GPT-5.6 Luna está orientado a ofrecer mucha capacidad con menor coste y latencia. Y no deberíamos confundir “más barato” con “sólo sirve para tareas simples”.

En un flujo de desarrollo con agentes, Luna puede ser perfectamente el modelo que escriba la mayor parte del código. Es una buena opción para:

• Implementar funcionalidades normales.
• Corregir bugs acotados.
• Crear tests.
• Modificar endpoints.
• Trabajar sobre componentes concretos.
• Generar código siguiendo patrones existentes.
• Hacer refactors pequeños.
• Cambios repetitivos o mecánicos.

Como configuración inicial, una combinación especialmente interesante es:

Luna + High

Es decir, utilizamos un modelo eficiente, pero le damos suficiente capacidad de razonamiento para resolver correctamente la mayor parte del desarrollo cotidiano.

Por ejemplo:

Añade validación de email al formulario de registro, actualiza la API y crea los tests necesarios siguiendo los patrones existentes.

Para cambios muy simples podríamos bajar a Medium o Low. Y si Luna High empieza a quedarse corto antes de cambiar de modelo podemos probar:

Luna + XHigh

Ésta es una idea importante: no siempre necesitamos subir inmediatamente a Terra o Sol; podemos aumentar primero el nivel de razonamiento.

🌍 Terra: cuando aumenta el tamaño del problema

GPT-5.6 Terra ocupa el punto intermedio. Tiene sentido cuando Luna puede resolver cada pieza individualmente, pero el cambio empieza a requerir mantener más contexto, más archivos y más dependencias coordinadas.

Por ejemplo:

• Features grandes.
• Cambios que afectan frontend, backend y base de datos.
• Refactors amplios.
• Migraciones.
• Modificaciones que atraviesan varios módulos.
• Cambios a nivel de repositorio.

Una buena referencia sería:

Terra + Medium → features grandes

Terra + High → cambios amplios o repo-wide

Imaginemos que queremos implementar recuperación de contraseña. No hablamos ya de modificar una función, sino de coordinar:

• Base de datos.
• Generación de tokens.
• Endpoints.
• Envío de correo.
• Frontend.
• Expiración.
• Tests.

Aquí Terra Medium puede ser una opción más adecuada que Luna. Y si tenemos algo como:

Sustituye el sistema de autenticación actual en todo el repositorio manteniendo compatibilidad con las APIs existentes.

podríamos pasar a:

Terra + High

La diferencia está principalmente en el alcance del problema.

☀️ Sol: planificación, arquitectura y revisión

GPT-5.6 Sol es donde reservaría la mayor capacidad de razonamiento. Pero eso no significa que tenga que escribir todo nuestro código. De hecho, una estrategia especialmente eficiente consiste en hacer justo lo contrario:

Utilizar Sol donde necesitamos juicio y Luna/Terra donde necesitamos volumen.

Sol resulta especialmente útil para:

• Entender problemas complejos.
• Diseñar arquitectura.
• Preparar planes de implementación.
• Evaluar distintas soluciones.
• Detectar riesgos.
• Debugging especialmente difícil.
• Revisar cambios importantes.
• Realizar una revisión final antes de desplegar.

La configuración de referencia sería:

Sol + High

Por ejemplo, antes de implementar una feature:

Analiza cómo introducir multi-tenancy en esta aplicación. Identifica cambios de arquitectura, aislamiento de datos, riesgos de seguridad, estrategia de migración y tests necesarios. No modifiques código todavía.

Aquí queremos que el modelo piense qué debemos construir. Después podemos entregar ese plan a Luna o Terra para implementarlo. Y una vez terminado:

Revisa el diff completo buscando regresiones, problemas de seguridad, errores de concurrencia y casos límite. No modifiques nada todavía.

Volvemos a utilizar Sol High.

Es decir:

• Sol → planifica
• Luna/Terra → implementan
• Sol → revisa

🧠 ¿Qué nivel de razonamiento utilizar?

Además de elegir la familia tenemos que elegir cuánto esfuerzo queremos que dedique el modelo. No hay una combinación perfecta, pero como referencia práctica:

⚡ Low: para tareas claras y mecánicas

Para tareas muy claras o prácticamente mecánicas.

Ejemplos:

• Renombres.
• Localizar referencias.
• Cambios repetitivos.
• Correcciones sencillas.
• Transformaciones de código muy definidas.

Especialmente útil con Luna.

⚖️ Medium: el punto de equilibrio

Un buen punto de equilibrio cuando existe razonamiento, pero el problema está relativamente acotado. Puede funcionar bien para:

• Features normales.
• Tests.
• Bugs conocidos.
• Implementaciones con requisitos claros.

🔍 High: cuando queremos que piense antes de actuar

Probablemente sea el nivel más interesante para desarrollo con agentes. Tiene sentido cuando queremos que el modelo analice antes de actuar. Por ejemplo:

• Luna High para programación diaria.
• Terra High para cambios grandes.
• Sol High para planificación y revisión.

🚀 XHigh: para problemas que necesitan más profundidad

Lo utilizaría como escalado puntual. Por ejemplo:

Luna High → Luna XHigh

Si el modelo está cerca de resolver correctamente la tarea pero necesita algo más de razonamiento. También puede tener sentido con Sol en debugging o problemas especialmente difíciles aunque no lo utilizaría como configuración permanente.

🧨 Max: sólo para situaciones excepcionales

Lo reservaría para situaciones excepcionales. Seguridad, migraciones críticas, problemas extremadamente ambiguos o decisiones donde equivocarse tenga un coste muy alto. Más razonamiento no significa automáticamente mejor resultado para todas las tareas.

🛠️ Una estrategia práctica para OpenCode

Si queremos trasladar todo esto a OpenCode, podemos utilizar una tabla muy sencilla:

Esto encaja especialmente bien con los modos Plan y Build de OpenCode. Para una feature importante podríamos trabajar así:

1️⃣ Plan — Sol High

Primero dejamos que Sol analice el problema:

Diseña la implementación, identifica componentes afectados, riesgos, casos límite y tests. No modifiques código.

2️⃣ Build — Luna High

Con el plan decidido:

Implementa el plan siguiendo los patrones existentes del proyecto.

3️⃣ Escalar a Terra cuando aumenta el alcance

Si durante la implementación aparecen muchas dependencias:

Terra Medium o High.

4️⃣ Review — Sol High

Finalmente volvemos a Sol:

Revisa todo lo implementado y busca errores, regresiones y casos límite antes de dar el trabajo por terminado.

💸 ¿Por qué no utilizar Sol para todo?

La tentación evidente es seleccionar Sol High —o incluso XHigh— y olvidarnos del resto. Funcionará. Pero seguramente estaremos utilizando el modelo más caro precisamente en la parte del proceso que genera más tokens: la implementación. Una estrategia más eficiente consiste en hacer lo contrario:

Los modelos caros toman decisiones. Los modelos eficientes producen volumen.

Por eso Luna tiene un papel mucho más importante del que puede parecer inicialmente. En lugar de utilizarlo únicamente para tareas triviales, podemos convertir Luna High en nuestro desarrollador habitual. Terra entra cuando aumenta el alcance. Y Sol aparece en los momentos donde una buena o mala decisión puede determinar el resto del trabajo.

🎯 La regla fácil de recordar

Si tuviera que reducir todo GPT-5.6 en OpenCode a tres líneas:

• Luna High → programa.
• Terra Medium/High → programa cuando el cambio crece.
• Sol High → piensa y revisa.

Después podemos subir o bajar el reasoning según la dificultad concreta.

La gran ventaja de GPT-5.6 no es simplemente tener tres modelos entre los que elegir, es poder orquestarlos durante una misma tarea, utilizando cada uno justo donde aporta más valor. Y probablemente ésa sea una forma bastante más eficiente de desarrollar con OpenCode que mantener permanentemente seleccionado el modelo más potente disponible.

🤖 ¿Quieres llevar la IA a procesos reales de tu empresa?

Elegir el modelo adecuado es sólo una parte del camino. El verdadero valor aparece cuando la IA se integra correctamente en aplicaciones, procesos, datos y equipos de trabajo.

En Solucionex ayudamos a las empresas a llevar la IA a producción: desde modernizar aplicaciones y acelerar el desarrollo de software hasta crear agentes, automatizar procesos, explotar el conocimiento corporativo o convertir prototipos de IA en soluciones robustas y escalables.

Si estás valorando cómo aplicar la inteligencia artificial en tu empresa, podemos ayudarte a identificar los casos de uso con mayor impacto y convertirlos en proyectos reales.