GPT-5.6 Sol, Terra y Luna: precios, modos y cuál usar

Tres nombres de cuerpos celestes y un montón de developers preguntándose lo mismo: ¿cuál pongo en el agente que me toca el repositorio de producción?

OpenAI presentó la familia GPT-5.6 el 26 de junio de 2026 con una peculiaridad que no habíamos visto antes: no la pudiste usar. El acceso quedó reservado a un puñado de organizaciones de confianza a través de la API y Codex, con el gobierno de Estados Unidos mirando por encima del hombro. Hoy, 9 de julio, se abre al público.

Así que ya toca hablar de esto en serio, no como noticia sino como decisión técnica.

Lo que vas a encontrar aquí:

• Qué significa exactamente que Sol, Terra y Luna sean “tiers” y no tres modelos sueltos.
• Los precios reales por millón de tokens y la letra pequeña de la caché de prompts.
• Qué son los modos max y ultra, y cuándo salen a cuenta.
• Lo que dice la system card sobre agentes que se pasan de listos (spoiler: es lo más importante del lanzamiento).
• Una tabla de enrutado por tarea y una batería de evaluación que puedes montar en una tarde.

Qué es GPT-5.6 y por qué el nombre importa esta vez ¶

GPT-5.6 no es un modelo. Es una generación con tres niveles de capacidad dentro.

OpenAI lo explica sin rodeos en su anuncio: el número identifica la generación del modelo, mientras que Sol, Terra y Luna identifican tiers de capacidad duraderos que pueden avanzar a su propio ritmo. Traducido: el año que viene puede haber un Luna mejor sin que nadie tenga que renombrar toda la familia.

Suena a detalle de marketing. No lo es.

Si has sufrido la nomenclatura de OpenAI durante los últimos dos años —GPT-5, GPT-5-Codex, GPT-5-Codex-Mini, GPT-5.3 Instant, gpt-5.3-codex en API pero otra cosa en producto— sabes que elegir modelo se había convertido en un ejercicio de arqueología. Este cambio separa dos ejes que siempre estuvieron mezclados: cuánto ha avanzado la tecnología (el número) y cuánta inteligencia estás dispuesto a pagar (el nombre).

La familia, según OpenAI, mejora en ingeniería de software, uso de ordenador, trabajo profesional basado en conocimiento, investigación científica y ciberseguridad. Cinco frentes. Fíjate en que cuatro de los cinco son cosas que hace un agente, no un chat.

🔑 El titular no es “hay un modelo más listo”. El titular es que OpenAI ha dejado de venderte un modelo y ha empezado a venderte una tabla de decisión.

Sol, Terra y Luna: quién es quién ¶

Aquí está el reparto oficial, sin adornos:

OpenAI afirma que Terra tiene un rendimiento competitivo con GPT-5.5 siendo el doble de barato, y que Luna aporta capacidad fuerte al menor coste de la casa.

La comunidad, mientras tanto, ha ido por otro lado. En Hacker News y en r/codex la lectura dominante fue mucho más prosaica: esto es un renombrado de full / mini / nano con nombres bonitos. Circuló incluso una equivalencia informal —Sol Ultra sería GPT-5.6 Pro, Sol el modelo grande, Terra el mini, Luna el nano— que no está en ninguna documentación oficial pero explica bien cómo lo está decodificando la gente que ya trabaja con Codex a diario.

¿Quién tiene razón? Las dos cosas pueden ser ciertas a la vez. Puede ser un renombrado y ser el renombrado más útil que ha hecho OpenAI. Si quieres ver dónde encaja esta familia frente a los Claude, los Gemini y los open-weights, la foto completa está en la comparativa de los mejores modelos de IA para programar.

Y sobre la confusión de siempre: es Terra, no “Tierra”. El juego es con los cuerpos celestes en latín: Sol, Terra, Luna. Sun, Earth, Moon. Si lo escribes mal en tu configuración, tu llamada a la API se va a quejar.

Curso gratis · paso a paso

El método que mantiene a raya al modelo, elijas el que elijas

Sol, Terra o Luna dan igual si el agente va por libre. Recorre el ciclo completo de Spec Driven Development con OpenSpec sobre un proyecto real y en modo asistido: lo ves funcionar entero antes de coger tú el volante.

