Llevamos tres años midiendo los modelos de IA por lo bien que escriben. Y resulta que buena parte de lo que les pedimos en una automatización no es escribir: es decidir. Si este correo es spam, si este ticket es urgente, si esto lo tiene que ver una persona. Jev, el modelo que TypeSafe AI presentó el 15 de septiembre de 2026, no sabe escribir ni una sola frase. Solo decide, y te dice cuánto está seguro de cada decisión.

Jev es el primer modelo de TypeSafe AI, una empresa fundada por Diogo Almeida, que antes estuvo en OpenAI y es uno de los autores del trabajo de investigación que está detrás de cómo se entrenó ChatGPT.

Sus creadores lo llaman un System One model, en referencia al libro "Pensar rápido, pensar despacio" de Kahneman. El sistema uno es el pensamiento rápido, el que usas cuando ves una cara y sabes al instante si está enfadada, sin razonar. Eso es Jev: juicios rápidos y cerrados, no reflexión.

El nombre viene de William Stanley Jevons, un economista del siglo XIX conocido por una paradoja: cuando algo se abarata, en vez de consumirse menos, se consume mucho más.

Cuando le preguntas algo a un modelo como Sonnet o GPT, la respuesta se construye token a token, palabra a palabra, y cada una depende de la anterior. Por eso ves el texto aparecer poco a poco en pantalla.

Jev funciona distinto. Recibe información sin estructurar y devuelve decisiones acompañadas de una probabilidad. Nada de texto.

Un ejemplo. En un sistema de atención al cliente, tu aplicación le puede preguntar cuál es la probabilidad de que un correo entrante sea urgente o de que necesite revisión humana. Jev no te contesta con un párrafo explicando su razonamiento: te devuelve un número entre 0 y 1 para cada pregunta. Con ese número, tu sistema decide por umbrales. Por ejemplo, escalar el ticket cuando la probabilidad de urgente pasa de 0,8.

Esta es la parte que más me interesó, y la que menos se entiende a la primera.

Piensa en la diferencia entre el hombre del tiempo y tu amigo que siempre está muy seguro de todo. El hombre del tiempo dice que hay un 70% de probabilidad de lluvia, y de todos los días que dice eso, llueve aproximadamente siete de cada diez. Su afirmación está calibrada: el número significa algo.

Los LLM se parecen más a tu amigo. Dan sus respuestas con una confianza implacable, estén en lo cierto o se estén equivocando. Te pasa cada vez que ChatGPT o Claude te sueltan un dato con total seguridad y resulta que se lo ha inventado.

Jev promete lo contrario: que cuando dice 0,9, acierta más o menos nueve de cada diez veces. Eso es lo que permite montar reglas de verdad encima, porque el umbral que pongas significa algo.

Aquí es donde la cosa se pone interesante, porque la API no se parece a la de un chat.

Yo me lo imagino así. Piensa en Jev como un revisor de documentación. Llegas y le dejas un expediente encima de la mesa. Y ese expediente viene con un formulario de preguntas sobre ese mismo expediente.

El state es el expediente. Aquí va el contenido sobre el que quieres que Jev decida: el correo, la conversación, el documento, lo que sea. Puede ser texto suelto o un objeto con partes separadas, por ejemplo el asunto por un lado y el cuerpo por otro.

Las questions son el formulario. Cada pregunta tiene un nombre que eliges tú para identificarla en la respuesta, un tipo y la pregunta escrita en lenguaje normal.

Los creadores de Jev las llaman primitives, y hay tres tipos según lo que quieras que te responda.

choice pregunta cuál de estas opciones. Le das una lista de opciones con una descripción de cada una, y recibes la opción que ha elegido, la confianza con la que la ha elegido y el reparto de probabilidad entre todas.

noul pregunta si esto es verdad. Recibes un valor de 0 a 1 que indica lo seguro que está de que la respuesta sea sí. Cerca de 1 es un sí claro, cerca de 0 un no claro, y cerca de 0,5 significa que duda.

score pregunta a qué nivel. Le das una escala con niveles ordenados, de menos a más, y recibes una posición ponderada dentro de esa escala, que puede caer entre dos niveles.

Un detalle importante: un 0,5 en una pregunta de tipo noul no significa "un término medio". Significa que Jev no lo tiene claro. Si lo que quieres es medir un nivel, el tipo correcto es score.

Y se pueden mezclar los tres tipos en la misma llamada. Todas las preguntas se responden a la vez, no una detrás de otra.

La vía directa es su página oficial, typesafe.ai. El problema es que ahora mismo está saturada: hay lista de espera, así que no puedes usarlo hoy mismo.

La vía que sí funciona hoy es Vercel AI Gateway: https://vercel.com/docs/ai-gateway/sdks-and-apis/typesafe.

Vercel es una empresa conocida por publicar webs: le das tu código y ellos se encargan de ponerlo en internet. En los últimos tiempos se han metido de lleno en el mundo de la IA, y uno de sus servicios es este gateway.

Entras al dashboard de Vercel, vas al menú de AI Gateway, después a API Keys, y creas una. Cópiala en cuanto la crees, porque no te la vuelve a enseñar.

