GPT-6 Astra, Sol o Luna: cómo elegir por tarea y coste total

Puede que ya sepas que Luna es el más barato y Astra el más capaz, pero eso no responde a la pregunta importante: ¿esta tarea justifica pagar 20× o 100× más por los tokens? Usa esta regla inicial: Luna para trabajo frecuente y verificable, Sol para programación compleja y flujos con agentes, y Astra para tareas integrales ambiguas o con errores costosos. Al terminar, sabrás con qué modelo empezar, qué señales justifican escalar y cómo comparar la misma carga de tokens entre OpenAI Standard y BetterToken.

Empieza aquí: Luna para volumen verificable, Sol para desarrollo complejo, Astra para errores costosos

Elige el punto de partida según los límites de la tarea y el coste del error; después corrige la ruta con tus propios datos de aceptación.

Modelo	Posicionamiento de OpenAI	Buenos candidatos iniciales	Cuándo escalar
gpt-6-luna	Modelo eficiente para tareas enfocadas y de gran volumen	Cambios pequeños y acotados, extracción estructurada, clasificación, conversión de formatos, generación de pruebas a partir de una especificación clara y lotes con validación determinista	La validación falla repetidamente; hace falta razonar entre archivos; crece la cadena de herramientas; queda una ambigüedad crítica
gpt-6-sol	Diseñado para programación compleja y flujos con agentes	Funcionalidades en varios archivos, depuración, revisión de código, tareas de repositorio con varias llamadas a herramientas e investigación o documentación de complejidad media con límites claros	Un plan incorrecto tendría gran impacto; varios intentos omiten restricciones esenciales; se necesitan compromisos entre sistemas o investigación difícil
gpt-6-astra	El modelo más capaz de OpenAI para el trabajo integral más exigente	Decisiones de arquitectura, migraciones complejas, análisis de incidentes entre sistemas, cambios de código de alto riesgo y procesos largos con investigación, creación de documentos o computer use	Astra ya es el nivel superior de esta familia; si aun así falla, hay que acotar la tarea, aportar evidencia o introducir una decisión humana, no seguir escalando por nombre

El objetivo no es afirmar que Luna deba resolver siempre todo lo que parezca “fácil”. Se trata de encontrar el modelo de menor coste que supere de forma estable el umbral de calidad requerido. Un modelo barato que obliga a repetir muchas veces puede terminar costando más. Del mismo modo, comenzar cada tarea bien especificada con Astra puede significar pagar por una capacidad que el flujo nunca utiliza.

La documentación pública aún no ofrece una comparación independiente de Astra, Sol y Luna sobre las mismas tareas reales. Usa esta matriz como punto de partida y registra aceptación al primer intento, reintentos, tiempo real hasta un resultado aceptado y coste total por tarea aceptada.

Un contexto parecido no vuelve intercambiables a los modelos

Los tres modelos tienen capacidades de contexto y herramientas parecidas, por lo que la forma de la tarea, la configuración de razonamiento y el coste del error importan más que el tamaño de la ventana. OpenAI sitúa Astra en razonamiento complejo, código, computer use, investigación y documentos; Sol en programación compleja y flujos con agentes; y Luna en trabajo enfocado y de gran volumen. Ese posicionamiento sirve para elegir el primer candidato, pero tus resultados deben decidir el modelo predeterminado.

Los tres modelos ofrecen una ventana de contexto de 1.050.000 Token, un máximo de entrada de 922.000 Token y un máximo de salida de 128.000 Token. Por tanto, la capacidad de contexto por sí sola no los distingue. En la práctica importan más estos puntos:

