JEV: un modelo que no chatea, decide

Introducción

Seré honesto: casi todo lo que le he pedido a un LLM dentro de un programa terminó igual. Le pido que clasifique algo, me responde con un párrafo amable, y yo acabo escribiendo un parser para sacar la palabra que de verdad necesitaba. Si la respuesta viene con un "Claro, con gusto" o con una categoría que no existe, el parser truena. Y el modelo, mientras tanto, está pensando token por token para decirme "sí".

Hace poco TypeSafe AI presentó JEV, y la idea me llamó la atención justo por ahí: un modelo que no está hecho para conversar, sino para decidir. Lo probé, armé una demo con tres ejemplos y en este post te cuento qué es, cómo se le pregunta y qué aprendí construyéndola.

Qué es JEV

Según el anuncio oficial, JEV es el primer System One Model de TypeSafe AI: un modelo pensado para automatizar decisiones dentro de software, no para chatear. La comparación que hacen es con el "pensamiento rápido" (System One) frente al razonamiento largo y deliberado de un LLM de chat.

Las diferencias que ellos destacan:

• Devuelve valores tipados, no strings. Le das una pregunta con opciones y responde con una de ellas, no con prosa.
• Trae probabilidades calibradas. Si dice 80% de confianza, la idea es que acierte cerca del 80% de las veces.
• Es rápido y barato. Hablan de 70-500 ms de punta a punta y de entrada a $0.042 por millón de tokens, con la salida gratis.
• No puede salirse del tipo. Como genera todas las salidas en paralelo sobre opciones que tú defines, no hay respuestas fuera del set.

Son números de la empresa

Las cifras de velocidad y costo ("193.6x más rápido, 444.6x más barato" en sus evaluaciones de workflows) vienen del anuncio de TypeSafe, no de mis pruebas. Yo no las medí. Si te importan, revisa sus evaluaciones y mídelas con tu caso.

Para ubicarlo: no reemplaza a un LLM de chat. Es una pieza distinta para otro trabajo, el de esas decisiones pequeñas y repetitivas que hoy resolvemos con un if frágil o con un prompt largo.

Y como era de esperarse, las demás no tardaron en responder

JEV se presentó el 15 de septiembre. Menos de dos semanas después, el 29, OpenAI mostró en su DevDay 2026 la Decisions API: un endpoint dedicado a decisiones en tiempo real, con una versión especializada de su modelo Luna. La mecánica te va a sonar conocida: mandas contexto, una pregunta y un conjunto finito de respuestas que tú defines, y recibes una de ellas con un puntaje de confianza. No genera texto libre y no puede inventar una respuesta fuera de tu lista.

Los casos de uso que mencionan también son los mismos: clasificar, enrutar peticiones, elegir qué agente atiende una tarea o decidir el siguiente paso de un agente. Incluso hay quien ya lo compara de frente con JEV.

Todavía no se puede probar

Según los resúmenes que revisé, la Decisions API está en vista previa limitada y OpenAI no ha publicado esquema de petición, de respuesta, ruta del endpoint, método de SDK ni precios. Los 150 ms frente a 1.6 s de un llamado normal salen de su diapositiva del DevDay, así que son cifras suyas, igual que las de TypeSafe. Lo que sí puedes probar hoy, con acceso anticipado, es JEV.

Que una empresa del tamaño de OpenAI sacara su propia versión me dice algo: la idea de "decisiones tipadas en vez de texto" no es un capricho de una startup. Pero ojo, es una señal de que el patrón importa, no una prueba de cuál implementación es mejor. Eso se mide con tus datos.

Las tres preguntas que sabe hacer

JEV expone tres tipos de pregunta (la documentación les llama primitivas), y mi demo tiene un ejemplo por cada una:

Primitiva	Qué le preguntas	Qué devuelve
Choice	Elige una opción de una lista cerrada	choice, confidence, probabilities
Score	Ubica el texto en una escala ordenada	score, confidence, probabilities
Noul	Responde sí o no	noul, un número entre 0 (no) y 1 (sí)

El texto que escribe el usuario es el state, y a cada pregunta le defines las respuestas posibles. Eso es todo el contrato.

La demo

La demo es una página sencilla en Flask. Escribes un texto, eliges el tipo de pregunta y ves qué decide JEV, qué tan seguro está, el código Python con el que se le preguntó y una explicación en lenguaje llano.

Los tres ejemplos:

• Elegir una opción (Choice). "¿Qué comida o bebida encaja con este texto?", con unas 130 opciones representadas por emoji. Escribes "hace mucho frío y quiero algo caliente para desayunar" y JEV elige una. Si escribes algo sin sentido como asdkjfh 42 lunes 🦋, igual elige una de la lista: nunca inventa una nueva.
• Calificar en una escala (Score). Escribes un mensaje como si fueras un cliente y JEV decide qué tan urgente es, de 0 a 3, con niveles que yo definí ("puede esperar", "durante el día", "en la próxima hora", "ahora mismo").
• Responder sí o no (Noul). ¿La persona está pidiendo hablar con un humano? Devuelve un número entre 0 y 1, y yo decido el umbral.

Cómo se le pregunta desde Python

Lo que más me gustó es lo poco que hay que escribir. Con el SDK, una pregunta Noul queda así:

from typesafe_sdk import TypeSafeClient, Noul, NoulCriteria

client = TypeSafeClient()  # lee TYPESAFE_API_KEY del entorno

question = Noul(
    instructions="¿La persona está pidiendo hablar con un agente humano?",
    criteria=NoulCriteria(
        true="Pide explícita o implícitamente hablar con una persona real",
        false="No pide hablar con una persona; solo pregunta o comenta",
    ),
)

response = client.system_one(
    state="Ya pregunté tres veces lo mismo. ¿Puedo hablar con alguien de verdad?",
    questions={"q": question},
)

print(response.answers["q"].noul)  # un número entre 0 y 1

state es el texto, questions es un diccionario con las preguntas (puedes mandar varias en la misma consulta) y la respuesta llega en response.answers, con la misma llave que usaste. Para Choice cambia la primitiva y lees .choice y .probabilities; para Score, .score.

El resultado ya es un dato, no un texto. En la demo ese número noul se compara con 0.5 y decide si el bot sigue o si se pasa la conversación a una persona. Sin parser, sin regex.

Lo que aprendí construyéndola

Un par de decisiones de la demo que creo que sirven para cualquier proyecto con una API de pago:

• La clave vive solo en el servidor. El navegador le pega a mi endpoint /api/decide y es Flask quien llama a JEV. La API key nunca llega al cliente.
• Valido antes de gastar cuota. Texto vacío o de más de 500 caracteres se rechaza antes de llegar a JEV. Cada consulta cuesta, y la demo es pública.
• Los errores se traducen. Una clave inválida, un límite de peticiones o un corte de conexión se convierten en mensajes claros para el visitante, no en un 500 genérico.
• Un solo worker en producción. El "registro reciente" que muestra la página vive en memoria del proceso. Con varios workers cada uno tendría el suyo y verías resultados distintos según quién te atendiera. Para una demo, un worker de gunicorn con varios hilos alcanza, porque casi todo el tiempo se va esperando a JEV.

Si lo vas a publicar

Una demo pública gasta la cuota de tu clave con cada visita. Revisa los límites de tu plan o agrega un límite de consultas por IP antes de compartir el enlace. Y avisa que el registro reciente lo ve cualquiera: que nadie escriba datos sensibles ahí.

Corre la demo tú mismo

Necesitas Python 3.10 o superior y una API key de TypeSafe (están abriendo acceso anticipado desde una lista de espera, así que revisa su consola).

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

cp .env.example .env
# completa TYPESAFE_API_KEY en .env

python app.py

Abre http://localhost:5000. Si prefieres Docker:

docker build -t jev-demo .
docker run --rm -p 8000:8000 -e TYPESAFE_API_KEY=tu_clave jev-demo

Dónde no encaja

• No es un asistente. No redacta, no explica, no conversa. Si necesitas texto libre, sigues necesitando un LLM.
• Las decisiones son tan buenas como tus opciones. Choice nunca se sale de la lista, pero si tu lista está mal pensada, JEV elegirá bien... entre malas opciones.
• Está en acceso anticipado. Hay lista de espera y el producto es joven. No lo casaría con un flujo crítico sin probarlo bastante con tus propios datos.
• Las probabilidades calibradas hay que confirmarlas. Es lo que prometen, y para una demo me sirvieron, pero no las validé a escala. Si vas a automatizar algo importante con ese umbral, mídelo tú.

Conclusión

Lo que me llevo de JEV no es "otro modelo más". Es que me obligó a replantear cuántas de mis llamadas a un LLM en realidad eran una decisión disfrazada de conversación. Muchas veces no necesito que el modelo me explique nada: necesito un sí, un no o una categoría, con qué tan seguro está, y que llegue rápido y en el tipo correcto.

No sé si System One termine siendo una categoría que se quede, y tampoco quita el deber de verificar lo que decide. Pero como pieza para esas decisiones pequeñas, repetitivas y con opciones cerradas, me parece una idea que vale la pena probar. La demo es una buena forma de hacerlo en diez minutos.

Referencias

Introducing System One Models & JEV (TypeSafe AI)|Documentación de TypeSafe AI|Evaluaciones de TypeSafe AI|OpenAI DevDay 2026 Recap|OpenAI's Decisions API vs Jev (Firecrawl)