OpenAI Decisions API: el nuevo rival de Jev y Laya, analizado

Hace unos días escribí sobre el paradigma System One y Jev, comparé a Jev con Laya y armé un pipeline de clasificación con Jev y un LLM verificador. Ahora OpenAI entra al terreno con la Decisions API, en beta pública, y la idea me resulta familiar: en vez de pedirle texto a un modelo, le haces preguntas tipadas y recibes probabilidades.

Aviso desde el principio: este es un análisis sobre el papel. Leí la documentación oficial completa y le hice una prueba pequeña con textos inventados y fotos públicas; la prueba grande, con mis datos etiquetados, viene en otro artículo.

En corto:

• Es un endpoint (POST /v1/decisions) que responde con probabilidades y opciones tipadas, no con texto libre.
• Su diferencia más clara frente a Jev y Laya es que acepta imágenes junto con el texto.
• Cobra solo tokens de entrada y no declara que sus probabilidades estén calibradas. Eso lo tienes que verificar tú.

---

Qué es la Decisions API

Según la documentación de OpenAI, la Decisions API evalúa texto, imágenes o ambos y devuelve respuestas tipadas. Los casos de uso que menciona son clasificar contenido, enrutar solicitudes y priorizar trabajo. Está en beta pública y OpenAI dice que la disponibilidad general llegará “en las próximas semanas”. Hoy solo admite un modelo: gpt-6-luna.

Es la misma idea de fondo que expliqué en el artículo de System One: muchas decisiones de un sistema no necesitan que el modelo escriba un párrafo, necesitan una respuesta que tu código pueda consumir sin parsear nada. Con generación de texto tienes que pedir JSON, validar y rezar. Aquí la forma de la respuesta la define el endpoint.

Ojo con un detalle: la documentación no dice que la Decisions API sea “no generativa” ni explica su arquitectura interna. Lo que sí afirma es que es “unas 10 veces más rápida que la Responses API”, sin dar benchmark ni condiciones. Por eso no voy a hablar de latencias: no tengo datos.

---

Cómo funciona

La petición lleva tres campos:

• model: por ahora solo gpt-6-luna.
• input: la evidencia compartida. Puede ser un texto o mensajes de usuario con partes input_text e input_image.
• questions: una lista de preguntas. Cada una tiene un type, un name único, instrucciones y, según el tipo, choices o levels.

La respuesta trae un arreglo answers con un elemento por pregunta, identificado por el name que tú definiste. Un ejemplo ilustrativo, armado solo con los campos documentados (no es una salida real):

{
  "model": "gpt-6-luna",
  "input": "Bomba P-101: fuga por el sello, goteo constante desde ayer.",
  "questions": [
    {
      "type": "predicate",
      "name": "es_falla",
      "instructions": "¿El texto describe una falla real y no una rutina?"
    },
    {
      "type": "choice",
      "name": "tipo",
      "instructions": "Tipo de intervención.",
      "choices": ["correctivo", "preventivo", "predictivo", "otro"]
    }
  ]
}

La respuesta tendría la forma {"answers": [{"type": "predicate", "name": "es_falla", "probability": ...}, {"type": "choice", "name": "tipo", "choice": ..., "probabilities": [...], "confidence": ...}]}.

Las preguntas independientes pueden compartir una misma petición. Si una decisión depende de otra, la documentación indica que van en peticiones separadas.

Tabla 1: Los tres tipos de pregunta de la Decisions API

Tipo	Qué evalúa	Qué devuelve
predicate	Una condición verdadera o falsa	probability entre 0 y 1
choice	Una opción entre valores que tú das (categorías sin orden)	choice, un arreglo probabilities por opción y confidence
score	Un nivel dentro de levels ordenados (por ejemplo, severidad)	score (promedio de los índices de nivel ponderado por probabilidad), probabilities y confidence

Dos detalles prácticos de la tabla. Primero, como score es un promedio ponderado por probabilidad, el resultado puede caer entre dos niveles. Segundo, una respuesta puede venir como refusal: los ejemplos de código de la documentación revisan si una respuesta tiene type igual a "refusal". No hay un JSON de ejemplo que muestre su forma completa, así que tu código debe contemplarla.