• Astra admite reasoning.effort con low, medium, high, xhigh y max.
• Sol y Luna también admiten none, y el valor predeterminado es medium. En tareas muy acotadas, probar primero un nivel de razonamiento inferior ayuda a separar el coste del modelo del coste de un reasoning innecesario.
• Para flujos con agentes y muchas herramientas, conviene priorizar Responses API. Con Sol y Luna, function calling en Chat Completions exige reasoning_effort igual a none.
• La elección del modelo, el contexto, el razonamiento, las herramientas, la recuperación y la caché afectan al consumo. La longitud del Prompt no basta para estimar el coste de la tarea.

Una comparación justa mantiene constantes la interfaz, el contexto, las herramientas, el reasoning effort, la salida máxima y los criterios de aceptación. Si cambian varias variables a la vez, la diferencia observada puede proceder de la configuración y no del modelo.

Con los mismos tokens, compara BetterToken solo con OpenAI Standard

Con el mismo uso de tokens, las tarifas de BetterToken verificadas el 2026-09-24 eran el 68% de las tarifas equivalentes de OpenAI Standard. Eso no lo convierte en la ruta más barata en todos los casos: OpenAI Batch y Flex son inferiores, y los reintentos, las herramientas y el retrabajo humano determinan el coste completo. La tabla usa USD por un millón de Token y muestra el nivel de contexto de entrada de hasta 272K.

Model ID	Fuente	Entrada	Lectura de caché	Escritura de caché	Salida
gpt-6-astra	OpenAI Standard	$10.00	$1.00	$12.50	$50.00
gpt-6-astra	BetterToken	$6.80	$0.68	$8.50	$34.00
gpt-6-sol	OpenAI Standard	$2.00	$0.20	$2.50	$10.00
gpt-6-sol	BetterToken	$1.36	$0.136	$1.70	$6.80
gpt-6-luna	OpenAI Standard	$0.10	$0.01	$0.125	$0.50
gpt-6-luna	BetterToken	$0.068	$0.0068	$0.085	$0.34

Cuando una petición supera 272K de contexto de entrada, los tres GPT-6 pasan al tramo de contexto largo en ambos servicios: las tarifas de entrada, lectura de caché y escritura de caché son 2 veces las de la tabla, y la salida es 1,5 veces mayor; el tramo superior se aplica a toda la petición. Por ejemplo, gpt-6-sol con contexto largo cuesta $4.00/$0.40/$5.00/$15.00 en OpenAI Standard y $2.72/$0.272/$3.40/$10.20 en BetterToken para entrada/lectura de caché/escritura de caché/salida.

Los precios son dinámicos. Antes de desplegar, conviene consultar los precios actuales y verificar de nuevo la disponibilidad del modelo, la moneda y el tramo aplicable. OpenAI Batch y Flex cuestan actualmente el 50% de Standard y están por debajo de las tarifas de BetterToken de esta instantánea; si la carga admite procesamiento asíncrono o de menor prioridad, no deben mezclarse con OpenAI Standard en la misma comparación. Tampoco se incluyen recargos regionales, llamadas a herramientas, contenedores ni reintentos.

El grupo GPT de BetterToken puede utilizarse mediante API, Codex y herramientas externas que admitan un Base URL personalizado. BetterToken no es un producto de OpenAI y su consumo de API no equivale a los mensajes, la capacidad incluida o los credits de una suscripción de ChatGPT o Codex.

¿Ya usas GPT-5.5? Conserva la referencia antes de cambiar

Si tu flujo con GPT-5.5 es estable, no cambies solo porque apareció una familia nueva. Conserva la referencia de calidad, tiempo y coste, y reproduce las mismas tareas en Sol, Luna y Astra. Los precios siguientes son USD por un millón de Token, verificados el 2026-09-24.

Model ID	Fuente	Contexto	Entrada	Lectura de caché	Salida
gpt-5.5	OpenAI Standard	≤ 272K	$5.00	$0.50	$30.00
gpt-5.5	OpenAI Standard	> 272K	$10.00	$1.00	$45.00
gpt-5.5	BetterToken	Sin tramos	$3.40	$0.34	$20.40

