System One y Jev: la IA que decide sin escribir

TypeSafe ha lanzado un modelo que no sabe escribir. Ni una palabra.

No genera texto, no escribe código, no mantiene una conversación y no tiene interfaz de chat. Le pasas un estado y una lista de preguntas tipadas, y te devuelve probabilidades. Se llama Jev, y TypeSafe sostiene que inaugura una clase nueva de modelos: los System One Models.

El titular del anuncio es «193 veces más rápido, 444 veces más barato». Ese titular es lo menos interesante de todo esto.

Lo interesante es dónde te deja colocar la inteligencia.

En este artículo vas a encontrar:

• Qué es un System One Model y por qué TypeSafe insiste en que Jev no es un LLM
• Los tres tipos de decisión que acepta (Choice, Score y Noul) y cómo se le pregunta
• Qué cifras están verificadas, cuáles son afirmaciones de la casa y cuáles no ha demostrado nadie todavía
• Lo que pasó cuando dos equipos independientes lo metieron en producción y midieron
• Dónde tiene sentido meterlo en tu harness y dónde te va a empeorar el sistema

¿Qué es un System One Model y en qué se diferencia de un LLM? ¶

Un System One Model es un modelo que renuncia por completo a generar texto y devuelve decisiones tipadas con probabilidades. El nombre viene del System 1 de Kahneman, ese juicio rápido e intuitivo que emites sin deliberar.

Ojo con el nombre, porque importa: «System One Model» es nomenclatura creada por TypeSafe, no una categoría establecida de investigación como «LLM», «VLM» o «modelo de difusión». Es marketing técnico hasta que la comunidad lo adopte o lo tire a la basura.

El nombre del modelo sí que es una declaración de intenciones. Jev viene de William Stanley Jevons, el economista de la paradoja que lleva su apellido: cuando la máquina de vapor se volvió más eficiente, no se consumió menos carbón, se consumió muchísimo más. TypeSafe lo dice sin rodeos en su FAQ: esperan que cada orden de magnitud que baja el coste de la inteligencia desbloquee órdenes de magnitud más de casos de uso.

Han bautizado el modelo con su propia tesis. Guárdate eso, porque es la clave de todo el artículo.

La diferencia se ve mejor con los dos caminos uno al lado del otro:

Ellos lo resumen en una frase: unstructured state in, typed probabilistic decisions out. Estado sin estructura entra, decisiones tipadas y probabilísticas salen.

Parece un cambio pequeño. No lo es. Cambia la arquitectura del software que rodea al modelo, y ese es el punto que se pierde debajo de las cifras del anuncio.

🔑 Jev no compite con Claude ni con GPT por escribir mejor. Compite con el if de tu código en los sitios donde no sabes escribir el if.

TypeSafe salió del anonimato con Jev y una ronda seed de 40 millones de dólares liderada por DCVC. El fundador es Diogo Almeida, ex-OpenAI y coinventor del RLHF y de InstructGPT, la línea de investigación que acabó siendo ChatGPT.

No es un proyecto de garaje. Dos años en stealth para sacar un modelo que se niega a hablar.

¿Cómo se le pregunta a Jev? Choice, Score y Noul ¶

Jev acepta tres tipos de pregunta, y ninguno admite texto libre como respuesta. Esa es toda la API.

El Noul es un Bernoulli con nombre propio. Un 0,9 significa 90% de probabilidad de que sea cierto, y ya está.

La entrada es texto: strings, JSON, arrays de texto. No hay imágenes, no hay audio. El presupuesto de contexto ronda los 32.000 tokens, unos 150.000 caracteres en inglés, y una pregunta de tipo Choice admite hasta 255 opciones a la vez.

Así se ve con el SDK de Python:

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