Si lo que necesitas es un objeto JSON a medida o llamadas a herramientas, la propia documentación recomienda Structured Outputs o function calling, no esta API.

---

Imágenes: la ventaja real

Aquí está lo que, para mí, más distingue a la Decisions API. En mis artículos anteriores, Jev y Laya trabajaron con texto. La Decisions API acepta partes input_image dentro de input, mezcladas con texto, y hace preguntas tipadas sobre ambas cosas a la vez.

La documentación trae ejemplos como detectar daño visible en la foto de un producto con una pregunta predicate. A partir de eso, y como ejemplos hipotéticos míos, se me ocurren usos como estos:

• Mantenimiento: una foto de la placa de un equipo o de una falla visible más una línea de texto del técnico, y preguntas como “¿hay evidencia visible de fuga?” (predicate) o “severidad del daño” (score).
• Moderación de catálogo: foto de producto más título, con una pregunta choice sobre la categoría y un predicate sobre contenido inapropiado.
• Triaje de documentos: la imagen de un formulario o un soporte escaneado y una pregunta choice sobre a qué cola va.

Piensa en mi pipeline de órdenes de mantenimiento: hoy el técnico describe la falla en 40 caracteres. Si algún día adjuntara una foto, un modelo que lea ambas cosas tendría más evidencia que cualquier normalizador de texto. No sé si funciona bien; solo que la API lo permite.

La restricción: solo base64

Las imágenes deben enviarse como data URLs en base64 dentro de la petición. La documentación es explícita: no se aceptan URLs HTTP o HTTPS ni file_id. En la práctica significa que tu servicio tiene que descargar o leer el archivo, codificarlo y enviarlo. Eso afecta el tamaño de la petición y tu código de ingesta. La documentación que leí no da límites de tamaño ni de cantidad de imágenes, así que no los voy a inventar: pruébalos antes de diseñar sobre ellos. Tampoco explica cuántos tokens consume una imagen, y eso importa para el costo.

Privacidad

Enviar imágenes a un tercero tiene el mismo problema que enviar texto, con una complicación extra: una foto puede mostrar caras, matrículas, pantallas, etiquetas con códigos internos. Mi regla de siempre aplica: recorta y anonimiza antes de enviar, y pon un control que cancele la petición si algo sensible pasa. Del lado de OpenAI, la documentación dice que la API admite Zero Data Retention y uso HIPAA para clientes elegibles, y que hay residencia de datos y procesamiento regional en Estados Unidos y Europa (EEA y Suiza). Los requisitos de elegibilidad están en su guía de controles de datos; tampoco los asumas.

---

Decisions vs. Jev vs. Laya

Para esta comparación solo uso lo que dice la documentación de OpenAI y lo que ya publiqué sobre Jev y Laya. Donde no tengo dato, lo marco como “no documentado”.

Tabla 2: Comparativa entre la Decisions API, Jev y Laya

Dimensión	Decisions API (OpenAI)	Jev (TypeSafe AI)	Laya (ConvAI)
Tipos de pregunta	predicate, choice, score	noul (booleano), choice, score	Clasificación por opciones sobre ModernBERT
Entrada	Texto, imágenes (base64) o ambos	Texto y campos estructurados (hasta 32.000 tokens)	Texto (en mis pruebas)
Probabilidades	Por opción en choice y score, más confidence	Probabilidades y confianzas por pregunta	Probabilidades, pero en mi prueba con sesgo optimista
Declaración de calibración	No la hace; recomienda fijar umbrales con tus ejemplos	Sí: entrenamiento RLCD y pérdida de Brier	Sin calibración limpia en mi prueba
Número máximo de opciones	No documentado	Hasta 255	Acotado: conviene menos de 5 a 8 opciones en zero-shot
Despliegue	API en la nube de OpenAI	API en la nube (SaaS)	Código abierto (Apache-2.0), local
Precio	US$0,10 por 1M de tokens de entrada, sin cargo por salida	No lo comparo en esta tabla: mi medición fue por 1.000 órdenes (ver más abajo)	Sin costo de API; pones tú el cómputo
Residencia de datos	EE. UU. y Europa (EEA y Suiza)	No lo cubrí en mis artículos	Total: corre en tu infraestructura
Madurez	Beta pública, GA “en las próximas semanas”	Producto comercial (versión 1.13 que usé)	Modelo abierto
Modelos disponibles	Solo gpt-6-luna	No lo cubrí	ModernBERT-Large y mmBERT