BetterToken no aplica un tramo separado de contexto largo a gpt-5.5; OpenAI Standard sí lo hace por encima de 272K. No se incluye el precio de escritura en caché porque la fila pública de precios de GPT-5.5 de OpenAI no proporciona ese valor; se deja vacío en lugar de estimarlo.

También hay que separar dos preguntas de migración. OpenAI indica que GPT-5.5 se retirará de ChatGPT, ChatGPT Work y Codex en todos los planes el 2026-10-14, mientras que la API de OpenAI no se verá afectada. Los usuarios de planes de Codex necesitan una ruta alternativa antes de esa fecha. Las cargas que usan API Key no tienen que migrar únicamente por esa retirada en los planes. Los límites del plan de Codex, los credits adicionales y el uso de API facturado en USD son sistemas contables distintos.

La métrica útil es el coste por tarea aceptada

El precio de una llamada no revela qué modelo termina el trabajo por menos. Suma intentos fallidos, reintentos, escrituras de caché, herramientas y retrabajo humano, y divide el total entre los resultados aceptados. El ejemplo siguiente aísla primero las dos vías de facturación con la misma mezcla de tokens.

Supongamos que una ejecución aceptada utiliza:

• 120.000 Token de entrada sin caché;
• 100.000 Token de entrada leídos de caché;
• 10.000 Token de salida;
• ninguna escritura nueva de caché en esta ejecución;
• 220K de contexto total de entrada, por lo que se aplica el tramo corto.

Con la fórmula “Token ÷ 1.000.000 × tarifa correspondiente”, el cargo del modelo por esa ejecución es:

Model ID	OpenAI Standard	BetterToken
gpt-6-luna	$0.01800	$0.01224
gpt-6-sol	$0.36000	$0.24480
gpt-6-astra	$1.80000	$1.22400
gpt-5.5	$0.95000	$0.64600

El ejemplo compara la facturación del mismo conjunto de Token; no compara calidad, velocidad ni valor final. Con los mismos Token y el mismo modo de procesamiento, Sol cuesta 20 veces Luna y Astra cuesta 5 veces Sol. Sin embargo, intentos fallidos, salidas más largas, más herramientas o trabajo humano pueden reducir o invertir la diferencia del coste total.

Una fórmula más útil es:

Coste de finalización = cargos de Token de todos los intentos + escritura de caché + herramientas + reintentos fallidos y retrabajo.

Al dividirlo por el número de tareas aceptadas se obtiene el coste por resultado aceptado. Esa métrica se acerca mucho más a una decisión de producción que el precio de una sola petición exitosa.

Elige el primer modelo por escenario y define cuándo escalar

La ruta inicial puede ser concreta: trabajo de bajo riesgo con verificación automática en Luna, desarrollo complejo en Sol y tareas de alto riesgo o mucha ambigüedad en Astra.

Trabajo verificable y de gran volumen: empieza con Luna

Si un schema, linter, unit test u otra regla determinista detecta el fallo con rapidez, prueba Luna primero. Son buenos candidatos las conversiones de formato fijo, la extracción de campos conocidos, los renombrados locales, los tests derivados de una especificación precisa y otros resultados masivos con aceptación automática fiable.

Hay que escalar a Sol cuando falle la validación, aparezca una dependencia no declarada o sea necesaria una decisión entre módulos. No conviene permitir reintentos ilimitados de un modelo pequeño en la misma dirección equivocada.

Programación multiarchivo y flujos con agentes: empieza con Sol

Cuando la tarea debe comprender varios archivos, usar herramientas en secuencia o cambiar el plan después de ejecutar, empieza con Sol. Algunos ejemplos son implementar una función entre archivos, diagnosticar fallos de tests, buscar en el repositorio antes de editar y continuar a partir de resultados de herramientas.

