Qué es JEV de TypeSafe AI y cómo usarlo en tu código

Q: ¿Jev sustituye a mi LLM?

No, y no lo pretende. Jev no escribe código, ni resúmenes, ni respuestas a un usuario. Sustituye a las llamadas de tu pipeline que solo devuelven una etiqueta, un booleano o una nota del 1 al 5. El LLM se queda para generar.

Q: ¿Qué significa exactamente que las probabilidades estén calibradas?

Que el número es verificable: de todo lo que Jev responde con un 90% de probabilidad, acierta cerca del 90% de las veces. Es lo que optimiza RLCD, frente a RLHF, que optimiza que la respuesta le guste a un humano y produce modelos que suenan igual de seguros acertando que inventando.

Q: ¿Puede alucinar Jev?

Sí, en el sentido que importa. Lo que no puede es devolver un tipo inválido: eso está garantizado por diseño, no por estadística. Pero puede devolver una opción perfectamente válida y equivocada, y hacerlo con confianza alta. Trata el confidence como una señal de enrutado, nunca como una garantía de verdad.

Q: ¿Cuánto cuesta y cuánto tarda?

$0,042 por millón de tokens de entrada y salida gratis. TypeSafe cita de 70 a 500 ms de inferencia, unos 100 ms típicos; medido desde mi red, el end-to-end fue de 258 ms de mediana y nunca bajó de 213 ms. Los límites publicados: 250.000 tokens por segundo, 1.200 requests por minuto y un presupuesto compartido de unos 64.000 tokens por request.

Q: ¿Qué hago si tengo más de 255 opciones?

Ese es el techo de una elección de una sola etapa. Por encima toca scoring en dos pasadas: reduces el espacio con un score sobre categorías gruesas y luego haces el choice fino dentro del grupo ganador. Sigue saliendo más barato que encadenar llamadas a un LLM, pero deja de ser gratis en complejidad.

Tienes un clasificador de tickets en producción. Entra un ticket, lo mandas a un modelo de cientos de miles de millones de parámetros y esperas casi dos segundos a que razone en voz alta para acabar escupiendo una palabra: billing.

Pagas la entrada, pagas la salida —cinco veces más cara— y te llevas una etiqueta. Y no sabes si el modelo estaba seguro o echando una moneda al aire: el JSON sale válido en los dos casos.

Ese es el agujero que quiere tapar Jev de TypeSafe AI, que salió el 15 de septiembre de 2026. Hace cuatro días.

Lo firma Diogo Almeida, co-autor de InstructGPT y co-inventor del RLHF en OpenAI, con 40 millones de dólares liderados por DCVC. No es un wrapper: es una arquitectura nueva que renuncia a generar texto a propósito.

En corto: Jev es el primer modelo de TypeSafe AI y no genera texto. Recibe un estado no estructurado y devuelve decisiones tipadas —binarias, elecciones o puntuaciones— con probabilidades calibradas, en unos 250 ms medidos de extremo a extremo —unos 100 ms de inferencia más el viaje de red— y a $0,042 por millón de tokens de entrada con la salida gratis. Sirve para clasificar, enrutar, extraer y puntuar. No sirve para escribir código, contar ni hacer cuentas.

¿Qué es Jev, el System One Model de TypeSafe AI?

Jev —que el fabricante escribe así, no "JEV"— es un "System One Model": un modelo que convierte estado no estructurado en decisiones tipadas con probabilidades calibradas, sin generar ni una línea de texto libre. Es el primer modelo de TypeSafe AI y se lanzó el 15 de septiembre de 2026.

Lo aclaro porque el acrónimo en mayúsculas ya estaba cogido: JEV es, en literatura médica, el virus de la encefalitis japonesa. A partir de aquí lo escribo como lo escriben ellos.

El nombre viene de Kahneman. El Sistema Dos delibera y escribe: eso es un LLM. El Sistema Uno responde por reflejo, y su salida no es prosa sino un juicio. Jev es lo segundo, con la parte cara amputada.

El truco es arquitectónico: un sampler paralelo que muestrea todas las respuestas a la vez en lugar de ir token a token. Por eso es tan rápido. Y por eso no puede explicarte por qué decidió lo que decidió — no hay secuencia donde escribirlo.

Está entrenado exclusivamente con datos sintéticos, y con un método distinto: RLCD, Reinforcement Learning for Calibrated Decisions.

¿En qué se diferencia RLCD de RLHF?

RLHF optimiza que la respuesta le guste a un evaluador humano. De ahí que los LLM suenen igual de seguros inventando que acertando: la seguridad puntúa bien. RLCD optimiza otra cosa — que las probabilidades sean epistémicamente honestas.

Calibrado significa esto: de todo lo que el modelo responde con un 90% de probabilidad, debería acertar alrededor del 90% de las veces. No el 99% ni el 60%. El número significa lo que dice.

Si has peleado con logprobs sabes por qué importa: esos números existen, pero no están calibrados. Un 0.95 no te promete 19 aciertos de cada 20. Jev dice que sí — y es la única promesa del lanzamiento que puedes verificar tú en una tarde: agrupa tus respuestas por tramo de probabilidad y mira qué porcentaje acierta cada tramo. Si cuadra, sobre eso puedes escribir un if.

Es el mismo fondo que expliqué en por qué la IA se inventa cosas: el problema no es que el modelo se equivoque, es que se equivoca con el mismo tono con el que acierta.

Las tres primitivas: noul, choice y score

La API es un endpoint REST, POST https://api.typesafe.ai/v1/systemone, con bearer token. Le mandas tres cosas: model (por ejemplo jev-latest), state —string, objeto JSON o array de texto— y questions.

Las preguntas referencian campos del estado con notación de backticks: `ticket`, `mensaje`. Y solo hay tres tipos:

noul — binaria sí/no. Devuelve una probabilidad de 0 a 1.
choice — elige entre opciones que tú defines. Devuelve la opción, la distribución completa de probabilidad y un confidence de 0 a 1.
score — sitúa algo en una escala ordenada. Devuelve la media ponderada, la distribución y un confidence.

Con el SDK de JavaScript, @typesafe-ai/sdk, se ve así:

import { choice, noul, score, TypeSafeClient } from &#39;@typesafe-ai/sdk&#39;

const client = new TypeSafeClient()