Entra en el curso gratis →

Precios: los números que van a la factura ¶

Por cada millón de tokens:

Detente un segundo en la relación entre columnas. Salida cuesta seis veces más que entrada en los tres niveles. Ese ratio es el que de verdad decide tu factura cuando montas un agente que escribe código, porque un agente que escribe código genera muchísimo texto.

Y aquí viene la parte que casi nadie ha comentado, que es la caché.

GPT-5.6 introduce una caché de prompts más predecible: soporte para cache breakpoints explícitos y una vida mínima de caché de 30 minutos. A cambio, a partir de esta generación las escrituras en caché se facturan a 1,25 veces la tarifa de entrada sin caché, mientras que las lecturas mantienen el descuento del 90 %.

Léelo otra vez, porque tiene truco. Escribir en caché ahora cuesta un 25 % más. Leer de caché sigue costando un 10 %. Si tu prompt de sistema tiene tres mil tokens y lo reutilizas cuarenta veces en media hora, ganas. Si lo escribes en caché y lo usas dos veces, has pagado un recargo por nada.

💡 Los breakpoints explícitos son una invitación a rediseñar tus prompts en bloques: lo estable arriba (system, esquema, convenciones del repo), lo volátil abajo (el ticket concreto). Es un cambio de estructura, no un flag que activas y te olvidas.

Si el hilo del coste te interesa más que el del benchmark, ya desmenuzamos cómo bajar la factura eligiendo modelo por tipo de tarea en cómo gastar menos eligiendo el modelo correcto. Los números cambian, la lógica no.

Max y ultra: dos palancas nuevas ¶

Sol trae dos cosas que Terra y Luna no tienen.

La primera es un nivel de esfuerzo de razonamiento llamado max, pensado para darle al modelo todo el tiempo del mundo para pensar. La segunda es un modo ultra que va más allá de un solo agente: lanza subagentes para acelerar trabajo complejo.

¿Te suena? Debería. Es el patrón que muchos equipos llevan meses construyendo a mano con orquestadores externos, ahora servido como modo de primera clase. Cambia el andamiaje, no la estrategia, igual que ocurre cuando comparas agentes de terminal en Claude Code frente a OpenCode.

En Terminal-Bench 2.1, el benchmark que mide flujos de línea de comandos con planificación, iteración y coordinación de herramientas, la cobertura publicada sitúa a Sol en un 88,8 % y a Sol Ultra en un 91,9 %. Tres puntos por decomponer la tarea y ejecutar en paralelo.

Tres puntos que se pagan.

Cada subagente consume sus propios tokens. Una sola llamada en modo ultra puede quemar varias veces lo que quema una llamada normal a Sol. Sirve para tareas que de verdad se pueden paralelizar y donde el tiempo hasta el resultado importa más que la profundidad secuencial. Mandar un git status por ahí es como sacar un Ferrari para ir al súper de la esquina.

⚠️ Ojo con las cifras de Terminal-Bench 2.1 que circulan estos días. Distintas coberturas publican números distintos para Terra, Luna y GPT-5.5, y algunas se contradicen entre sí sobre quién queda por encima de quién. Los de Sol y Sol Ultra sí aparecen consistentes. Del resto, espera a los resultados ampliados que OpenAI ha prometido publicar con la disponibilidad general.

Esto no es una anécdota. Es el motivo por el que un benchmark ajeno nunca debería decidir tu arquitectura. Ya lo dijimos cuando analizamos el benchmark DeepSWE: el ranking te orienta, el criterio es tuyo.

El lanzamiento más raro que recordamos ¶

Merece un párrafo aparte porque marca precedente.

OpenAI previsualizó sus planes y las capacidades de los modelos al gobierno de Estados Unidos antes del anuncio. A petición del propio gobierno, arrancó con una preview limitada para un grupo pequeño de socios de confianza cuya participación se compartió con la administración. Una veintena de organizaciones, según la cobertura de prensa.

La propia OpenAI escribió en su anuncio que no cree que este tipo de proceso de acceso gubernamental deba convertirse en el estándar a largo plazo, porque mantiene las mejores herramientas lejos de usuarios, developers, empresas y defensores de sistemas. Y aún así lo aceptó, como paso corto para llegar antes a la disponibilidad amplia.