La tarea debe seguir acotada. Condiciones como “analiza, modifica, ejecuta las pruebas más relevantes y comunica lo que queda sin resolver” suelen ser más útiles que aumentar reasoning.effort sin un plan. Astra entra cuando Sol omite repetidamente restricciones de arquitectura en tareas representativas.

Trabajo integral ambiguo o de alto riesgo: empieza con Astra

Empieza con Astra cuando el coste de una respuesta incorrecta sea claramente mayor que la prima del modelo. Las migraciones entre sistemas, los incidentes difíciles de producción, los límites críticos de seguridad, las decisiones intensivas en investigación y los flujos que combinan código, computer use y una larga cadena de herramientas entran aquí.

Astra también necesita validación. Conviene dividir el trabajo en puntos de control para el plan, la evidencia, los cambios y la verificación, evitando que el modelo más potente dedique más tiempo a una premisa incorrecta.

¿Todavía dudas? Compara los modelos con las mismas tareas reales

No necesitas fijar un número universal de ejemplos. Sí necesitas un conjunto representativo con casos normales, límite y de fallo, y las mismas reglas de aceptación para cada modelo.

1. Elige un conjunto representativo. Incluye cambios pequeños, desarrollo multiarchivo, depuración, herramientas y trabajo de conocimiento, no solo demos pulidas.
2. Define la aceptación antes de ejecutar. Usa tests, lint, schemas, una lista de hechos o revisión humana. Cambiar la rúbrica después de ver una respuesta vuelve poco fiable la comparación.
3. Mantén constantes las demás variables. Usa el mismo contexto, herramientas, API, esfuerzo de razonamiento, salida máxima y entorno. Trata otro reasoning.effort como un experimento separado.
4. Registra cada intento. Guarda aceptación al primer intento, reintentos, tiempo real hasta un resultado aceptado, Token de entrada/caché/salida, llamadas a herramientas y gasto final.
5. Calcula el coste por resultado aceptado. Incluye intentos fallidos y retrabajo humano, no solo la última ejecución correcta.
6. Concluye por clase de tarea. Un modelo puede superar cambios de código y fallar en investigación o agentes largos. No ocultes esa diferencia con un único valor predeterminado.
7. Revisa la ruta cuando cada clase haya acumulado varias ejecuciones reales. Si un nivel superior no mejora de forma repetible la aceptación o el coste total, vuelve al modelo menor o conserva el flujo existente con GPT-5.5 API.

Compara como mínimo la aceptación al primer intento, la aceptación final, el coste total por resultado aceptado y la mediana más un percentil alto del tiempo. Un modelo solo debe ser predeterminado cuando gana de forma sostenida con tu umbral real de calidad.

Escala por fallos repetidos y riesgo, no por prestigio del modelo

El escalado debe activarse por señales observables de fallo, no por suponer que un modelo más caro será mejor por definición.

• Luna → Sol: la validación determinista falla de forma repetida; la tarea exige razonamiento entre archivos o módulos; los resultados de herramientas cambian materialmente el plan; o persiste una ambigüedad crítica después de aclarar las condiciones.
• Sol → Astra: los planes repetidos omiten restricciones clave; un error afecta producción, seguridad o una migración importante; o la tarea combina razonamiento difícil, investigación, documentación y ejecución.
• Astra → acotar la tarea: si Astra tampoco supera la aceptación, añade evidencia, divide el flujo o pide una decisión humana en lugar de aumentar sin límite el contexto y el razonamiento.
• Modelo nuevo → volver a GPT-5.5: en flujos de API, conserva GPT-5.5 mientras cumpla los requisitos de calidad, latencia y mantenimiento. Un nombre más nuevo no basta para migrar.

Usa Luna → Sol → Astra como cadena inicial: verificador fiable significa Luna, desarrollo complejo significa Sol y riesgo alto significa Astra. Cambia la regla solo cuando tus datos de aceptación, reintentos, tiempo y coste por resultado aceptado demuestren que otra ruta es mejor.