Jev de TypeSafe: el modelo del que todo el mundo habla

En tres semanas guardé siete enlaces sobre Jev en mi inbox. Hilos de X, artículos largos, un repo que lo metía en Postgres, otro que lo usaba para decidir cuándo compactar el contexto de Claude Code. Todos venían a decir lo mismo: que el nuevo modelo de TypeSafe era cientos de veces más rápido y más barato que un LLM, y que no podía alucinar.

Cuando algo se vende así, me salta la alarma. Así que hice lo de siempre: leer la documentación entera, buscar quién lo había medido de verdad y probarlo yo con datos reales. En concreto, con 200 tickets de soporte reales, en español, de un producto SaaS B2B que mantenemos.

Qué es Jev (en un minuto)

Jev es el primer System One model de TypeSafe AI, y salió el 15 de septiembre de 2026. Su gracia es que no escribe. No genera texto, no razona en voz alta, no conversa. Le pasas un state (texto o JSON) y una serie de preguntas tipadas, y te devuelve respuestas tipadas con probabilidades.

Solo tiene tres tipos de pregunta:

Tipo	Pregunta	Devuelve
Choice	¿Cuál de estas opciones? (hasta 255)	La opción elegida, la probabilidad de cada una y un confidence
Score	¿Dónde cae en esta escala? (2-10 niveles)	Una posición que puede quedar entre niveles
Noul	¿Es cierto esto?	La probabilidad de que sí, de 0 a 1

Es como un examen tipo test, no uno de desarrollo. Todas las preguntas de una llamada se evalúan en paralelo sobre el mismo estado. Si el estado es grande, hacer diez preguntas cuesta casi lo mismo que hacer una, porque lo que pagas es sobre todo el estado.

Una petición tiene esta pinta (el ticket es inventado):

{
  "model": "jev-1.13.0",
  "state": {
    "subject": "No podemos facturar",
    "body": "Desde la actualización, al pulsar Emitir sale un error 500. Hoy cerramos el mes."
  },
  "questions": {
    "tipo": {
      "type": "choice",
      "instructions": "What kind of support request is this ticket?",
      "criteria": {
        "error": "Something in the software fails or behaves incorrectly",
        "change": "The customer asks for new functionality",
        "question": "The customer asks how to do something"
      }
    },
    "urgencia": {
      "type": "score",
      "instructions": "How urgent is this for the customer's business?",
      "criteria": ["Can wait", "Soon", "A core task is blocked", "The business cannot operate"]
    },
    "requiere_codigo": {
      "type": "noul",
      "instructions": "Would resolving this require changing the software's code?"
    }
  }
}

En mi prueba, una petición como esta (con cinco tipos en vez de tres) tardó 271 ms y consumió 676 tokens. A 0,042 $ por millón de tokens de entrada, con la salida gratis, sale a 0,00003 $.

TypeSafe lo vende como un if inteligente: un if que entiende lenguaje natural. Los proyectos que funcionan, los que verás más abajo, siguen la misma regla: la IA ejecuta y el código decide. El modelo grande piensa y escribe, Jev elige entre opciones cerradas y tu código decide qué hacer con lo que elige.

Quién está detrás (y una corrección)

Lo ha creado Diogo Almeida, junto a Erik Gafni y Sasha Sheng. Salieron del modo stealth con una ronda seed de 40 millones liderada por DCVC.

Diogo se presenta como cocreador de ChatGPT, y en muchos sitios leerás que inventó el RLHF. El RLHF (aprendizaje por refuerzo a partir de valoraciones humanas) es la técnica con la que se entrenó ChatGPT: personas puntúan respuestas del modelo y el modelo aprende a dar las que más gustan. Diogo no firma el paper original de esa técnica (Christiano et al., 2017). Lo que se puede comprobar es que es uno de los autores principales de InstructGPT, el trabajo que aplicó el RLHF a seguir instrucciones y del que salió ChatGPT. Él mismo matiza en la entrevista de Latent Space que no coescribió otro de los papers que se llaman RLHF.