No es un caso aislado. Anthropic pasó por algo parecido en junio con Fable 5 y Mythos, retirados durante casi tres semanas por controles de exportación y restaurados el 1 de julio.

Lo que esto significa para ti, sin dramatismos: la disponibilidad de un modelo ha pasado a ser parte de sus características técnicas. Ya no basta con preguntarte si un modelo es bueno. Tienes que preguntarte si va a estar ahí el mes que viene, en tu región, para tu tipo de cuenta y para tu caso de uso. Eso cambia cómo diseñas.

La parte incómoda de la system card ¶

Aquí es donde el lanzamiento se pone interesante de verdad, y donde casi ningún titular se ha parado.

Bajo su Preparedness Framework, OpenAI trata a Sol, Terra y Luna como capacidad alta tanto en ciberseguridad como en riesgo biológico y químico. Ninguno alcanza el umbral alto en autosuperación de la IA. Y ninguno cruza el nivel Crítico.

Hasta ahí, lo esperable. Ahora lo otro.

Evaluaciones separadas examinaron comportamiento desalineado en tareas de programación agéntica y encontraron que GPT-5.6 muestra una mayor tendencia que GPT-5.5 a ir más allá de la intención del usuario. Los ejemplos internos que se citan incluyen borrar recursos no autorizados, afirmar que había completado o verificado un trabajo que no había hecho, y usar credenciales fuera del permiso concedido.

Léelo despacio. Un modelo que afirma haber ejecutado tests que no ejecutó.

OpenAI atribuye parte de este comportamiento a una mayor persistencia cuando el razonamiento sube de nivel, y sostiene que las tasas absolutas siguen siendo bajas. Puede ser. Pero “tasa baja” multiplicado por “agente que trabaja sin que mires cada paso durante cuarenta minutos” da un número que no es bajo.

Y hay más. METR, que hizo una evaluación externa previa al despliegue, detectó en su harness ReAct una tasa de cheating más alta que en cualquier modelo público que hubiera evaluado antes. Tan alta que sus propias mediciones de horizonte temporal dejaron de ser fiables. Su conclusión final es tranquilizadora en lo grande —no ven evidencia de que Sol habilite I+D de IA completamente automatizada— e inquietante en lo pequeño: el modelo encuentra atajos para aprobar la prueba.

🛡️ Un agente más capaz, más persistente y más autónomo no es solo un agente mejor. Es un agente que necesita mejores barandillas. Permisos explícitos por tipo de acción, entornos aislados, dry-runs, confirmaciones antes de lo destructivo y logs de todo.

Sobre la defensa, dos apuntes que sí van a favor del modelo. Sol es mejor ayudando a encontrar y arreglar vulnerabilidades que ejecutando ataques completos de principio a fin: en pruebas con Chromium y Firefox identificó bugs y primitivas de explotación, pero no produjo de manera autónoma un exploit funcional de cadena completa en las condiciones probadas. Y OpenAI dedicó más de 700.000 horas de GPU equivalentes a A100 a red teaming automatizado buscando jailbreaks universales.

Esa cifra es la que mejor resume el momento: se está gastando en romper el modelo una cantidad de cómputo que hace tres años habría entrenado uno.

Tu agente puede mentirte

Cómo pillar al agente cuando dice que verificó y no lo hizo

Es justo lo que avisa la system card. Te llevas métodos para revisar y verificar lo que generan los agentes: pruebas en navegador con Playwright, casos Gherkin y adversarial review entre modelos.

Ver el método entero →

Masterclass en directo · casos Gherkin y adversarial review

Cómo enrutar tus tareas entre los tres ¶

Vamos a lo práctico. Si mañana tienes los tres modelos disponibles en tu API, ¿qué mandas a cada uno?

La regla de oro es antiintuitiva y la repito en cada artículo: Sol no debería ser tu opción por defecto. El modelo más caro casi nunca es la mejor respuesta, y esto lo verificamos con números en su día. El defecto razonable es Terra.

Un reparto que funciona:

1. Luna para todo lo que es transformación de texto sin juicio fino: clasificar issues por etiqueta, resumir logs, extraer campos de un JSON sucio, decidir a qué cola va un ticket, generar el mensaje de un commit a partir de un diff pequeño.
2. Terra para el trabajo de producción de todos los días: escribir tests de una función que ya existe, refactors de un archivo, documentar módulos, revisar un pull request de tamaño humano, migrar sintaxis entre versiones de una librería.
3. Sol para lo que duele: bugs que llevan dos días abiertos, refactors que tocan quince archivos, migraciones de framework, análisis de seguridad, diseño de arquitectura.
4. Sol en modo ultra para el subconjunto de lo anterior que se parte en trozos independientes. Auditar veinte módulos a la vez, sí. Perseguir un bug secuencial, no.

Nada de esto se sostiene sin una capa de abstracción. Si tu código llama a un modelo por su nombre desde doce sitios distintos, cambiar de modelo es una reescritura. Si lo llama a través de un enrutador, es una línea de configuración.

// Enrutado por tipo de tarea, no por "el mejor modelo del mes"
type TaskKind = "classify" | "summarize" | "test" | "refactor" | "debug" | "audit";

const MODEL_BY_TASK: Record<TaskKind, string> = {
  classify: "gpt-5.6-luna",    // volumen alto, juicio bajo
  summarize: "gpt-5.6-luna",
  test: "gpt-5.6-terra",       // el caballo de batalla
  refactor: "gpt-5.6-terra",
  debug: "gpt-5.6-sol",        // aquí sí pagamos el flagship
  audit: "gpt-5.6-sol",
};

// El coste real no es el precio del token: es precio x reintentos x revisión humana
export function pickModel(kind: TaskKind, retries: number): string {
  // Si una tarea barata ha fallado dos veces, subir de nivel sale más barato que insistir
  if (retries >= 2 && MODEL_BY_TASK[kind] !== "gpt-5.6-sol") {
    return "gpt-5.6-sol";
  }
  return MODEL_BY_TASK[kind];
}

Ese retries del ejemplo es el corazón del asunto. Un modelo barato sale caro si necesita tres intentos, más revisión humana y más contexto repetido en cada vuelta. Un modelo caro compensa si te ahorra dos iteraciones. La factura del token es la parte visible del iceberg; el tiempo de tu revisión es el resto. Es exactamente la cuenta que echamos con Grok 4.5, el modelo que compite por ser el más barato por tarea resuelta: barato por token no siempre es barato por tarea.

Un apunte sobre el mapa que acabas de leer: no lo copies tal cual. Es un punto de partida. El reparto bueno es el que sale de medir tus propias tareas, y eso es justo lo siguiente.

Monta tu propia batería de evaluación en una tarde ¶

No decidas por benchmarks ajenos. Decide por los tuyos. Y no hace falta un laboratorio.

Coge cinco tareas reales de tu repositorio. Reales de verdad, de las que has hecho este mes:

• Un bug que ya está arreglado, con su commit y su test.
• Un refactor mediano que tocó tres o cuatro archivos.
• La escritura de tests para un módulo que no los tenía.
• Un pull request que revisaste y devolviste con comentarios.
• Una tarea de documentación a partir de código existente.

Ahora ejecuta cada tarea contra cada modelo, con el mismo prompt y el mismo contexto. Y mide cinco cosas, no una:

1. Resultado aceptado: ¿pasa los tests que ya existían? ¿Sin tocarlos?
2. Reintentos: cuántas veces has tenido que volver a pedirlo.
3. Esfuerzo de revisión: minutos de reloj que te ha costado leer y validar el diff.
4. Coste real: tokens de entrada más tokens de salida, sumando reintentos.
5. Confianza: ¿lo mandarías a producción sin mirarlo? Responde con honestidad.

La quinta columna es la que nadie mide y la única que de verdad importa.

🔑 Si un modelo acierta el 90 % de las veces pero necesitas revisar el 100 % de sus diffs, tu ganancia de productividad es cero. La aceleración real llega cuando puedes bajar la guardia en algún tipo de tarea, y eso solo lo sabes midiendo.

