La Decisions API de OpenAI ya es general: cuándo compensa un modelo de decisión dedicado
Si tu aplicación llama a un modelo de chat completo cada vez que tiene que resolver un sí/no, elegir una rama o puntuar la relevancia de un fragmento, estás pagando un generador de texto para que haga de clasificador. El 22 de octubre OpenAI abrió a todos los desarrolladores su Decisions API, un endpoint pensado justo para eso: respuestas acotadas, mucho más rápidas y baratas. La pregunta no es si funciona, sino para qué trozos de tu producto tiene sentido y para cuáles no.
Qué ha pasado
OpenAI presentó la Decisions API en su DevDay del 29 de septiembre, la pasó a beta pública el 6 de octubre y el 22 de octubre de 2026 la puso a disposición de todos los clientes. En lugar de texto libre, el endpoint devuelve una respuesta tipada: una probabilidad, una opción dentro de un conjunto cerrado, o una puntuación según una rúbrica. Admite texto e imagen.
Lo mueve gpt-6-luna, que no es un modelo diseñado desde cero para clasificar, sino ChatGPT Luna reconfigurado para abaratar y acelerar la inferencia. El cambio que se nota es la latencia: OpenAI habla de pasar de uno a tres segundos a entre 100 y 180 milisegundos. El precio anunciado es de 0,10 $ por millón de tokens de entrada, con la salida gratis; las condiciones de caché han cambiado entre la beta y la versión general, así que confirma la tabla de precios vigente antes de echar cuentas.
La categoría no la inventa OpenAI. La abrió TypeSafe con Jev, el "superclasificador" que devuelve una elección y su nivel de confianza, y que de momento aguanta por delante en varios índices: en el Artificial Analysis Decision Index, Jev va tercero y el modelo de OpenAI, decimocuarto. Jev 1.14 añadió imágenes la semana pasada. Clientes como Box, Datadog, Ramp o Speak ya usaban estos modelos para quitar carga a los LLM; Speak dice que bajó el tiempo entre acciones de 1,4 segundos a 0,13.
Qué implica para tu producto
El encaje natural es el trabajo de alto volumen, respuesta corta y métrica de acierto clara: moderación de contenido, triaje de tickets, enrutado de peticiones hacia distintos modelos, scoring de relevancia en un RAG, priorización de colas, evals corriendo en producción. En el camino crítico, resolver eso con un modelo de chat completo es latencia y coste que no estás obligado a pagar.
Hay tres sitios donde nosotros no lo meteríamos.
El primero es el volumen bajo. Si haces unos pocos miles de clasificaciones al día, un modelo general con salida estructurada (JSON schema o function calling) ya te resuelve el problema sin sumar otro proveedor al stack ni otro sitio donde algo se puede romper.
El segundo es la decisión que necesita razonamiento largo o contexto amplio. Un modelo optimizado para responder en 120 milisegundos no es el lugar para una llamada que requiere leerse medio expediente antes de contestar.
El tercero es no tener evals. Sin un conjunto de casos etiquetados y una métrica, migrar al modelo barato es cambiar una factura por errores que no vas a ver. El clasificador caro y el barato pueden coincidir el 95 % de las veces; ese 5 % restante es justo del que te enteras en producción, tarde.
Queda el lock-in. La Decisions API solo corre sobre gpt-6-luna: atas tu capa de decisión a un proveedor y a un modelo concretos, en un hueco donde Jev, Liquid D1 o Elephant-1 se intercambian el ranking cada pocas semanas.
Nuestra recomendación
Para quien está clasificando, enrutando o puntuando a gran escala y mide la latencia en milisegundos, un endpoint de decisión dedicado vale lo que cuesta, y la Decisions API entra en esa conversación. Para quien aún llama a un modelo grande cuatro veces al minuto, el ahorro es teórico y el coste de operación, real.
Si decides moverte, no llames a /v1/decisions desde media aplicación. Nosotros ponemos la decisión detrás de una interfaz propia, un gateway, de forma que el proveedor sea un detalle de implementación y no una dependencia repartida por todo el código. El día que Jev, Liquid o el que venga después te convenga más, cambias una pieza y no veinte. Y antes de migrar nada, pásalo por tus evals con tu propio tráfico: el benchmark que importa es el tuyo, no el del índice.
Si estás en ese punto (decidiendo qué parte de tu stack de IA mantener en un LLM general y qué parte mover a un modelo especializado) es justo el tipo de decisión de arquitectura que ayudamos a tomar sin perseguir cada release. Te leemos el caso y te decimos qué moveríamos y qué no.