# Un solo estado, varias preguntas independientes en la misma llamada
response = client.system_one(
    state="Llevo tres días sin poder pagar la suscripción y nadie me contesta.",
    questions={
        # Enruta el ticket a un departamento de una lista cerrada
        "departamento": Choice(["facturacion", "tecnico", "cuenta"]),
        # Puntúa la urgencia contra niveles descritos en lenguaje natural
        "urgencia": Score(["puede esperar", "normal", "urgente", "crítico"]),
        # Pregunta binaria: ¿hace falta una persona?
        "necesita_humano": Noul("¿Este caso requiere intervención humana?"),
    },
)

Se instala con pip install typesafe-sdk, la clave va en TYPESAFE_API_KEY y hay SDK equivalente para TypeScript. También hay un playground web una vez te dan acceso.

Fíjate en lo que no hay en ese bloque: ni un json.loads, ni un try/except de parseo, ni un esquema de validación, ni un reintento por si el modelo devuelve markdown alrededor del JSON. Ese código no existe porque no puede fallar por ahí.

¿Por qué Jev es tan rápido si no hace magia? ¶

Porque no escribe la respuesta, la evalúa.

Un LLM tradicional, aunque le obligues a cumplir un JSON Schema, sigue siendo un modelo generativo haciendo decoding autoregresivo. Tiene que producir esto token a token:

{
  "departamento": "facturacion",
  "urgencia": "urgente"
}

Las comillas, las llaves, los dos puntos. Todo.

Jev no escribe la palabra facturacion. Tu programa ya le ha dicho que solo existen facturacion, tecnico y cuenta. El modelo evalúa esas alternativas y devuelve la distribución.

Su fundador tiene además un argumento sobre el decoding restringido que merece la pena escuchar aunque no compres el resto: forzar el esquema enmascarando logits vuelve al modelo más tonto, porque si alguna vez estaba asignando probabilidad a un token inválido es que estaba confundido, y taparlo no lo arregla. En su opinión sería mejor que el sistema fallara con un error que fingir que la salida es buena.

TypeSafe dice haber cambiado tres piezas: una arquitectura nueva, un parallel sampler que genera todas las salidas en una sola pasada en lugar de hacerlo token a token, y un método de entrenamiento llamado RLCD (Reinforcement Learning for Calibrated Decisions).

La idea del RLCD es la que más me interesa. Donde el RLHF optimiza por la respuesta que un humano prefiere y el RLVR por la salida que un programa puede verificar, el RLCD pretende optimizar por probabilidades honestas: un modelo que dice estar seguro al 70% debería acertar el 70% de las veces.

Y ahora el problema gordo. TypeSafe no ha publicado la arquitectura. En Hacker News se lo preguntaron a bocajarro —¿es un transformer con una cabeza discriminativa? ¿difusión?— y la respuesta fue que la mantienen «close to the chest» por ahora, con un paper como posibilidad futura.

⚠️ Desconfía de cualquier artículo que hoy te explique con seguridad cómo funciona Jev por dentro. No sabemos si es encoder-only, qué tamaño tiene, cómo implementa el sampler ni qué comparte entre preguntas.

Lo que sí sabemos es lo que el propio fundador concedió en ese hilo. Cuando un comentarista lo describió como un clasificador zero-shot generalizado, la respuesta fue «exactly right!». También aclaró que ellos no lo consideran un modelo de lenguaje porque no genera lenguaje.

Ese es el modelo mental correcto hoy: un clasificador y regresor semántico generalista, zero-shot, de mucha capacidad y programable en lenguaje natural.

Que no suene a poco. Juntar todas esas propiedades a la vez es justo lo difícil.

¿Qué cuesta Jev y qué límites tiene ahora mismo? ¶

Cuesta 0,042 dólares por millón de tokens de entrada. Los tokens de salida son gratis, porque técnicamente no hay salida que cobrar: unas cuantas probabilidades no son tokens generados.

La latencia extremo a extremo que publica TypeSafe va de 70 a 500 milisegundos.

Las limitaciones de hoy son gordas y conviene tenerlas delante antes de emocionarse:

• Solo entrada de texto y JSON. Ni imágenes ni audio
• Presupuesto de contexto de unos 32.000 tokens por petición
• Máximo 255 opciones por pregunta de tipo Choice
• No genera texto, no escribe código, no mantiene conversación

La demo con la que salieron a la calle es Doom. Jev juega a Doom reaccionando al estado del juego —en texto estructurado, no capturas de pantalla— unas 10 veces por segundo, a unos 7 dólares la hora de inferencia. La cifra contra la que comparan es la suya propia: entre 3 y 329 segundos de respuesta extremo a extremo en los modelos frontier, que para un bucle en tiempo real no es una opción.

Y aquí TypeSafe hace algo que le honra: reconoce que un bot clásico sin IA jugaría mejor. El objetivo de la demo no es que juegue bien, es demostrar que puede decidir dentro de un bucle en tiempo real donde una llamada a un LLM que tarda segundos no tiene ningún sentido.

Guía interactiva gratis

Separar el modelo del arnés, que es de donde sale todo esto

La tercera parada del curso pone modelos y agentes en dos columnas distintas, y la cuarta mete el presupuesto en la conversación. Es el mapa que necesitas antes de decidir qué pieza toma cada decisión.

Entra en el curso gratis →

¿Qué cifras te puedes creer y cuáles no? ¶

Esta es la tabla que me habría gustado encontrar el primer día, separando lo que está verificado de lo que es una afirmación de parte.

El detalle de los evals merece un párrafo propio porque es donde se cae media narrativa.

El panel público de TypeSafe publica cuatro workflows completos, con sus trazas y sus desacuerdos. Suena serio. Lo es. Pero las etiquetas de referencia se generan promediando las respuestas de GPT-6 Astra y Claude Fable 5.1, ambos en modo de razonamiento alto.

Léelo otra vez. La «respuesta correcta» de ese eval la definen dos modelos de OpenAI y Anthropic.

Eso significa que la puntuación mide cuánto se parece Jev a dos LLMs frontier, no cuántas veces acierta. TypeSafe lo dice en sus propios documentos, sin esconderlo, y esa honestidad vale mucho. Pero no convierte el número en lo que parece.

Por si fuera poco, en «Lies, Damned Lies, and Benchmarks» defienden que no piensan publicar tablas de benchmarks estándar: sus evals serán instantáneas fechadas que se retiran en vez de escalarse, y publicarán también la evidencia que les deja mal.

Es una postura coherente. Y tiene un efecto práctico incómodo: hoy no existe un benchmark externo estándar con el que decir que Jev tiene tal nivel de inteligencia.

¿Es verdad que Jev no alucina? ¶

No. Y a la vez sí, según qué entiendas por alucinar.

Supón que le pides esto:

Choice(["Madrid", "Barcelona", "Valladolid"])

Y la respuesta correcta es Valladolid, pero Jev te devuelve:

Madrid       0.82
Valladolid   0.11
Barcelona    0.07

Jev no ha violado el tipo. No se ha inventado «Zaragoza», no ha devuelto un JSON roto, no ha llamado a una herramienta que no existe.

Se ha equivocado igual.

Hay un detalle del anuncio que no deberías pasar por alto. En el gráfico donde comparan tasas de alucinación, TypeSafe pone a Jev un 0% y aclara en la letra pequeña que ese número no es empírico: lo deducen de que el esquema está garantizado, así que se lo asignan. Las cifras de los LLM con las que se comparan, en cambio, salen de datos de OpenRouter, donde las consultas más complejas tienden a enrutarse a modelos mejores. Son dos cosas que no se miden igual puestas en la misma barra.

Esta fue la crítica principal en Hacker News, y se repitió en decenas de comentarios: type safety y corrección factual son propiedades distintas. Una elección errónea no es un error de tipo, pero un error con confianza alta sigue teniendo consecuencias operativas.

Yo reformularía la afirmación de TypeSafe así:

