OpenAI libera la Decisions API para todos: respuestas tipadas de gpt-6-luna, sin cobrar tokens de salida

OpenAI sacó de beta pública su Decisions API el 22 de octubre, según el changelog de su API. El endpoint había salido en beta el 6 de octubre y está pensado para un trabajo acotado: tomar texto, imágenes o datos estructurados, hacerle al modelo un lote de preguntas sobre eso y recibir respuestas tipadas en vez de prosa. Corre sobre un único modelo, gpt-6-luna.

Ese mismo día OpenAI publicó en su feed de noticias un post titulado "Build more responsive apps with the Decisions API", que presenta el producto como decisiones "rápidas, enfocadas y de bajo costo para cualquier aplicación". No pudimos abrir esa página desde nuestro entorno; esta nota se basa en la documentación para desarrolladores de OpenAI.

Qué hace el endpoint

Un request a POST /v1/decisions lleva un input y una lista de preguntas. Según la guía de Decisions, cada pregunta es de uno de tres tipos:

• predicate: devuelve una probabilidad entre 0 y 1 de que una condición se cumpla (por ejemplo, "¿este mensaje reporta un cobro duplicado?").
• choice: devuelve uno de los valores que vos definís, más una probabilidad para cada opción y un nivel de confianza. Sirve para derivar un ticket al área correcta.
• score: devuelve una posición ponderada por probabilidad sobre una escala de niveles que definís vos, así que el resultado puede caer entre dos niveles. Sirve para calificar severidad o prioridad.

Cualquier respuesta puede volver como un rechazo (refusal). El input puede ser texto plano o una lista ordenada de mensajes, llamadas a herramientas y sus resultados, así que el endpoint puede evaluar la transcripción de un agente además de un mensaje suelto.

Qué cambia con la disponibilidad general

• 400 preguntas por request, contra 200 durante la beta.
• input_json: los datos estructurados se pueden pasar como un objeto JSON dentro de un mensaje de usuario, sin convertirlos a string. Las claves que contiene se tratan como datos, no como campos del mensaje.
• Imágenes en las instrucciones de cada pregunta, para que cada una tenga su propia imagen de referencia.
• Prompt caching sobre el input compartido, activado por defecto, con un punto de corte implícito al final del input compartido. El prefijo reutilizable necesita al menos 1.024 tokens, y el texto de las preguntas no cuenta para ese mínimo.

La documentación también menciona Zero Data Retention y uso compatible con HIPAA para clientes que califiquen, y procesamiento regional en Estados Unidos y Europa. No admite archivos, audio, imágenes por file_id ni referencias a ítems.

Precios

El input sin caché cuesta US$0,10 por millón de tokens, y la guía aclara que los tokens de salida no se cobran. Las lecturas y escrituras de caché siguen las tarifas estándar de gpt-6-luna, que la página de precios fija en US$0,01 por millón de tokens de input cacheado y US$0,125 por millón para una escritura de caché de 30 minutos (US$0,25 en la opción de 12 horas). Como referencia, el mismo modelo usado a través de la Responses API cobra la salida a US$0,50 por millón de tokens. Pueden aplicarse recargos por procesamiento regional y multiplicadores por contexto largo.

Como una decisión devuelve un número o una etiqueta y no texto, no cobrar la salida pesa menos por llamada de lo que parece. El ahorro de fondo es estructural: dejás de pagar para que el modelo escriba un objeto JSON, o un razonamiento, que después tu código parsea para quedarse con un solo valor.

El dato de velocidad

OpenAI dice que el endpoint responde "unas 10 veces más rápido que la Responses API". La documentación no da cifras de latencia, ni condiciones de prueba, ni límites de rate, y no encontramos ningún benchmark independiente. Tomá el 10x como un dato del proveedor hasta que alguien lo mida con cargas reales.

Qué significa para quienes desarrollan

Buena parte del tráfico de LLM en producción no es generación: chequeos de moderación, ruteo por intención, triage, filtros de "¿esta salida es aceptable?" dentro de loops de agentes. Lo habitual es pedirle a un modelo general que emita una etiqueta, forzar un esquema con structured outputs y después parsear. Decisions convierte ese patrón en una primitiva dedicada, y las probabilidades que devuelve te dan algo que una etiqueta parseada no: un umbral que podés ajustar.

Eso cambia cómo se escriben estos prompts. En lugar de un prompt largo que pide un objeto JSON con una docena de campos, escribís instrucciones cortas y de un solo propósito para cada pregunta, y dejás que el input compartido quede en caché entre ellas. Agrupar hasta 400 preguntas sobre el mismo contexto cacheado es donde el argumento de costo y latencia es más fuerte.

La guía es clara sobre los límites. Si necesitás que el modelo genere un objeto que respete tu propio esquema JSON, te manda a Structured Outputs en la Responses API; si el modelo tiene que llamar a una herramienta con argumentos, corresponde function calling. Las preguntas de un mismo request se responden de forma independiente, así que una decisión que depende de una respuesta anterior necesita otra llamada. Y como solo admite gpt-6-luna, no podés pasar a un modelo más grande para juicios más difíciles dentro de este endpoint.

Antes de migrar un pipeline de clasificación, pasá tus ejemplos ya etiquetados por los dos caminos y compará precisión, calibración de las probabilidades devueltas y latencia medida. Con estos precios el experimento sale barato; lo que hay que verificar son las afirmaciones del proveedor.