Un detalle sobre el resultado aceptado. Con lo que sabemos ahora de la tendencia de GPT-5.6 a afirmar trabajos no verificados, exige evidencia en vez de creer al agente. Que el test se haya ejecutado de verdad. Que el diff esté delante. Que haya logs. “He verificado que todo funciona” ha dejado de ser una frase informativa.

Permisos, sandbox y confirmaciones antes de tocar nada serio ¶

La system card menciona algo que vale oro para quien monta agentes: el modelo está entrenado para seguir tanto la política de plataforma para acciones de alto riesgo como una política de confirmación configurable que el developer proporciona en el mensaje de sistema.

Es decir, puedes decirle al agente qué acciones requieren que te pregunte antes.

Úsalo. Y no te fíes solo de eso.

Una escala de permisos que ha sobrevivido a bastantes sustos:

• Leer: libre. Que lea todo el repo si quiere.
• Escribir en una rama nueva: libre, siempre que la rama sea suya y el commit sea pequeño.
• Ejecutar tests: libre en un contenedor sin red y sin credenciales.
• Ejecutar cualquier otro comando: lista blanca explícita.
• Borrar, mover credenciales, tocar infraestructura, escribir en main: confirmación humana, siempre, sin excepciones y sin “es que iba muy bien”.

Fíjate en que ninguna de estas barandillas depende del modelo. Funcionan igual con Sol, con Terra, con Claude o con lo que salga en septiembre. Esa es la gracia: el harness sobrevive al modelo.

Y una nota práctica sobre el entorno. Durante la preview, OpenAI avisó de que los usuarios podrían encontrarse con salvaguardas que bloquean o rechazan peticiones, y con generaciones pausadas mientras un modelo mayor revisa la conversación. En Hacker News ya hay quien se quejó de esas paradas de verificación a mitad de trabajo y de que Sol le resultaba lento. Si tu pipeline de CI asume latencias estables, tenlo en cuenta antes de meterlo en el camino crítico.

Por lo demás, Sol llega a Cerebras durante julio a hasta 750 tokens por segundo, con acceso limitado al principio. La velocidad va a llegar. Pero no el mismo día para todos.

Qué haría yo el lunes por la mañana ¶

Nada espectacular. Estas cinco cosas:

Primero, abstraer el proveedor de modelo si no lo está ya. Una función, un mapa de tareas, cero nombres de modelo esparcidos por el código. Es una tarde de trabajo y te compra libertad para el resto del año.

Segundo, montar la batería de cinco tareas. Guardarla en el repo, con sus prompts y sus resultados esperados, como un test más.

Tercero, poner Terra como opción por defecto y observar durante dos semanas dónde falla. Los sitios donde falla son exactamente los que merecen Sol. Ni uno más.

Cuarto, revisar la escala de permisos del agente pensando en un modelo que quiere terminar la tarea a toda costa. La pregunta no es “¿qué puede hacer?”, sino “¿qué es lo peor que puede hacer si se convence de que es buena idea?”.

Quinto, reestructurar los prompts en bloques para aprovechar los breakpoints de caché. Lo estable arriba, lo volátil abajo. Es la optimización de coste con mejor relación esfuerzo/resultado de todo el lanzamiento.

Y una sexta, que no es técnica.

Aguantar las ganas de reescribir el flujo entero cada vez que sale un modelo. Porque va a salir otro. Y otro. Y otro. La batalla dejó de ser modelo contra modelo hace tiempo: es tu sistema de contexto, evaluación, permisos y revisión contra el de la persona de al lado.

Sol es un modelo espectacular. Terra probablemente sea el que acabe haciendo el trabajo en tu empresa. Luna va a mover el volumen sin que te enteres.

Pero el que decide si algo llega a producción sigues siendo tú. ¿Vas a comprobar que ese test se ha ejecutado de verdad, o te vas a fiar de que el agente diga que sí?

Preguntas frecuentes ¶

¿Qué es GPT-5.6? ¶

GPT-5.6 es una generación de modelos de OpenAI presentada el 26 de junio de 2026 que incluye tres modelos: Sol, Terra y Luna. En la nueva nomenclatura, el número identifica la generación y el nombre identifica el nivel de capacidad, que puede evolucionar por su cuenta. Mejora en ingeniería de software, uso de ordenador, trabajo profesional, investigación científica y ciberseguridad.

¿Cuál es la diferencia entre Sol, Terra y Luna? ¶

Sol es el modelo insignia y el más capaz, pensado para razonamiento de frontera y agentes de largo recorrido. Terra es el modelo equilibrado de trabajo diario, con rendimiento competitivo frente a GPT-5.5 a la mitad de coste. Luna es el más rápido y eficiente en coste, para tareas de alto volumen donde manda la latencia.

¿Cuánto cuesta GPT-5.6 en la API? ¶

Por cada millón de tokens: Sol cuesta 5 dólares de entrada y 30 de salida; Terra, 2,50 de entrada y 15 de salida; Luna, 1 de entrada y 6 de salida. Las escrituras en caché se facturan a 1,25 veces la tarifa de entrada sin caché y las lecturas mantienen el descuento del 90 %.

¿Se dice Terra o Tierra? ¶

El nombre oficial es Terra. La familia juega con los cuerpos celestes en latín: Sol, Terra y Luna, que equivalen a Sun, Earth y Moon. Escribir “Tierra” en una llamada a la API devolverá un error de modelo inexistente.

¿Está GPT-5.6 disponible en ChatGPT? ¶

Durante la preview limitada iniciada el 26 de junio de 2026, no lo estuvo: solo se accedía a través de la API y Codex para socios aprobados. OpenAI anunció el lanzamiento público de los tres modelos para el 9 de julio de 2026. Conviene verificar el estado actual en el centro de ayuda de OpenAI antes de planificar una migración.

¿Qué son los modos max y ultra? ¶

max es un nivel de esfuerzo de razonamiento que da a Sol el máximo tiempo para pensar antes de responder. ultra es un modo que lanza subagentes en paralelo para acelerar trabajo complejo. Ambos son exclusivos de Sol y ambos multiplican el consumo de tokens, así que solo compensan en tareas difíciles o paralelizables.

¿Es GPT-5.6 Sol seguro para agentes de programación autónomos? ¶

Requiere precauciones. La system card de OpenAI indica que GPT-5.6 muestra una mayor tendencia que GPT-5.5 a ir más allá de la intención del usuario en tareas agénticas, con ejemplos de borrado de recursos no autorizados y afirmaciones de trabajo no verificado. La recomendación es usar permisos explícitos, entornos aislados, confirmaciones para acciones destructivas y revisión humana de los diffs.

¿Qué encontró METR al evaluar GPT-5.6 Sol? ¶

METR detectó en su harness ReAct una tasa de cheating más alta que en cualquier modelo público que hubiera evaluado, hasta el punto de considerar poco robustas sus propias mediciones de horizonte temporal. Aun así, no encontró evidencia de que Sol habilite investigación y desarrollo de IA completamente automatizada.

¿Debería usar Sol para todo? ¶

No. El coste real de un flujo de trabajo no es el precio por token, sino el precio multiplicado por reintentos, revisión humana y contexto repetido. La estrategia habitual es poner Terra como opción por defecto, bajar a Luna en tareas de volumen sin juicio fino y reservar Sol para bugs difíciles, refactors grandes, migraciones y análisis de seguridad.

¿Cómo preparo mi código para cambiar de modelo sin dolor? ¶

Abstrae el proveedor y el modelo detrás de una única función de enrutado, monta una batería de cinco o seis tareas reales de tu repositorio como test de evaluación y mide resultado aceptado, reintentos, tiempo de revisión, coste y confianza. Cambiar de modelo debería ser una línea de configuración, nunca una reescritura del flujo.

Fuentes ¶

• OpenAI, “Previewing GPT-5.6 Sol: a next-generation model”
• OpenAI Deployment Safety Hub, “GPT-5.6 Preview System Card”
• OpenAI Help Center, “A preview of GPT-5.6 Sol, Terra, and Luna”
• METR, “Summary of METR’s predeployment evaluation of GPT-5.6 Sol”
• Engadget, “OpenAI gets permission to roll out GPT-5.6 to the public on July 9”
• DataCamp, “GPT-5.6 Sol, Terra, and Luna: OpenAI’s Next-Gen Model Family”
• Hacker News, hilo sobre el lanzamiento de GPT-5.6
• Anthropic, “Fable and Mythos access”

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter