GPT-6 Sol y Luna: precios, prompt caching y cómo recalcular el costo de tus agentes

Por Felipe Traina · 28/9/2026 · 7 min · ia, llm, costos, openai

El 22 de septiembre de 2026 OpenAI lanzó GPT-6 Sol y GPT-6 Luna con precios de API 50% más bajos que los promocionales de sus antecesores de la serie GPT-5.6: Sol pasa de USD 4 a 2 por millón de tokens de entrada y de 20 a 10 de salida; Luna, de 0,20 a 0,10 de entrada y de 1,20 a 0,50 de salida. Junto con los modelos llegó un sistema de prompt caching renovado que, para agentes de larga duración, puede mover la factura tanto como el cambio de modelo.

Si tenés features con LLM en producción, este es un buen momento para rehacer las cuentas. Pero conviene hacerlas con la documentación oficial a mano, porque hay reglas de precio que cambian bastante el resultado.

Qué salió exactamente

Según el anuncio y la documentación de la API:

Modelo Entrada (USD/M) Entrada cacheada Salida (USD/M) Pensado para
gpt-6-sol 2,00 0,20 10,00 Coding complejo y flujos agénticos
gpt-6-luna 0,10 0,01 0,50 Tareas acotadas y de alto volumen
gpt-6-astra (referencia) 10,00 1,00 50,00 El modelo tope de la familia

Otros datos de la ficha de Sol que importan para arquitectura:

Los benchmarks, con la advertencia de siempre

OpenAI publica comparaciones agresivas. En DeepSWE v1.1, Sol con esfuerzo max llega a 68,8%, a 1,1 puntos del mejor resultado de Claude Fable 5 (69,9% en xhigh), con un costo por tarea aproximadamente 80% menor. En OSWorld 2.0 offline, Sol en xhigh saca 60,5% contra 60,3% de Claude Opus 5 en medium.

Son números del propio vendor, y OpenAI aclara que los datos de competidores salen de reportes públicos (y que usó Fable 5 cuando no había resultados de Fable 5.1). Sirven como señal para decidir qué probar, no para decidir qué usar. Esa decisión se toma con tus propias evals.

El caching nuevo: la parte que más mueve la factura

OpenAI detalló los cambios en un post aparte:

{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

GitHub, citado en el anuncio, dice que estas mejoras redujeron más de 50% la porción de tokens de prompt que Copilot necesita procesar desde cero.

Hagamos números (ejemplo ilustrativo)

Supongamos un agente que consume 10 millones de tokens de entrada y 2 millones de salida por día. Con precios de lista:

Escenario Cálculo Costo diario
GPT-5.6 Sol (precio promocional) 10 × 4 + 2 × 20 USD 80
GPT-6 Sol sin caché 10 × 2 + 2 × 10 USD 40
GPT-6 Sol, 80% de la entrada cacheada 8 × 0,20 + 2 × 2,50 + 2 × 10 USD 26,60
GPT-6 Luna sin caché 10 × 0,10 + 2 × 0,50 USD 2

En el escenario con caché asumimos el caso conservador: los 2 millones de tokens de entrada no cacheados se cobran como escritura de caché (USD 2,50, es decir 1,25 veces el precio de entrada). Aun así, la salida (USD 20) pasa a ser el costo dominante. Con estos precios, diseñar prompts que aprovechen la caché y controlar la longitud de las respuestas vale tanto como elegir el modelo.

La letra chica: el umbral de 272K tokens

La documentación de Sol y Luna dice que, si un request supera los 272.000 tokens de entrada, todo el request se cobra al doble en entrada y caché, y a 1,5 veces en salida.

Un request de 300.000 tokens de entrada y 10.000 de salida en Sol cuesta:

Tener un millón de tokens de contexto disponible no significa que convenga usarlo. Otros multiplicadores a tener en cuenta: Batch y Flex cuestan la mitad del precio estándar, Fast mode cuesta el doble y el procesamiento regional (residencia de datos) suma 10%.

Qué cambiar en tu arquitectura

  1. Routing por tarea. Luna para clasificar, extraer y resumir; Sol para agentes y código; Astra solo donde tus evals muestren que la diferencia se paga.
  2. Prefijo estable. System prompt y definiciones de herramientas primero, siempre en el mismo orden. Lo variable va al final, en modo append-only.
  3. Presupuesto de contexto por debajo de 272K, con compactación o chunking.
  4. Métrica de costo por tarea resuelta, no por token. Un modelo más barato que necesita tres intentos puede salir más caro.
  5. Una capa de abstracción entre tu aplicación y el proveedor, para que cambiar de modelo sea configuración y no un refactor.

Un chequeo simple para detectar requests que se acercan al umbral, usando el campo usage que devuelve la API:

UMBRAL = 272_000

def revisar_uso(response):
    entrada = response.usage.input_tokens
    if entrada > UMBRAL * 0.9:
        # Registrar y alertar: este request está cerca del recargo (o ya lo pagó)
        print(f"[alerta-costo] input_tokens={entrada}")

Qué hacer con esto

¿Ya medís el costo por tarea resuelta o seguís mirando el precio por millón de tokens?

Lecturas relacionadas

Fuentes

← Volver al blog