Lo bueno es que esa misma clave no sirve solo para TypeSafe. En Model List ves todos los modelos con los que Vercel está integrado: Anthropic, Alibaba, xAI y TypeSafe, entre otros. Pagas en un solo sitio y accedes a un montón de servicios.

La teoría se entiende mejor con un caso real. Cogí un agente de atención al cliente que tenía montado en Make y le puse Jev delante.

Ese agente hacía demasiadas cosas: leer el correo, clasificarlo, decidir si lo respondía, decidir si lo escalaba a una persona y encima redactar la respuesta. Todo dentro del mismo prompt.

Entre el módulo de Gmail y el del agente metí un módulo de Vercel AI Gateway, concretamente el de Make an API Call. Le pones la conexión con tu clave, el endpoint de tipo POST que viene en la documentación de Vercel, y en el body va la llamada a Jev.

En ese body, el state es el correo (asunto y cuerpo) y las questions son las cinco cosas que quiero saber de cada correo: si es spam o publicidad, si pregunta algo sobre el gimnasio, si va de cobros o de su cuenta, si es una queja y si es una propuesta de colaboración externa. Las cinco de tipo noul.

Aquí me encontré un problema que no esperaba. No puedes meter el cuerpo del correo directamente en el body: los saltos de línea y las comillas rompen el JSON y la petición da error. Lo sé porque hice unas cuantas pruebas hasta dar con ello.

La solución es añadir un módulo Create JSON antes, con una estructura que enlace el asunto y el cuerpo del correo de Gmail. Ese módulo se encarga de escapar los caracteres problemáticos, y luego usas su salida como state.

Como ahora hay un módulo que decide, el agente ya no tiene que hacerlo. Reescribí su prompt para quitarle toda la parte de clasificar y repartir.

El prompt antiguo tenía 898 palabras. El nuevo tiene 342.

Probé con cuatro correos distintos.

Spam. Una newsletter comercial de un proveedor. Jev le dio 0,96 de spam y el resto de valores casi a cero. Lo cazó a la primera. Aproveché para meter un filtro en el flujo: si la probabilidad de spam es mayor de 0,85, el correo ni siquiera llega al agente.

Consulta informativa. Alguien preguntando cosas del gimnasio. Spam casi nulo, queja casi nula, propuesta externa casi nula, y las que se dispararon fueron consulta informativa y cobro o cuenta. Acertado.

Propuesta de colaboración. Un creador de contenido ofreciendo colaborar. Propuesta externa en 0,97. También lo clavó. Curiosamente marcó 0,63 de spam, que tiene su lógica: al final es alguien ofreciéndote algo que no has pedido.

Un correo ambiguo. Aquí está lo interesante. El modelo dejó claro que no era spam ni una propuesta externa, pero repartió entre consulta informativa (que en parte lo es), cobro o cuenta (porque habla de tarifas) y un cierto valor en queja. No es un fallo: es el reflejo de que el correo de verdad es ambiguo.

Y esa es justo la conclusión práctica: tienes que probar con tus propios correos y, en función de los números que veas, decidir qué flujos y qué umbrales montas encima.

Después de las pruebas me fui al dashboard de Vercel a ver el gasto. Cuatro peticiones, más lo que había probado antes para preparar el vídeo, y los cinco dólares de crédito gratis seguían intactos. El coste marcaba cero.

Si quieres el dato exacto de una llamada, lo tienes en la propia respuesta de la API: en usage ves los tokens que se han usado, y en los metadatos del gateway aparece el coste real. En mi caso, una llamada con cinco preguntas costó 0,000021714 dólares.

Para que te hagas una idea, con los cinco dólares gratis saldrían unas 218.000 llamadas. O lo que es lo mismo, 218.000 correos.

También miré los tiempos: la mitad de las peticiones tardaron menos de 413 milisegundos.

Dos avisos antes de que te emociones con el precio.

El primero: la propia empresa reconoce que no puede asegurar que este precio no esté subvencionado. Así que no sabemos si será el precio definitivo.

El segundo: esto es lo que cuesta Jev, no lo que cuesta el resto del flujo. Y eso depende mucho de dónde lo montes. En Make, añadir dos módulos consume créditos, porque te cobra por cada módulo que se ejecuta. Si lo montaras en n8n, que cobra por ejecución de flujo completo, no notarías tanto esa diferencia. De hecho, podría salirte más barato.

Resumiendo.

Desde mi punto de vista, lo valioso de este tipo de modelos no es la velocidad ni el precio, que hoy están subvencionados y mañana ya veremos. Es que sacan la decisión de dentro del prompt y la ponen en un sitio donde la puedes ver, medir y ajustar. Cuando la decisión vive escondida en el razonamiento de un agente, no sabes por qué ha escalado un correo. Cuando vive en un umbral de tu flujo, lo cambias en diez segundos.

Si quieres ver todo esto montado paso a paso, con las pantallas de Make y los resultados de cada correo, lo tienes en el vídeo.

Y ahora te devuelvo la pregunta que dejé en el vídeo: ¿crees que este tipo de modelos va a cambiar la forma en la que construimos aplicaciones de IA, o es una tendencia más? Cuéntamelo en los comentarios.