Resumen de la lectura: Decisions compite con Jev en el mismo nicho (API en la nube, preguntas tipadas, probabilidades) y añade imágenes. Laya sigue siendo la opción cuando los datos no pueden salir de tu red. No es una comparación de calidad: de la Decisions API no tengo ni un dato de exactitud.

Una estimación de costo, con sus supuestos

Con el precio documentado puedes hacer una cuenta aproximada. Es una estimación gruesa, no una medición. Supongamos 500 tokens de entrada por petición, solo texto:

• 1.000 peticiones x 500 tokens = 500.000 tokens.
• A US$0,10 por millón: unos US$0,05 por cada 1.000 peticiones.

Para tener contexto, en mi pipeline Jev costó unos US$0,054 por cada 1.000 órdenes. La coincidencia de cifras no debe engañarte: mi 0,054 es un costo medido de un panel, con mis prompts y mis preguntas, y el 0,05 de arriba sale de un supuesto de tokens. Además, cada proveedor cuenta los tokens a su manera, y la documentación puede aplicar multiplicadores regionales y por contexto largo. Con imágenes, el costo depende de cuántos tokens genere cada imagen, algo que la documentación que revisé no detalla. Mide con tu tráfico antes de sacar conclusiones.

---

Lo que la documentación no dice

Esta es la parte que más me importa, porque es donde se decide si algo sirve en producción:

1. No promete calibración. Jev presume de haber sido entrenado para que sus probabilidades signifiquen algo. La Decisions API entrega probabilidades y confidence, pero la documentación no dice que estén calibradas. Lo que sí dice es que uses ejemplos etiquetados de tu aplicación para fijar umbrales, según el costo de falsos positivos y falsos negativos. Es un consejo sensato y a la vez una advertencia.
2. No da límites. No encontré topes de número de preguntas, de opciones por pregunta, de niveles, de tamaño de imagen ni de longitud de entrada. Que no estén documentados no significa que no existan.
3. El “10x más rápida” no tiene respaldo. Es una frase de la introducción, sin datos ni condiciones (en mi prueba pequeña fue unas 3 veces más rápida, te lo muestro más abajo). Además, el modelo gpt-6-luna ya pasó por mi mesa en un piloto anterior, donde tardó casi 30 s por lote de 10 órdenes. Esta API usa el mismo nombre de modelo pero otro endpoint, así que no infiero nada sobre su latencia.
4. Un solo modelo. Solo gpt-6-luna: no hay una opción más pequeña ni más grande para ajustar costo contra calidad.
5. Es beta. La disponibilidad general llega “en las próximas semanas”. Los detalles pueden cambiar.
6. Cómo está construida por dentro. No lo explica, y por eso no sé si se parece a Jev en algo más que en la forma de la respuesta.

---

¿Cuándo usarla?

Mi guía, razonada y sin haberla probado:

• Tienes imágenes en la decisión. Hoy es el motivo más fuerte. Jev y Laya, en lo que yo cubrí, trabajan con texto.
• Solo hay texto y necesitas probabilidades calibradas de entrada. Jev declara calibración; Decisions pide que valides tú los umbrales.
• Los datos no pueden salir de tu infraestructura. Laya, con fine-tuning, sigue siendo el camino. Decisions ofrece residencia regional, que no es lo mismo que correr local.
• Necesitas más de unas pocas decenas de opciones. Jev documenta hasta 255; en Decisions no hay un tope documentado, así que prueba antes.
• Necesitas explicaciones en texto o JSON a medida. Ninguna de las tres: ahí van Structured Outputs o un LLM generativo.

Un papel posible en mi pipeline

En el pipeline de órdenes de mantenimiento, Jev clasifica todo y un LLM verifica las dudosas. La Decisions API podría entrar de dos formas, y las dos son hipótesis mías:

• Como verificador rápido en el lugar del LLM generativo, usando sus probabilidades para decidir qué órdenes revisar.
• Como capa para órdenes con foto, donde el texto de 40 caracteres no alcanza y la imagen aporta lo que falta.

Que cualquiera de las dos valga la pena depende de datos que todavía no tengo.

---

Una primera prueba, pequeña

Antes del experimento grande hice una prueba corta para comprobar lo básico: qué devuelve de verdad, si es estable, qué tan rápida es y cuánto cuesta una imagen. Usé textos de mantenimiento inventados y 6 fotos con licencia libre de Wikimedia Commons, nada de datos de clientes. Fueron 61 peticiones en total, con un costo de unos US$0,003.

Ojo con el alcance: con textos inventados no hay etiquetas reales, así que esto no mide exactitud. Mide forma, estabilidad, velocidad y costo.

Lo que devuelve en la práctica

Una petición con las tres preguntas juntas (falla, tipo y severidad) sobre el texto «fuga sello mecánico bba centrífuga, se cambió sello» devolvió esto (resumido):

{
  "model": "gpt-6-luna",
  "answers": [
    { "type": "predicate", "name": "es_falla", "probability": 0.95 },
    {
      "type": "choice",
      "name": "tipo",
      "choice": "correctivo",
      "confidence": 1.0
    },
    { "type": "score", "name": "severidad", "score": 0.96, "confidence": 0.88 }
  ],
  "usage": { "input_tokens": 492, "output_tokens": 0, "total_tokens": 492 }
}

Tres cosas que la guía no cuenta:

• La respuesta trae un bloque usage con los tokens cobrados; la guía no lo documenta. output_tokens siempre fue 0, consistente con que solo cobra entrada.
• predicate devuelve la probabilidad, pero no trae confidence; solo choice y score la traen.
• El score es un índice ponderado: 0,96 significa “casi exactamente en el nivel 1” (media), que es donde estaba el 89 % de la probabilidad.

Estabilidad: la misma pregunta cinco veces

Repetí la misma petición 5 veces y las respuestas fueron idénticas: misma etiqueta, mismas probabilidades hasta el último decimal (desviación estándar 0). Para un clasificador eso es bueno: lo que cambie en tus resultados será por el texto, no por azar del modelo.

Velocidad y costo frente a la Responses API

Mandé los mismos 20 textos por dos caminos: la Decisions API, y la Responses API con el mismo modelo, salida estructurada (JSON con enums) y razonamiento en none, el nivel más bajo que acepta. Alterné el orden para no favorecer a ninguna.

Tabla 3: Decisions API frente a Responses API con 20 textos inventados

Métrica	Decisions API	Responses API (gpt-6-luna, razonamiento none)
Latencia media	0,47 s	1,63 s
Latencia p50	0,42 s	1,40 s
Latencia p95	0,58 s	2,42 s
Tokens por petición	~495 de entrada	~207 de entrada + ~26 de salida
Costo de las 20 peticiones	US$0,00099	US$0,00067
Costo estimado por 1.000 peticiones	~US$0,05	~US$0,03

Dos lecturas:

1. Fue unas 3,3 veces más rápida en la mediana, no 10. Con razonamiento por defecto en la Responses API la diferencia seguramente sería mayor, pero eso ya no es una comparación justa.
2. No fue más barata. Que no cobre la salida no compensa que cada petición pese más: las definiciones de las preguntas ocupan casi 500 tokens y el texto de la orden apenas unos 15. Si mandas muchas preguntas por petición o textos largos, la cuenta puede cambiar; con textos cortos, hoy sale más cara. Coincide con la estimación de 500 tokens por petición que hice arriba.

En es_falla las dos coincidieron en los 20 textos. En tipo, en 17: las tres diferencias fueron casos ambiguos, como «ruido raro en rodamiento, programar cambio», donde Decisions eligió predictivo y la Responses API, correctivo. Sin etiquetas no puedo decir cuál acertó.

Imágenes: seis fotos de equipos

Le pasé 6 fotos públicas, 3 de equipos con daño visible (corrosión, una fuga, una bomba erosionada) y 3 de equipos en buen estado, con la pregunta “¿hay daño visible?” y “¿qué componente es?”.

Tabla 4: Respuestas de la Decisions API sobre seis fotos de equipos

Foto	Lo esperado	Probabilidad de daño	Componente elegido	Tokens de la imagen
Bomba de hierro fundido erosionada	Daño, bomba	1,00	otro	1.253
Fuga en tubería oxidada	Daño, tubería	1,00	tubería	1.368
Tuberías corroídas	Daño, tubería	0,99	otro	2.608
Motor eléctrico	Sin daño, motor	0,05	motor	1.648
Motobomba	Sin daño, bomba	0,75	bomba (confianza 0,45)	1.448
Válvula de seguridad	Sin daño, válvula	0,12	válvula	618

• Detectó el daño en las tres fotos que lo tenían y descartó dos de las tres sanas. La motobomba en buen estado sacó 0,75 de probabilidad de daño, un falso positivo claro con umbral 0,5.
• Acertó el componente en 4 de 6. Las dos fallas fueron “otro” en vez de bomba o tubería.
• Una imagen costó entre 618 y 2.608 tokens, es decir, entre US$0,00006 y US$0,00026. El costo crece con las dimensiones de la foto, no con su peso en bytes: si vas a mandar muchas, redúcelas antes.

Con 6 fotos esto es una señal, no una medición. Pero muestra el punto que más me interesa: la imagen sí aporta información, y también que los umbrales hay que calibrarlos con tus propios casos, como dice la documentación.

Lo que voy a probar

Mi plan es medirla con el mismo rigor que a Jev: las 200 órdenes etiquetadas a mano del experimento anterior, sobre las mismas 2.000 órdenes. Quiero comparar:

• Exactitud frente a mis etiquetas humanas en es_falla y tipo, contra Jev y contra el híbrido.
• Latencia con textos reales y en volumen: en la prueba pequeña fue unas 3 veces más rápida que la Responses API, no 10.
• Costo medido en el panel de OpenAI, no estimado, y si conviene agrupar varias preguntas por petición para repartir el peso de las definiciones.
• Utilidad de las probabilidades para enrutar: si un umbral sobre confidence separa bien las órdenes que se equivocan, a diferencia del router por confianza que me falló con Jev.

Cuando lo tenga, lo publico con sus limitaciones, igual que hice con los resultados de Jev.

---

Conclusión

La Decisions API valida la dirección que venimos viendo: sacar las decisiones discretas del flujo de generación de texto y devolverlas como datos tipados con probabilidades. Su aporte distintivo es la entrada de imágenes; su punto débil, hoy, es que no hay datos que respalden la calibración, la velocidad ni los límites.

Mientras tanto, no cambies nada en producción por una página de documentación. Si tienes un caso con texto e imágenes, o ya usas Jev y quieres saber si vale la pena probar otra opción, escríbeme a contact@camilordz.com y lo medimos con tus datos.

---

Fuentes y lecturas recomendadas

• OpenAI: Decisions API guide (consultada el 14 de octubre de 2026).
• OpenAI: Pricing y Data controls, citadas desde la guía.
• Deußer, T., Sparrenberg, L., & Sifa, R. (2026): Evaluating and Benchmarking the System One Model Jev, arXiv:2609.37647.
• Artículos relacionados en este blog:
  • JEV y el Paradigma System One: Por qué generar texto token por token es un desperdicio
  • JEV vs. Laya: Comparativa Real en Inferencia System One y Lecciones Aprendidas
  • Clasificar Texto Sucio a Gran Escala: cómo armar un pipeline con JEV y un LLM verificador