🔑 Jev elimina las alucinaciones estructurales, no los errores semánticos.

Sigue siendo valioso. En una cadena de veinte decisiones automáticas, que nunca aparezca un JSON inválido, una herramienta inexistente o un enum inventado te ahorra una clase entera de incidentes. Pero no convierte los juicios en correctos, y el marketing de «zero hallucinations» se pasa varios pueblos.

La recomendación práctica es la aburrida de siempre: comprueba con tus propias etiquetas, pon umbrales conservadores, mantén la vía de escalado a un humano y mide lo que te cuesta una decisión equivocada.

¿Qué pasó al meter Jev en un agente de código de verdad? ¶

Esta ha sido la fuente externa más útil de todas, y lo es precisamente porque no sale todo bien.

El equipo de Empryo integró Jev en su harness de agente de programación. Probaron ocho usos posibles y se quedaron con cinco: selección de skills, reranking de búsqueda, clasificación de errores, aprobación de acciones y computer use. Los otros tres los tiraron después de medirlos.

Donde brilló fue en clasificación de errores. Sobre 102 fallos reales de proveedores de modelos sacados de logs de sesión, con la respuesta correcta fijada por la documentación oficial de cada API, Jev acertó los 102 en una mediana de 273 milisegundos y unas dos cienmilésimas de dólar por comprobación. Un modelo frontier de razonamiento también acertó los 102, pero tardando alrededor de 1.387 milisegundos: cinco veces más latencia por el mismo resultado.

Ahí Jev gana sin discusión. Misma precisión, una quinta parte del tiempo, una fracción ridícula del coste.

Donde falló fue en reordenar resultados de grep. Replicando 220 búsquedas reales, el fichero que la sesión acababa leyendo estaba entre los tres primeros el 78,6% de las veces con el orden nativo de la herramienta, y solo el 74,1% con el orden de Jev.

Jev empeoró el sistema. Ese uso se descartó.

Los otros dos descartes van en la misma línea. Decidiendo si una revisión había pasado o fallado, coincidió con el criterio humano en 12 de 20 casos ambiguos. Y prediciendo la siguiente llamada a herramienta, una heurística tonta por palabras clave llegó al 26% frente al 15% de Jev.

De ahí sale la mejor regla de uso que he leído sobre este modelo:

💡 Si el problema ya tiene una señal determinista buena, no metas Jev. Vas a pagar latencia y coste para empeorar el resultado.

TypeSafe dice casi lo mismo en su documentación: código para reglas, control de flujo y efectos secundarios; System One solo en los puntos donde necesitas juicio semántico sobre datos sin estructura. Te lo están diciendo ellos. Hazles caso.

¿Y qué encontró la prueba independiente de Every? ¶

Mike Taylor, responsable de evals en Every, cogió 37 documentos y lanzó 21 preguntas sobre cada uno. Son 777 juicios, y Jev los devolvió todos en menos de 0,7 segundos por un cuarto de céntimo de dólar.

Esa cifra es una señal externa fuerte, y no de inteligencia sino de economía: hacer centenares de juicios semánticos pequeños deja de ser caro. Aun así, Taylor avisa de que no llevaría esos resultados a producción sin una evaluación de precisión más seria.

Ahí es donde yo me quedo también. La tesis de «tenemos inteligencia frontier 200 veces más barata» no está demostrada. La tesis de «podemos ejecutar cantidades absurdas de juicios semánticos razonablemente buenos con latencia y coste ridículos» empieza a estarlo.

La segunda ya sería importante de por sí.

¿Qué es la calibración y por qué es la pieza que más vigilaría? ¶

Para automatizar, la calibración puede importarte más que la precisión bruta.

Una probabilidad calibrada significa que, de mil decisiones emitidas con un 90% de confianza, unas novecientas deberían ser correctas. Si eso se cumple, puedes escribir esto y que signifique algo:

# Los umbrales solo tienen sentido operativo si las probabilidades están calibradas
if p > 0.98:
    ejecutar()
elif p > 0.75:
    enviar_a_verificacion()
else:
    escalar_a_humano()

Si las probabilidades no están calibradas, ese bloque es superstición con sintaxis.

TypeSafe deja claro en su documentación que la calibración es estadística y no garantiza que una predicción concreta sea cierta, y recomienda medir confianza contra precisión en tus propios datos antes de fijar umbrales. Correcto por su parte.

También han publicado experimentos de autoconsistencia: repiten una rúbrica de 14 decisiones quince veces sobre el mismo caso y miden cuánto se mueve cada respuesta. La desviación típica media por pregunta les sale de 0,0102, por debajo de todas las condiciones de LLM con las que comparan.

Es un dato bonito. Y es un dato que mucha gente va a leer mal, así que subrayo la diferencia:

⚠️ Autoconsistencia no es calibración. Que siempre contestes 0,87 a la misma pregunta no prueba que las cosas a las que asignas 0,87 sean ciertas el 87% de las veces. Prueba que eres estable, no que aciertas.

No he encontrado curvas de fiabilidad, puntuaciones de Brier, ECE ni ninguna evaluación amplia e independiente del RLCD. Esa es hoy la mayor incógnita científica de Jev, y es la que decide si toda la propuesta se sostiene o se queda en un clasificador rápido más.

¿Cómo cambia esto la arquitectura de tu harness? ¶

Esta es la parte que me tiene dándole vueltas, y no tiene nada que ver con los 100 milisegundos.

TypeSafe publicó un cookbook que parece escrito a medida de cualquiera que lleve tiempo peleándose con la orquestación de Agent Skills. Usaron Jev para elegir qué skill debe cargar un agente de entre 182 skills, en una sola petición y con una opción explícita de «ninguna sirve».

No meten las 182 skills completas en el contexto. Jev hace una pasada barata sobre todo el catálogo y produce un ranking más una señal de si de verdad hace falta cargar algo. Después el agente lee en detalle solo las tres mejores. Es progressive disclosure dirigida por un modelo barato.

Los resultados sobre el conjunto de peticiones que midieron:

Unas 2,3 veces menos cargas erróneas con 182 skills sobre la mesa. Y el dato honesto que también publican: Jev arregló 37 casos que el agente tenía mal, pero rompió 7 que el agente tenía bien.

Me parece un resultado muchísimo más interesante que la demo de Doom, porque enseña una arquitectura concreta:

                       ┌─ reglas deterministas
                       │
petición → Jev/router ─┼─ skill A
                       ├─ skill B
                       ├─ modelo barato
                       ├─ modelo razonador
                       └─ humano

Jev no sustituye al agente. Jev gobierna partes del harness que hoy estamos resolviendo con el propio agente.

La demo con Home Assistant que enseñaron lo deja todavía más claro: cuando llega una petición con varias intenciones mezcladas, el sistema sigue tirando de un modelo de Anthropic para partirla en dos órdenes discretas, y solo después entra Jev. Ellos mismos enseñan a Jev delegando.

Construye agentes con criterio

Los seis niveles donde decides qué pieza hace cada cosa

Vas a recorrer la arquitectura completa de un agente, de las tools a la orquestación, con la capa de evals y LLM as Judge que es justo donde encajaría un modelo de decisiones como este.

Ver la arquitectura entera →

6 niveles de arquitectura, en directo

¿Dónde meterías Jev en tu harness y dónde no? ¶

Piensa en la cantidad de decisiones triviales que hoy le pides al modelo más caro que tienes: decidir si buscar, elegir qué skill cargar, valorar si dos resultados son relevantes, decidir si reintentar, juzgar si hace falta una revisión, filtrar resultados de RAG, comprobar una cita, detectar una acción destructiva, elegir entre herramientas, verificar una precondición.

Son miles de microdecisiones, y tu modelo principal acaba haciendo de planificador, generador, router, clasificador, crítico, verificador y selector de herramientas al mismo tiempo.

Eso es exactamente lo que discutimos al hablar de qué es un AI harness: el modelo es la pieza pequeña, el arnés es donde está el trabajo.

Jev sugiere otro reparto: código determinista para las reglas, miles de microjuicios baratos para lo que necesita criterio, y el LLM reservado para donde de verdad hay que pensar o generar algo nuevo.

Y hay una consecuencia bastante profunda para la verificación. La verificación determinista sigue siendo la de siempre: tests, tipos, lint, esquemas, compilador, análisis estático, invariantes. Para lo que necesita juicio semántico solemos tirar de LLM-as-a-judge o de un agente crítico, que es lento y caro.

Jev permite meter una tercera capa mucho más ligera entre medias. Afirmaciones semánticas lanzadas en paralelo sobre el mismo estado:

"¿Esta implementación satisface este requisito?"   → 0.94
"¿Ha cambiado comportamiento no relacionado?"      → 0.12
"¿Hay evidencia en el diff de este bug?"           → 0.81
"¿Este test prueba de verdad el requisito?"        → 0.73
"¿Esta llamada tiene efectos destructivos?"        → 0.97

No sustituyes tests por Jev. Añades una capa semántica barata entre los tests y el juez caro. Si ya estás construyendo sensores y guías en tu harness, esto encaja justo en el hueco de los sensores.

La primitiva mental que me quedo es esta:

💡 semantic_if(). Código cuando conoces la regla. Jev cuando conoces las respuestas posibles pero no sabes formalizar la regla. Un modelo razonador cuando ni siquiera conoces el camino o tienes que generar algo nuevo.

Esa separación me parece bastante más importante que el titular de «200× más rápido».

¿Qué se te complica al programar con preguntas en vez de prompts? ¶

El trabajo no desaparece, se muda. Y se muda a un sitio donde no estás acostumbrado a trabajar: el diseño de la pregunta.

En el hilo de Hacker News alguien puso el ejemplo perfecto. Imagina esta entrada de un usuario:

"Quiero que un agente humano me llame mañana a las cinco."

Y esta pregunta a Jev:

"¿El usuario pide hablar con un agente humano?"  → 0.97

La respuesta es correcta. Y el sistema hace lo que no debe, porque llama al usuario ahora en vez de mañana a las cinco.

La réplica en el hilo también es correcta y es la que te tienes que llevar: la pregunta estaba mal formulada. Si necesitabas saber el «cuándo», eso era otra pregunta. Aquí no hay un modelo que rellene los huecos que dejaste, y esa es al mismo tiempo la garantía y la carga.

Sus propios ejemplos de documentación dan la medida del asunto. Una sola pregunta bien hecha no es una línea de texto, es una estructura con question, focus, compare, y criterios donde defines para cada opción what, not_for, examples y signals. Hay quien en el hilo lo describió como un híbrido incómodo de lógica de código, definiciones en texto y caja negra, con demasiado pegamento alrededor.

⚠️ Con un LLM, una pregunta floja te da una respuesta floja que a veces te salva porque el modelo rellena lo que faltaba. Con Jev, una pregunta floja te da una respuesta perfectamente tipada, perfectamente confiada y perfectamente inútil.

Hay además una grieta más sutil que señalaron en el hilo y que a mí me parece la crítica más fina de todas: que cada respuesta esté calibrada por separado no implica que lo esté la decisión que las combina. Si tú sumas cinco nouls con pesos que has elegido a ojo, la calibración del resultado es cosa tuya, no de TypeSafe. Puede haber muchas decisiones equivocadas que produzcan exactamente la misma puntuación compuesta.

Y una acción no autorizada no se vuelve aceptable porque puntúe alto en las otras cuatro dimensiones.

¿Qué no sabemos todavía de Jev? ¶

Cuatro incertidumbres, y ninguna es menor.

La arquitectura está cerrada y no hay paper, así que la afirmación de «clase nueva de modelos» no se puede auditar. La tesis central del RLCD sobre calibración necesita evidencia pública mucho más fuerte que un experimento de autoconsistencia. Sus evals principales comparan contra el consenso de dos modelos frontier en lugar de contra verdad verificada. Y el producto acaba de salir de stealth, así que toda la experiencia externa que existe tiene literalmente días.

A eso súmale que TypeSafe reconoce que sus cifras famosas de 193,6× y 444,6× salen de sus propios workflows de evaluación y que esperan que estén «en el extremo alto de las ganancias reales». La horquilla que publican en la tabla del anuncio es más modesta: de 40 a 200 veces más rápido, según el caso.

La reacción técnica ha sido enorme. El hilo de Hacker News acumula 1.838 puntos y 483 comentarios, y se plantó en lo alto de la portada todo el día. Pero interés no es validación, y buena parte de esos comentarios eran escépticos justo con las tres cosas que peor ha explicado TypeSafe: «frontier model», «no hallucinations» y la arquitectura oculta.

Y un dato que vale por todas las discusiones del hilo: horas después del lanzamiento alguien publicó un Qwen-2.5-1B-RLCD entrenado con la misma idea de decisiones calibradas, y dijo haber tardado dos horas. Casi seguro que no se acerca a Jev en calidad. Pero que el ecosistema intentara reproducirlo esa misma tarde te dice algo sobre dónde está el foso, y si tu caso es acotado ya tienes alternativas abiertas como GLiNER2 o los zero-shot de DeBERTa.

Mi lectura final es que aquí hay menos magia de machine learning de la que sugiere el anuncio y más importancia arquitectónica de la que parece.

Si dentro de seis meses descubrimos que Jev es un clasificador discriminativo muy grande y extraordinariamente bien entrenado, no me decepcionaría nada. Lo relevante sería que ha juntado propiedades que hasta ahora costaba tener a la vez: zero-shot, programable en lenguaje natural, con categorías dinámicas, capacidad semántica alta, probabilidades utilizables, fan-out masivo, 100 a 300 milisegundos y un coste casi despreciable.

Eso cambia el sitio donde sale a cuenta poner inteligencia.

Y si estás construyendo agentes, ahí es donde deberías mirar. No como un modelo más que añadir a la lista junto a Claude, Codex u OpenCode, sino como una primitiva nueva del lenguaje con el que escribes tu arnés.

El siguiente experimento que merece la pena es muy concreto: coge tu harness real y dibuja en qué quince o veinte puntos meterías Jev, cuáles seguirían siendo código determinista y cuáles dejarías para el modelo caro. Ahí se ve si esto altera de verdad tu arquitectura o solo añade otro clasificador barato.

¿Cuántas decisiones tontas le estás pagando hoy a tu modelo más caro?

TL;DR ¶

• 🧠 Jev es el primer System One Model de TypeSafe: no genera texto, solo devuelve decisiones tipadas (Choice, Score, Noul) con probabilidades
• ⚡ Entre 70 y 500 ms por respuesta y 0,042 dólares por millón de tokens de entrada, con la salida gratis
• 🎯 «No alucina» significa que respeta el esquema, no que acierte: elimina alucinaciones estructurales, no errores semánticos
• 📊 Sus evals miden acuerdo con GPT-6 Astra y Claude Fable 5.1, no verdad verificada, y la calibración sigue sin evidencia independiente
• 🔧 La regla de oro la dio Empryo midiendo: si el problema ya tiene una señal determinista buena, Jev te va a empeorar el resultado
• 🪨 El nombre viene de Jevons y su paradoja: abaratar la inteligencia no hace que uses menos, hace que la metas en sitios donde antes no cabía

Preguntas frecuentes sobre System One y Jev ¶

¿Qué es un System One Model?
Es la categoría que TypeSafe ha creado para describir modelos que renuncian a generar texto y devuelven decisiones tipadas con probabilidades calibradas. El nombre alude al System 1 de Kahneman, el juicio rápido e intuitivo. No es una categoría establecida de investigación, es nomenclatura de la propia empresa.

¿Jev es un LLM?
Según TypeSafe, no, porque no genera lenguaje. La descripción más precisa que existe hoy, y que su propio fundador aceptó en Hacker News, es la de un clasificador zero-shot generalizado programable en lenguaje natural.

¿Cuánto cuesta usar Jev?
0,042 dólares por millón de tokens de entrada, con tokens de salida gratuitos. En la práctica, Empryo midió unas dos cienmilésimas de dólar por comprobación en su caso de clasificación de errores.

¿Qué son Choice, Score y Noul?
Son los tres tipos de pregunta que acepta. Choice elige una opción de una lista cerrada de hasta 255 alternativas, Score puntúa contra unos niveles ordenados que describes en lenguaje natural, y Noul devuelve la probabilidad de que una pregunta de sí o no sea cierta.

¿De verdad Jev no puede alucinar?
Solo en un sentido estructural. No puede devolver un valor fuera del esquema que le has dado, así que no vas a ver JSON roto ni enums inventados. Pero puede elegir la opción equivocada con mucha confianza, y eso sigue siendo un error del modelo.

¿Qué es el RLCD?
Reinforcement Learning for Calibrated Decisions, el método de entrenamiento de TypeSafe. Donde el RLHF optimiza por la respuesta que prefiere un humano, el RLCD pretende optimizar por probabilidades honestas: que un 70% de confianza signifique acertar el 70% de las veces.

¿Puedo usar Jev para procesar imágenes o generar código?
No. Solo acepta texto y JSON como entrada, con un presupuesto de unos 32.000 tokens por petición, y no genera texto, código ni conversación. Es un motor de decisiones, no un asistente.

¿Jev sustituye a Claude Code o a Codex en mi flujo de trabajo?
No los sustituye. Se coloca en el harness, decidiendo qué skill cargar, si hace falta escalar o si una acción es destructiva, mientras el modelo grande sigue encargándose de razonar y generar código.

¿Es fiable el 193× más rápido que anuncia TypeSafe?
Es el extremo favorable de sus propios workflows, y la empresa lo reconoce. Las horquillas que publican son de 20 a 200 veces más rápido y de 40 a 400 veces más barato según el caso.

¿Por qué se llama Jev?
Por William Stanley Jevons, el economista de la paradoja de Jevons: abaratar el carbón por eficiencia disparó su consumo en lugar de reducirlo. TypeSafe apuesta a que con la inteligencia pasará lo mismo, y que cada orden de magnitud de bajada de coste abre órdenes de magnitud más de casos de uso.

¿Dónde no conviene usar Jev?
Donde ya tengas una señal determinista buena. Empryo descartó tres de los ocho usos que probó porque Jev empeoraba el resultado frente a una heurística por palabras clave o al orden nativo de la herramienta de búsqueda.

Fuentes ¶

• Introducing System One Models & Jev — anuncio original de TypeSafe
• System One y How to build with TypeSafe — documentación oficial
• Workflow evals — panel público de evaluaciones de TypeSafe
• Lies, Damned Lies, and Benchmarks — su postura sobre benchmarks
• Skill suggestion y Self-consistency: nouls — cookbooks con datos
• Software needs decisions, not chat — integración medida de Empryo
• Mini-Vibe Check: TypeSafe’s Jev — prueba independiente de Mike Taylor en Every
• Introducing System One Models and Jev — hilo de Hacker News con las respuestas del fundador
• TypeSafe AI emerges from stealth — la ronda de 40 millones liderada por DCVC
• TypeSafe AI debuts model for machines that plays Doom — cobertura crítica en The Register
• system-one-adapter-python — el wrapper con el que constriñen a los LLM para poder compararlos
• Qwen-2.5-1B-RLCD — el intento de reproducción publicado horas después del lanzamiento

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter