El 30 de julio OpenAI bajó los precios de su API. GPT‑5.6 Luna quedó en $0.20 por millón de input tokens y $1.20 por millón de output — una baja del 80%. Terra quedó en $2 y $12 — una baja del 20%. Sol, el tier de arriba, se quedó exactamente donde estaba.
La mayoría de la cobertura se detuvo en el primer número. Yo creo que el interesante es el tercero.
Un descuento no te dice nada. Un descuento asimétrico te dice mucho.
Cuando un proveedor recorta parejo en toda la línea, estás mirando una movida defensiva: alguien le está sacando share y la respuesta es margen. Cuando un proveedor recorta 80% abajo, 20% en el medio y 0% arriba, estás mirando tres mercados distintos que casualmente comparten una marca.
Abajo, el producto son tokens. Luna compite por precio por unidad de output suficientemente bueno, y el piso de esa competencia es lo que sea que el operador más barato pueda sobrevivir. Un recorte del 80% es lo que cuesta seguir en la lista.
En el medio, el producto es un tradeoff. Terra es donde caes cuando Luna no alcanza y Sol no se justifica. Un recorte del 20% mueve esa línea — hace más barato ganar el argumento de “usa el modelo más grande y listo”, y eso vale más para OpenAI que el margen que resignó.
Arriba, el producto no son tokens. Es la capacidad que no consigues en otro lado. Sol no se movió porque nada le está apretando, y OpenAI te lo está diciendo justamente al dejar el número quieto. Si estás pagando Sol, no estás en una negociación de precio.
Ese es el mapa. Antes de leerlo como una noticia sobre OpenAI, mira dónde caen tus propios workloads en él — porque el tier en el que estás parado determina si esta noticia es un golpe de suerte o un error de redondeo.
De dónde salió el margen — y por qué esa es la parte con vida útil
Los recortes de precio suelen salir de algún lugar que nadie explicita. Este vino con explicación, publicada el día anterior, y la explicación es más duradera que los precios.
Según OpenAI, apuntaron GPT‑5.6 Sol a su propio inference stack. Dos resultados:
Kernels de producción. Sol reescribió y optimizó los kernels que ejecutan las operaciones matemáticas del modelo — escritos en Triton y Gluon, los lenguajes de programación de GPU que OpenAI mantiene como open source. El efecto declarado es una reducción del 20% en el costo end-to-end de serving. OpenAI también dice que se apoya en FpSan, un floating-point sanitizer open source, para validar la corrección de los kernels que escribe el modelo.
Speculative decoding. Sol rediseñó su propio draft model — el modelo chico que propone tokens que el grande verifica — corriendo cientos de experimentos sobre tamaño, estructura y features, y después lanzando y monitoreando el entrenamiento del speculator, interviniendo ante fallas de hardware e inestabilidad del training. Efecto declarado: más de 15% de mejora en eficiencia de generación de tokens.
Lee esas dos cosas juntas y el anuncio de precios se convierte en una nota al pie de otra historia. Esta es una empresa diciendo que su modelo mejoró su propia economía de serving lo suficiente como para financiar un recorte de precios del 80%, y mostrando cuáles fueron las dos palancas que movió.
Los caveats honestos: todas las cifras son self-reported. OpenAI no revela el modelo de GPU, la configuración baseline, los acceptance rates del speculator, ni nada del setup experimental. El único número de tercero en el anuncio es el Artificial Analysis Coding Agent Index, que mide capacidad, no costo de serving. Nadie fuera de OpenAI verificó ni el 20% ni el 15%.
Pero no necesitas verificar los porcentajes para tomarte el mecanismo en serio — y las dos palancas son cosas que puedes inspeccionar. Triton, Gluon y FpSan son públicos. Lo que OpenAI aplicó a escala frontier es la misma técnica disponible para cualquiera que sirva modelos: kernels afinados a tu workload real en vez del caso general, y un draft model con la forma de tu tráfico real en vez del que vino con el framework. La escala es de ellos. La técnica no.
Fast mode: la latencia pasa a ser una línea aparte
El tercer cambio fue el que menos atención recibió y puede ser el que te toque la arquitectura.
Fast mode reemplaza a Priority Processing en la API: hasta 2.5× más rápido que Standard al doble de precio, sin cambio en inteligencia. Los requests existentes con tag de priority siguen funcionando.
Fíjate en qué se está vendiendo ahí. No un modelo mejor — el mismo modelo, antes. Eso es un eje de precio que separa latencia de capacidad, y vuelve explícita una pregunta que hoy la mayoría de los equipos responde por accidente: ¿cuáles de tus llamadas son realmente sensibles a latencia?
Si venías yendo a un modelo más grande para que una interacción se sintiera responsiva, estabas pagando capacidad para comprar velocidad. Fast mode le pone precio honesto a eso. En muchos stacks la respuesta correcta ahora es un modelo más chico en Fast mode antes que uno más grande en Standard — y la única forma de saberlo es mirar tu propio p95, endpoint por endpoint, en vez de suponerlo.
Qué haría yo esta semana
Tres cosas, en orden:
- Rehacer las cuentas del routing. Cualquier lugar donde descartaste Luna por calidad y te quedaste en Terra merece una segunda mirada — la brecha de costo entre las dos cambió por un factor que invalida cualquier planilla que haya justificado esa decisión.
- Separar tus llamadas sensibles a latencia de las sensibles a capacidad. No son el mismo conjunto, y hasta que existió Fast mode no había motivo para tener la lista.
- No construyas sobre el precio. Construye sobre el tier. El número que se movió 80% se va a volver a mover; la estructura — piso commodity, medio disputado, techo sin disputa — es lo que realmente estás diseñando alrededor.
Luna a $0.20 es el titular. Sol sin cambios es el mercado diciéndote dónde está el leverage, y no está abajo.
¿Ya rehiciste el routing de modelos después de este recorte, o sigues con los números de antes? Tengo curiosidad por saber en qué tier terminaron cayendo tus workloads.
https://openai.com/index/advancing-the-price-performance-frontier-with-gpt-5-6/