# OpenAI Decisions API vs Jev: los System One ya son commodity

OpenAI sacó su propio System One con la misma forma que Jev. Qué trae la OpenAI Decisions API, cómo se compara y cómo no quedar atado a un proveedor.

*agentes · 2026-10-07 · [mauriciosneira.com](https://mauriciosneira.com/blog/openai-decisions-api-clasificacion-agentes)*

---

Usás un LLM generalista para decidir si un ticket va a facturación o a soporte técnico. El modelo genera texto, vos parseás un JSON y recién ahí decidís. Para una decisión de una palabra, es mucho cómputo.

Hasta ahora, la alternativa seria era un modelo System One como [Jev de TypeSafe AI](/blog/jev-system-one-modelos-discriminativos-ia): mandás el contexto y preguntas tipadas, y te devuelve probabilidades. El 6 de octubre de 2026, en su DevDay, OpenAI abrió en beta pública la **OpenAI Decisions API**, que hace lo mismo y con casi la misma forma. En este post te cuento qué trae, en qué se parece a Jev y qué cambia ahora que los System One empiezan a ser commodity.

## Qué es la OpenAI Decisions API

Es un endpoint nuevo, `POST /v1/decisions`, que por ahora corre un solo modelo: `gpt-6-luna`. No genera texto. Le pasás un input y una lista de preguntas, y cada respuesta vuelve con un tipo fijo:

1. **Predicate:** una pregunta de sí o no. Devuelve la probabilidad de que sea "sí", de 0 a 1.
2. **Choice:** elegir una opción de una lista cerrada. Devuelve la opción, la probabilidad de cada una y un `confidence`.
3. **Score:** ubicar el input en niveles ordenados (por ejemplo, de "cosmético" a "bloqueante"). Devuelve un promedio ponderado, que puede caer entre dos niveles, con la probabilidad de cada nivel.

Los datos que publica OpenAI en la [guía de la Decisions API](https://developers.openai.com/api/docs/guides/decisions):

- Responde "unas 10 veces más rápido que la Responses API". No da un número en milisegundos.
- Cuesta US$ 0,10 por millón de tokens de entrada. No cobra la salida ni la caché.
- Acepta texto e imágenes (las imágenes sólo inline en base64, no por URL).
- Tiene Zero Data Retention, HIPAA y residencia de datos en EE.UU. y Europa.
- Está en beta pública y esperan llegar a GA "en las próximas semanas".

La misma guía marca el límite: si necesitás tu propio JSON schema o una explicación escrita, usá Structured Outputs; si el modelo tiene que llamar una herramienta, function calling.

## OpenAI Decisions API vs Jev: la misma idea con otro nombre

Si ya usaste Jev, esto te va a sonar. TypeSafe presentó Jev como el primer modelo System One con tres primitivos: **noul**, **choice** y **score**. OpenAI salió con **predicate**, **choice** y **score**. Cambia el nombre del primero, la idea es la misma.

| | OpenAI Decisions API | Jev (TypeSafe AI) |
| :--- | :--- | :--- |
| Modelo | `gpt-6-luna` | `jev-1.13.0` |
| Primitivos | predicate, choice, score | noul, choice, score |
| Precio de entrada | US$ 0,10 por millón de tokens | US$ 0,042 por millón de tokens |
| Salida | no se cobra | no se cobra |
| Input | texto e imágenes (base64) | sólo texto |
| Contexto | no lo publica en la guía | 64k tokens por request |
| Estado | beta pública | en uso, con límites que van ajustando ([modelos](https://docs.typesafe.ai/models)) |

Hoy Jev sale menos de la mitad por token y OpenAI suma imágenes. Pero lo importante es otra cosa: uno de los proveedores de modelos más grandes copió la forma de la API. Cuando eso pasa, la categoría deja de ser una apuesta de una startup y se vuelve algo que vas a poder comprar en varios lados. Como pasó con los embeddings.

## Qué cambia si ya usás Jev

Nada se rompe, pero hay tres cosas que conviene tener claras.

**1. Tu código tiene que hablar en primitivos, no en proveedor.** Las dos APIs piden lo mismo con distinta forma. En Jev, `questions` es un mapa por nombre y las opciones de un choice van en `criteria`; en OpenAI es una lista con `name`, y las opciones van en `choices`. Si tu lógica depende del JSON de un proveedor, cambiar es reescribir. Si tenés una capa propia, es cambiar un adaptador:

```python
# Una pregunta, dos proveedores. Tu código sólo ve "choice" y una opción.
def ask_choice(provider, text, name, instructions, options):
    if provider == "jev":
        body = {
            "model": "jev-latest",
            "state": text,
            "questions": {name: {"type": "choice", "instructions": instructions,
                                 "criteria": options}},
        }
        answer = post_jev(body)["answers"][name]
    else:  # openai
        body = {
            "model": "gpt-6-luna",
            "input": text,
            "questions": [{"type": "choice", "name": name, "instructions": instructions,
                           "choices": [{"value": k, "description": v} for k, v in options.items()]}],
        }
        answer = next(a for a in post_openai(body)["answers"] if a["name"] == name)
    return answer["choice"], answer["confidence"]
```

**2. Los umbrales no se mudan solos.** Un 0,90 de un modelo no significa lo mismo que un 0,90 del otro. Si tu [gate](/blog/gates-system-one-agentes) bloquea una acción cuando la probabilidad pasa 0,90, al cambiar de modelo ese corte deja pasar o frena cosas distintas. TypeSafe dice que entrena a Jev para que sus probabilidades estén calibradas; OpenAI no explica en la guía cómo calibra `gpt-6-luna`. La única forma de saberlo es medir con tus casos.

**3. Guardá tus casos de prueba.** Es lo que hace posible cambiar de proveedor sin miedo. En [Laya vs Jev](/blog/laya-vs-jev-system-one-open-vs-cerrado) usé 10 titulares fijos con la respuesta esperada y comparé los dos modelos con la misma fórmula. Con la Decisions API voy a hacer lo mismo: todavía no la medí, así que en este post no hay números propios de `gpt-6-luna`.

```mermaid
flowchart TD
    A["Tu código: predicate / choice / score"] --> B["Capa propia de decisiones"]
    B --> C["Jev (TypeSafe)"]
    B --> D["Decisions API (OpenAI)"]
    E["Casos de prueba con la respuesta esperada"] --> F["Umbrales medidos por modelo"]
    F --> B
```

## Qué le queda a Jev

Que llegue OpenAI no lo deja afuera. Hoy tiene a favor el precio (menos de la mitad por token) y el foco: es lo único que hace, con muchos ejemplos de uso en su documentación. Para un uso como [los guardrails de un LLM](/blog/system-one-guardrails-clasificacion-baja-latencia), donde todo pasa por el filtro, el precio por token pesa.

Lo que tiene que demostrar es calidad: que sus probabilidades sean más confiables que las de `gpt-6-luna` en tareas reales, y que el idioma no sea un problema (su documentación dice que funciona mejor en inglés). Ahí se va a decidir la competencia, no en la forma de la API, que ya es la misma.

## Qué hacer el lunes

1. **Buscá las llamadas a LLM que sólo deciden.** Si un prompt termina en "respondé sólo sí o no" o en un JSON de un campo, es candidato a un System One.
2. **Armá tu capa de decisiones.** Una función por primitivo (`ask_predicate`, `ask_choice`, `ask_score`) y un adaptador por proveedor. Tu lógica no tendría que saber a quién le pregunta.
3. **Congelá un set de casos con la respuesta esperada.** Con eso medís cualquier modelo nuevo y ajustás los umbrales antes de cambiarlo en producción.
4. **Dejá el razonamiento donde hace falta.** Si la decisión necesita una explicación escrita o varios pasos, usá un modelo generativo con Structured Outputs.

Que OpenAI haya sacado su propio System One es la mejor señal de que la idea funciona. Ahora lo que importa es que tu código no dependa de un solo proveedor.