const { answers } = await client.systemOne({
  state: { ticket },
  questions: {
    category: choice(&#39;What kind of ticket?&#39;, { bug: &#39;...&#39;, billing: &#39;...&#39; }),
    severity: score(&#39;How severe?&#39;, [&#39;Low&#39;, &#39;Medium&#39;, &#39;High&#39;])
  }
})

Hay SDK de Python equivalente (from typesafe_sdk import Choice, Noul, TypeSafeClient, con client.system_one(...)) e integración con el Vercel AI SDK vía experimental_evaluate() y typeSafeAi.evaluationModel('jev-latest'), o con el string de gateway 'typesafe-ai/jev'.

Fíjate en lo que no hay en ese código: ningún prompt pidiendo "responde solo con JSON". Ninguna función de reparación. Ningún reintento. El tipo no es una súplica al modelo, es la superficie de salida del modelo.

Si vienes de montar esto a mano con schemas y validación —el camino que recorro en diseñar schemas Zod para LLM— el contraste es incómodo: la mitad de ese andamiaje deja de tener función. La otra mitad no — los tipos siguen siendo tuyos en cuanto la respuesta entra en tu dominio, y eso lo trabajo entero en el curso de Zod para TypeScript.

Caso práctico: triaje de tickets con umbrales

El patrón que mejor rinde es el fan-out especulativo: preguntar de golpe todo lo que no dependa de nada. Sale más barato que la cadena secuencial equivalente.

const { answers } = await client.systemOne({
  model: &#39;jev-latest&#39;,
  state: { ticket },
  questions: {
    category: choice(&#39;What kind of ticket is `ticket`?&#39;, {
      bug: &#39;Something in the product is broken&#39;,
      billing: &#39;Charges, invoices or refunds&#39;,
      feature: &#39;A request for something that does not exist yet&#39;,
      other: &#39;Anything else&#39;
    }),
    severity: score(&#39;How severe is `ticket`?&#39;, [&#39;Low&#39;, &#39;Medium&#39;, &#39;High&#39;, &#39;Critical&#39;]),
    impact: score(&#39;How many users does `ticket` affect?&#39;, [&#39;One&#39;, &#39;Some&#39;, &#39;Many&#39;]),
    isAngry: noul(&#39;Is the author of `ticket` frustrated?&#39;)
  }
})

Una request, cuatro decisiones, ~250 ms medidos desde mi red. Y ahora la parte que decide si esto es ingeniería o un juguete: qué haces con el confidence.

const { category, severity, impact, isAngry } = answers

// La doc sugiere estos umbrales; ajústalos con tus propios datos.
if (category.confidence < 0.5) {
  return escalarAHumano(ticket, { motivo: &#39;clasificación poco concentrada&#39; })
}

// `score` es la media ponderada sobre los índices de nivel: 0..3 con cuatro
// niveles, 0..2 con tres. Normalízalo antes de mezclar escalas distintas.
// `noul` es directamente la probabilidad de que la respuesta sea sí.
const prioridad =
  0.5 * (severity.score / 3) +
  0.3 * (impact.score / 2) +
  0.2 * (isAngry.noul > 0.7 ? 1 : 0)

// `category.choice` es la opción ganadora; `category.probabilities`, la distribución completa.
enrutar(category.choice, prioridad)

Cada respuesta llega tipada bajo el id que le pusiste en la request: un choice
trae choice, probabilities y confidence; un score trae score,
probabilities, confidence y un legend con la descripción de cada nivel; un
noul trae solo noul, la probabilidad de sí. La distribución suma 1, pero son
floats: si la compruebas en un test, hazlo con tolerancia
(Math.abs(suma - 1) < 1e-6), nunca con igualdad exacta. Y mira usage, que
llega junto a answers y model con los tokens de entrada y salida: el coste
real por decisión lo registras, no lo estimas.

El confidence mide cuán concentrada está la distribución. Por debajo de 0,5, la doc recomienda no actuar sin revisión humana. Y para acciones destructivas —borrar, reembolsar, banear— pide confirmación aunque estés por encima de 0,9.

Ese segundo umbral es el que todo el mundo se salta. Un número alto no es un permiso. Es la misma lógica de degradación controlada que aplico con los circuit breakers en agentes de IA: decidir de antemano qué pasa cuando el sistema duda.

El scoring compuesto tiene una ventaja que no es de rendimiento: es auditable. Ese 0.5 / 0.3 / 0.2 lo discutes en una PR. Un prompt que dice "decide la prioridad del ticket" no lo discutes: lo reescribes y rezas.

¿Jev o un LLM con structured output?

Esta es la comparación honesta, porque un LLM con salida estructurada ya funciona. Lo que Jev aporta no es capacidad nueva: es velocidad, coste y probabilidades que significan algo.

	Jev (System One)	LLM con structured output
Qué devuelve	decisión tipada + distribución + confidence	JSON validado contra tu schema
Texto libre, código, prosa	no, por diseño	sí
Latencia típica	~250 ms end-to-end medidos (~100 ms de inferencia)	segundos
Coste de entrada	$0,042 / millón de tokens	$0,20 – $10 / millón
Coste de salida	gratis	~5x el de entrada
Probabilidades	calibradas (RLCD)	logprobs sin calibrar, o nada
Aritmética, fechas, conteo	no fiable	mejor, aunque también frágil
Límite / riesgo	puede devolver un valor de tipo válido y completamente equivocado, con confidence alta; exige diseñar a mano el espacio de respuestas	alucina contenido dentro de un JSON perfectamente válido; coste y latencia escalan mal con el volumen

Haz la cuenta en vez de tragarte el titular. La home dice "193,6x más rápido, 444,6x más barato": con $0,042 de entrada frente a $0,20–$10, el ahorro solo en entrada va de unas 5x a unas 238x, y el 444x solo cuadra si además sumas la salida —gratis aquí, unas cinco veces la entrada allí— con un mix de tokens que no publican.

Con la velocidad pasa lo mismo. Coge mi propia apertura, dos segundos, y lo que mido de verdad, 258 ms: eso son 8x, no 193x. El 193,6x sale de workflows con muchas preguntas independientes, donde el LLM las resuelve en cadena y Jev las resuelve de una tacada. Es una comparación de arquitectura de workflow, no de modelo contra modelo.

Y ese “~100 ms” tampoco es lo que vas a medir tú. Lo he cronometrado contra la API real: 12 llamadas abriendo conexión nueva cada vez dan una mediana de 628 ms; reutilizando la conexión TLS, 258 ms, y nunca por debajo de 213. Solo el handshake TCP + TLS son 342 ms. Los 100 ms son tiempo de inferencia —ciertos, si tu código corre al lado de sus GPUs—; el resto es el viaje hasta San Francisco. Si te llevas una sola cosa de aquí que sea esta: reutiliza la conexión, son 2,4x gratis.

El propio blog de TypeSafe rebaja eso a 40x–200x para inteligencia equivalente en tareas System One, y admite que esas cifras "están en el extremo alto de las ganancias del mundo real". Midieron contra la media de GPT-6 Astra y Fable 5.1, con precios de LLM sacados de OpenRouter —lo que "casi con certeza" introduce sesgo— y desde la costa oeste de EEUU.

El número que yo me creo viene de fuera: Vercel midió el clasificador de seguridad de su modo automático de fx y le salió entre 5x y 18x más rápido en p95 con Jev que con gpt-5.6-luna, su opción anterior, y además con más acierto. Lo contaron su propio CEO y el ingeniero que hizo la prueba, y lo recogió TechCrunch. Tampoco es un árbitro imparcial —Jev viene integrado en su AI SDK, como has visto arriba—, pero al menos no vende el modelo, la carga de trabajo es real y el rango que publica es mucho más modesto que el de la home.

¿Cuándo NO conviene usar Jev?

Para esto, el hilo de Hacker News sobre el lanzamiento —más de 1.900 puntos y cerca de 500 comentarios— es más útil que la documentación oficial.

No puede escribir nada. Ni código, ni explicaciones, ni un resumen. Lo resumió un comentarista: "esto es probablemente súper útil para clasificación, routing y scoring, pero no se parece en nada a los modelos de generación de código que todos usamos hoy". El título original del post prometía un "nuevo modelo frontier" y hubo que editarlo.

No sabe contar ni hacer cuentas. Aritmética, fechas y comparaciones numéricas se quedan en tu código. No delegues un "¿han pasado más de 30 días?" a Jev; eso es un if.

El "no puede alucinar" es marketing. Lo que garantiza por diseño es que la salida es de un tipo válido: cero errores de tipo. Pero la objeción más votada del hilo lo parte por la mitad: "claro que no puede emitir un tipo inválido, pero sí puede emitir un valor válido completamente equivocado. También puedes forzar salida estructurada en un LLM". Un valor equivocado con confianza alta sigue siendo una alucinación cuando llega a tu base de datos.

Es frágil con lenguaje difuso. El ejemplo del hilo: ante "quiero que tu agente me llame mañana a las cinco", la pregunta "¿el usuario quiere hablar con un agente humano?" responde que sí y se traga entero el matiz temporal. Esa segunda dimensión tienes que haberla previsto tú. Traducido: el espacio de respuestas lo diseñas tú, a mano y con cuidado. Jev no descubre categorías, puntúa las que le das. Si tu taxonomía está mal, la salida está mal — y con confidence alta.

Piensa en inglés. La ficha del modelo lo dice sin adornos: el inglés es su idioma principal de entrenamiento y donde hoy la precisión es mejor. Otros idiomas funcionan, con menos puntería. Por eso las preguntas de los ejemplos de arriba están en inglés aunque el ticket entre en castellano: el state déjalo en el idioma que llegue, pero las preguntas, las opciones y los niveles escríbelos en inglés. Si los pones en español, mídelo antes de fiarte.

El state sucio le baja la puntería. El detalle irrelevante actúa de distractor. Manda los campos que importan, no el objeto entero que te escupe el ORM.

Solo lee texto. Nada de imágenes ni audio; imágenes, "todavía no". Y hay un techo de 255 opciones en una elección de una sola etapa — por encima toca hacer scoring en dos pasadas.

Y ojo con las demos. La de Doom impresiona hasta que ves que al modelo le pasaban el estado del juego ya estructurado —coordenadas, ángulos—, no píxeles. La de Home Assistant sí convenció a bastante gente, pero tuvieron que saltar a un modelo de Anthropic para partir peticiones con varias intenciones.

Donde sí le veo el hueco es en lo que nadie automatiza porque sale caro: deduplicar registros, casar entidades, revisar miles de filas una por una. Ahí velocidad y confianza calibrada sí cambian el juego.

Qué cambia esto si construyes agentes

Un agente es un bucle que decide muchas veces y actúa alguna. La mayoría de esas decisiones —¿consulta o queja?, ¿hace falta buscar?, ¿esto es urgente?, ¿me paro?— no necesitan prosa: necesitan un juicio rápido y honesto que hoy paga un modelo enorme escribiendo un párrafo para devolver una palabra.

A 250 ms y coste casi nulo deja de tener sentido racionar decisiones. Esa es la tesis: Jev no compite con tu LLM, compite con los if que escribiste porque llamar al LLM salía caro.

Con dos condiciones que no negocio. La primera, que midas: la viabilidad se calcula en coste por tarea resuelta, no por token, y sin evals sobre lo que genera la IA estás comparando titulares. La segunda, que las decisiones caras pasen por un contrato explícito — el método que explico en el ebook gratuito Revisión por Contrato.

Hoy mismo puedes hacer esto: coge la llamada a un LLM más tonta y repetida que tengas en producción —la que solo devuelve una etiqueta—, reescríbela como un choice con su confidence y ponle un umbral de 0,5 con salida a revisión humana. Es una tarde. Si el número no mejora, lo sabrás con datos y no con una home.

Y si quieres montar el agente entero con esta cabeza, el recorrido de idea a producto está en el curso Construye con IA.

Preguntas frecuentes

¿Jev sustituye a mi LLM?

No, y no lo pretende. Jev no escribe código, ni resúmenes, ni respuestas a un usuario. Sustituye a las llamadas de tu pipeline que solo devuelven una etiqueta, un booleano o una nota del 1 al 5. El LLM se queda para generar.

¿Qué significa exactamente que las probabilidades estén calibradas?

Que el número es verificable: de todo lo que Jev responde con un 90% de probabilidad, acierta cerca del 90% de las veces. Es lo que optimiza RLCD, frente a RLHF, que optimiza que la respuesta le guste a un humano y produce modelos que suenan igual de seguros acertando que inventando.

¿Puede alucinar Jev?

Sí, en el sentido que importa. Lo que no puede es devolver un tipo inválido: eso está garantizado por diseño, no por estadística. Pero puede devolver una opción perfectamente válida y equivocada, y hacerlo con confianza alta. Trata el confidence como una señal de enrutado, nunca como una garantía de verdad.

¿Cuánto cuesta y cuánto tarda?