Su tesis es que RLHF entrena a los modelos para agradar a una persona, y eso es justo lo contrario de lo que necesita el software. Por eso han entrenado Jev con lo que llaman RLCD (Reinforcement Learning for Calibrated Decisions): probabilidades que deberían significar algo, en vez de texto que suene bien. No hay paper de RLCD. Diogo lo describe más como un objetivo que como un algoritmo, y dice que el 100 % de sus datos de entrenamiento es sintético.

El nombre viene de William Stanley Jevons y su paradoja: si abaratas un recurso, se consume mucho más. Si la inteligencia cuesta un orden de magnitud menos, aparecen usos que antes no salían a cuenta.

Jev vs LLM: el 200x, comparado con lo que mide la gente

El hilo de lanzamiento en Hacker News se publicó con “40-400x cheaper and 20-200x faster” en el título. Lo cambiaron en menos de una hora.

El 193,6x y el 444,6x que aparecen en su web salen de sus propios workflow evals, y su letra pequeña dice tres cosas:

• No miden acierto. Miden acuerdo con la media de dos modelos de frontera (GPT-6 Astra y Claude Fable 5.1).
• En sus propios evals, Jev no es el más preciso en ninguno de los cuatro workflows. Saca entre un 61,7 % y un 76 %, frente al 66,2-79,1 % del mejor. En facturas queda 17 puntos por debajo.
• Ellos mismos dicen que esas cifras están “en el extremo alto” de lo que verás en la vida real.

Donde arrasa es en coste y latencia: entre 0,0001 y 0,0011 $ por caso y 0,3-0,5 s, frente a los 10-40 s de los LLM más precisos en cada workflow.

Luego busqué quién lo había medido por su cuenta, sin TypeSafe de por medio. Encontré una treintena de pruebas, y estas son las que más me han servido:

Quién	Tarea	Jev	Comparación
Sebastian Raschka	Sentimiento (IMDb, 25.000 reseñas)	96,5 %	Similar a un ModernBERT afinado
Red Hat	Toxicidad	86,2 % (1.º)	Qwen3.6-35B: 85,5 %
Red Hat	Prompt injection	86,4 %	Un deberta de 200M saca 89 % en 54 ms
distil labs	Reglas de facturas con aritmética	79 %	Un Qwen de 4B que razona: 98 %
Ibrahim y Zaki	18 tareas de ciencias sociales	−11,6 F1 de mediana frente al mejor LLM	44 veces más barato

En toxicidad, Jev quedó primero en la prueba de Red Hat, pero solo 0,7 puntos por delante del segundo. Y la conclusión del propio artículo de Red Hat es que los modelos como Jev no superan de forma fiable a los clasificadores de toda la vida ni a usar un LLM como juez.

Con estos datos, la precisión de Jev es la de un LLM de gama media, no la de uno de frontera. Clasifica muy bien lo que se lee directamente en el texto: sentimiento, spam, temas, intenciones, toxicidad. Falla en lo que exige calcular, cruzar documentos o captar matices finos.

En velocidad y coste, la ventaja depende de contra qué lo compares. Frente a un LLM de frontera con razonamiento es enorme. Frente a un clasificador pequeño, un modelo local o un LLM barato sin razonamiento, se reduce mucho o desaparece: el deberta de Red Hat responde en 54 ms.

Donde se ahorra de verdad es cuando un agente toma muchas decisiones cerradas por tarea. Piensa en un agente que procesa un ticket: lee la queja, decide quién lo lleva, si es urgente, si está resuelto y si hace falta una persona. Solo la primera tarea necesita lenguaje. Si sacas las otras cuatro del LLM, no haces una llamada más rápida: quitas cuatro llamadas caras por ticket.

La promesa central: las probabilidades

Para automatizar no basta con la etiqueta: necesitas saber cuánto fiarte de ella. Si el 0,95 de Jev significa “acierto el 95 % de las veces”, puedes automatizar por encima de un umbral y mandar el resto a una persona. Eso se cumple solo en parte.

Donde se sostiene: en clasificación en inglés de cosas que el modelo conoce, el error de calibración (ECE) está entre 0,03 y 0,07. Es bueno.

Donde no: John Berryman, de Arcturus Labs, le hizo una prueba muy simple. Le dijo que una moneda sale cara el 60 % de las veces y le preguntó por la siguiente tirada de dos formas:

• Con Noul (“¿saldrá cara?”): 0,58. Casi perfecto.
• Con Choice (cara o cruz): 0,99 para cara.

Kanta Hayashi lo llevó más lejos con un dado justo: en 400 tiradas, Choice eligió siempre la cara 1, con un 82,9 % de probabilidad media. Acertó el 19 % (por azar habría acertado el 16,7 %).

Así que Choice responde a “¿cuál es la más probable?”, no a “¿qué probabilidad tiene cada una?”. Noul se acerca más a una probabilidad real, aunque tampoco es perfecto: se aplana en los extremos.

El campo confidence tampoco es la probabilidad de acertar. Es una reescala de la probabilidad máxima entre las $n$ opciones:

$$\text{confidence} = \dfrac{p_{\max} - \dfrac{1}{n}}{1 - \dfrac{1}{n}}$$

Añade opciones absurdas y verás cómo sube.

Casi todas las fuentes recomiendan lo mismo: recalibrar con 50-300 ejemplos etiquetados tuyos. La calibración depende de tu distribución de datos: ningún modelo puede venir calibrado de fábrica para ti.

¿Y Jev en español?

TypeSafe solo dice que el inglés es su idioma principal y que el resto “funciona, pero no igual de bien”. La medición más completa que encontré es jev-acento: 3.200 ítems emparejados en inglés y en español. Su propio README avisa de que el protocolo aún no está cerrado. Tómalo como orientación:

• Pérdida de precisión: entre 3 y 6,4 puntos, según la tarea. Es mayor en inferencia y paráfrasis, y menor en intenciones y comprensión lectora.
• Calibración: el error casi se duplica en las tareas de inferencia.
• Coste: el texto en español gasta entre un 17 % y un 38 % más de tokens. Ya conté por qué el español sale más caro.
• Idioma de las instrucciones: escribirlas en español o en inglés apenas cambia nada.

Eso son benchmarks. Yo quería ver qué pasa con tickets de verdad.

Mi prueba: 200 tickets reales de soporte

Cogí 200 incidencias de soporte de 2025 y 2026: 35 que habían acabado en un pull request y 165 al azar.

No mandé datos personales a TypeSafe. Jev está alojado en Estados Unidos y la retención cero de datos solo existe en el plan enterprise. Así que anonimicé todo en local (nombres de personas y empresas, teléfonos, direcciones, firmas y avisos legales) y después revisamos los textos uno a uno. Los ejemplos de este artículo son inventados.

Le hice a Jev tres preguntas por ticket (tipo, urgencia y “¿requiere tocar código?”) en cuatro variantes: criterios en inglés, bilingües, todo en español y con las opciones en orden inverso. En total, 800 llamadas.

Primero lo comparé con otro LLM. Etiqueté los 200 tickets con Claude Opus 5.5 leyendo el mismo texto:

Variante	Acuerdo con Opus en el tipo	En los casos claros (143)	p50 desde España
Criterios en inglés	85,0 %	93,0 %	250 ms
Criterios bilingües	87,0 %	94,4 %	262 ms
Todo en español	84,5 %	92,3 %	237 ms

En la variante en inglés, con probabilidad ≥ 0,99, Jev decidió solo el 44 % de los tickets (88 de 200) con un 100 % de acuerdo. Invertir el orden de las opciones cambió el resultado en 8 de 200 tickets. Las 800 llamadas costaron 0,027 $.

Después lo comparé con la realidad. Descargué las respuestas que dio el equipo de soporte a cada ticket y miré cómo se resolvió de verdad: si hubo que tocar código, si soporte cambió datos o configuración, o si bastó con explicar algo. Quedaron 181 tickets con una resolución clara.

Quién	Ruta correcta	”¿Requiere código?”
Claude Opus 5.5	65,2 %	79,0 %
Jev (bilingüe)	63,0 %	80,1 % (AUROC 0,855)

Los dos se quedan en torno al 63-65 % en la ruta, y fallan en el mismo sitio. De los 79 tickets que Jev clasificó como error o cambio (es decir, los que mandaba a desarrollo), 37 no necesitaron tocar código: soporte los resolvió explicando algo (la caché del navegador, un error de uso, un malentendido) o cambiando un dato. Opus cayó en lo mismo.

La pregunta “¿requiere código?” va aparte, y ahí el resultado depende mucho del umbral. Con 0,5, Jev acierta el 70 % de lo que marca, pero se deja el 43 % de los tickets que sí eran de código. Con 0,3 recupera el 81 % a cambio de más falsas alarmas. Si el error caro es perder un bug, baja el umbral.

De aquí saco dos conclusiones:

1. Jev rinde casi igual que un LLM de frontera leyendo el mismo texto, por mucho menos.
2. Ninguno de los dos puede adivinar lo que no está escrito en el ticket. Automatiza el enrutado y deja que una persona confirme. No intentes automatizar la resolución.

Y una tercera: con pocos tickets al día, automatizar el triaje no compensa. Para ese volumen, a una persona le basta un vistazo. Jev tiene sentido cuando hay miles de decisiones.

Lo que ya está construyendo la gente

Revisé unos 110 proyectos entre repos, catálogos y posts. Muchos son demos de un día. Me quedo con los que tienen números o una idea reutilizable:

• Unblocked usa Jev para elegir qué memorias inyectar en el prompt de su agente. Lo midió sobre 12.927 pares, con un LLM como juez ciego: la precisión de las notas inyectadas pasó del 34,8 % al 46,4 % frente a su cross-encoder. Puntuar una nota por llamada perdía; ver 20 a la vez ganaba. Y un día ajustando el prompt (nueve variantes) no movió nada, mientras que mover el umbral sí.
• Polylane sustituyó cinco decisiones de su agente de guardia (responder o no, severidad, incidentes relacionados…) que antes hacían LLMs baratos. El P90 bajó de 4,7 s a 0,5 s y el coste, un 39 %. No publican precisión, y la ganancia grande fue la latencia.
• WindTunnel puso a Jev a elegir herramientas WebMCP de una página. Resolvió 49 de 49 tareas. Haciendo clics en el DOM, 25 de 49. Las tareas eran las mismas: con WebMCP, Jev elegía entre unas pocas herramientas con nombre, y en el DOM, entre cientos de elementos.
• Browser Use encontró un vuelo Zúrich-Londres en 7 s por 0,0039 $. El código construye la tabla de elementos de la página y Jev elige cuál pulsar. Un LLM pequeño solo entra cuando hay que escribir algo.

También hay mucho ruido. El bot de trading de Jarrod Watts corre en público con un modelo simulado. Y el de Polymarket que “convirtió 148 $ en 276.000 $” no tiene ni una prueba.

Jev en tu harness de código

Un agente de código toma decenas de decisiones pequeñas por sesión, y casi todas se pagan a precio de Opus: ¿este comando es peligroso?, ¿he terminado de verdad?, ¿qué fichero leo?, ¿compacto ya? Es terreno de harness engineering.

En el harness que usamos en la empresa, Jev ya responde en modo sombra. Tenemos un “juez” que decide si un cambio es pequeño o necesita el proceso completo. Siempre decide una heurística determinista, y Jev responde a la misma pregunta. Cada respuesta queda registrada junto a la de la heurística, así que sabemos cuántas veces coinciden. Si Jev falla o tarda más de 3 segundos, se descarta y el flujo sigue igual.

Lo que funciona

• Guardián del “hecho” (jev-belay, pi-warden). Es un Stop hook que detecta cuándo el agente dice “listo” sin haber verificado nada. jev-belay saca un AUROC de 0,976 sobre 100 cierres que etiquetó su autor, de los que 12 eran “hecho” falsos. Cuesta 346 ms y 0,00005 $ por llamada. pi-warden tiene la mejor telemetría: en 1.168 sesiones reales, el 76 % de los “hecho” falsos acabaron en una ejecución de tests.
• No preguntar si no cambia nada. El ask gate de pi-warden decide en código cuándo ninguna respuesta de Jev cambiaría la acción, y entonces no llama. Ahorra el 48,9 % de las peticiones y conserva el 96,7 % de las decisiones útiles.
• Comprobar tus reglas (Abide). Revisa cada edición contra tu CLAUDE.md. Me gusta porque publica sus falsos positivos: de 39 ediciones marcadas, un revisor independiente solo confirmó 10. Por turno, 11 de 15.
• Buscar mejor (Oko, jevgrep). Búsqueda local y Jev para reordenar candidatos. Con Oko, Claude Code tardó un 31 % menos. La primera versión ahorraba tokens y no tiempo, porque el agente seguía verificando con grep, y lo arregló una línea en el CLAUDE.md.
• Filtrar la salida antes de que entre al contexto (jev-pruner, winnow). Quitan lo que sobra de lo que devuelven Bash o Read antes de que llegue al modelo, así que no tocan la caché.
• Elegir qué tests ejecutar (jgrep). Con el 12 % de los ficheros de test cubre el 93 % de los tests que tocó el autor, en 60 commits de cinco repos.

Lo que no funciona

• Sugerir skills. jev-skill-router hizo 539 sugerencias y el agente siguió 28 (~5 %). El autor lo retiró. Claude Code ya ve todas las descripciones y no necesita un intermediario.
• Compactar reescribiendo la historia. La compactación con Jev se hizo viral (de casi un millón de tokens a 86.000 en un segundo), pero, como señaló Theo Browne, reescribir el historial invalida la caché de prompts. En sesiones largas, la caché pesa mucho en la factura. Mejor filtrar a la entrada que reescribir después.

Cómo lo diseñaría yo

Estas son las reglas que se repiten en lo que funciona:

1. El código prepara las opciones y Jev elige. Nunca le pidas que invente, y añade siempre una opción none u other.
2. Pon un Noul de “¿existe respuesta?” junto a cada Choice. Las probabilidades de un Choice siempre suman 1: siempre habrá un ganador, aunque ninguno valga.
3. Muchas preguntas por llamada, pocas filas por estado. Diez preguntas sobre el mismo diff, bien. Pero si metes 40 filas en el mismo estado para ordenarlas, el ranking se rompe: la correlación de Spearman cae de 0,93 a 0,58.
4. Calcula en código. Jev no cuenta ni suma, y su documentación desaconseja usarlo para comparar fechas. Pásale “3 o más tests fallidos”, no la salida cruda.
5. Calcula el umbral con tus datos. Es lo que encontraron Unblocked y casi todos los que lo han medido.
6. Elegir no es autorizar. Que Jev diga “este comando es seguro” no te da permiso para ejecutarlo. Tu código revalida.

Nuestro harness tiene además un Stop hook. Al cerrar un turno con ediciones, pasa el formateo y el linter, y le hace a Jev la pregunta de jev-belay: ¿dice que ha terminado sin haberlo verificado? Va por el mismo juez y también en modo sombra. Nunca bloquea el turno.

Junto a esa pregunta van las comprobaciones que exijo antes de dar una tarea por cerrada. ¿Pegó la salida real de los tests? ¿Cambió un constructor sin actualizar sus llamadas? ¿La migración es idempotente? Son cuatro Noul en una sola llamada, sobre los ficheros editados, los tests que ejecutó y el final de su último mensaje. Ese estado tiene un tamaño máximo y se limpia de secretos antes de salir de la máquina.

Hay una quinta comprobación: ¿va un .env en el commit? Esa no llega a Jev. La decide el código, porque un grep no se equivoca y porque no tiene sentido mandar fuera justo lo que intentas proteger.

Lo que no te cuentan

• “No puede alucinar” solo significa que no rompe el esquema. Puede elegir la opción válida equivocada con un 0,94 de confianza: en una prueba independiente clasificó una receta de tarta como incidencia técnica. Diogo lo admite: “¿dirías que un clasificador lineal alucina?”.
• Su propia página de límites enumera dónde falla: lectura literal, no calcula, no compara fechas, le cuesta la indirección, la inyección en el estado mueve la respuesta y tiene sesgo hacia la primera opción. No es habitual que un lanzamiento lo publique.
• No es determinista. Archestra repitió las mismas peticiones: la etiqueta salió igual en 394-398 de 400 casos, pero solo el 35-39 % de las probabilidades fueron idénticas.
• RGPD:
  • Alojado en EE. UU., con cláusulas contractuales tipo.
  • El DPA no fija un plazo de retención y la retención cero solo existe en enterprise.
  • El contrato permite derivar telemetría “in perpetuity”, y esa telemetría incluye “classifications”.
  • Prohíbe usar las salidas para entrenar un modelo que lo imite.

Si tus datos son sensibles, anonimiza antes o usa una alternativa local.

OpenAI ya ha movido ficha: la Decisions API y las alternativas

Dos semanas después del lanzamiento, en el DevDay del 29 de septiembre, OpenAI anunció su Decisions API: la misma idea, sobre GPT-6 Luna y con soporte de imágenes. A 2 de octubre seguía en preview limitada, sin precio ni documentación, y los “~150 ms” del anuncio salen de un vídeo acelerado 15 veces.

También hay alternativas abiertas que hablan el mismo formato (/v1/systemone):

• Kev (Apache-2.0): la réplica más seria, de 0,8B a 27B parámetros. En inglés.
• Laya: más de 100 idiomas y corre en CPU, pero sin afinar acierta por debajo de lo que sacarías eligiendo siempre la clase más frecuente. Sirve como base para entrenar con tus datos, no como sustituto.
• Ollama 0.35+, llama.cpp y SGLang (en nightly) ya sirven /v1/systemone en local.

Mi consejo: abstrae la capa de decisión tras /v1/systemone. Entre proveedores compatibles, cambiar de uno a otro pasa a ser cambiar un base_url. OpenAI, de momento, no es uno de ellos.

¿Cuándo no usaría Jev?

• Si los datos no pueden salir de la UE.
• Si tienes más de 500 ejemplos etiquetados y etiquetas estables: un clasificador afinado será más preciso y lo controlas tú.
• Si necesitas imágenes.
• Si la decisión pasa cinco veces al día.

Conclusión

Jev no inventa nada desde cero. Clasificadores zero-shot hay desde hace años, y en NobodyWho lo parodiaron en “25 líneas de Python” leyendo logprobs. Esa versión casera ni está calibrada ni aguanta que cambies el orden de las opciones. Lo nuevo es que Jev funciona lo bastante bien en tareas muy distintas, por casi nada y en un cuarto de segundo. Como dice Raschka, no desbloquea capacidades nuevas, pero sube muchísimo el listón para justificar un clasificador propio.

Lo que me llevo no depende de TypeSafe: separo las decisiones cerradas del resto y dejo la última palabra a mi código. En el JevBench del 5 de octubre ya hay modelos abiertos que puntúan por encima de Jev, así que el proveedor puede cambiar pronto. Si mañana me paso a otro compatible, solo toco el base_url.

Antes de elegir modelo, mira si la respuesta está en los datos que le vas a pasar. En mis tickets, 37 de los 79 que Jev mandaba a desarrollo se resolvieron sin tocar código, y ni Jev ni Opus podían verlo en el texto.

---

P.D.: Mi próximo experimento con Jev es en voz: un callbot que entiende la intención y la frustración del cliente mientras habla, en español. Saldrá en vídeo en el canal. Si estás probando Jev con datos en español, me encuentras en Twitter como @lm_martinbar. Cuéntame qué has implementado o vas a implementar con Jev.