Si trabajás con automatización o inteligencia artificial, conocés esta escena. Armaste un flujo que clasifica mensajes entrantes. Le pediste al modelo que devuelva una de tres categorías. Funcionó perfecto en las pruebas. Y un martes cualquiera, a las tres de la mañana, el sistema se rompe porque el modelo devolvió una cuarta categoría que inventó, o un párrafo donde tu código esperaba una palabra.
Ese problema tiene nombre: error de tipo. Y es distinto del error de criterio.
El 15 de septiembre de 2026, TypeSafe AI presentó un modelo que ataca exactamente eso. Se llama Jev, inaugura una categoría que llaman System One Models, y su propuesta es sencilla de enunciar: no escribe, no explica, no programa. Solo decide.
Quién está detrás del proyecto
Jev fue creado por TypeSafe AI, fundada por Diogo Almeida, quien antes trabajó en OpenAI ayudando a construir los métodos que hicieron que los modelos de lenguaje fueran útiles para seguir instrucciones y conversar con personas: el trabajo de investigación que terminó siendo la base de ChatGPT.
Su pregunta de arranque, según cuenta en el anuncio oficial, fue directa: si los modelos son sobrehumanos en chat desde hace años, ¿dónde está toda la automatización?
La empresa pasó dos años en stealth antes de este lanzamiento, y construyó un stack completamente nuevo: arquitectura de modelo propia, muestreador paralelo y un método de entrenamiento llamado RLCD (Reinforcement Learning for Calibrated Decisions).
💡 De dónde salen los nombres. "System One" viene de Daniel Kahneman y Pensar rápido, pensar despacio: la distinción entre el pensamiento rápido e intuitivo y el razonamiento lento y deliberado. "Jev" viene de William Stanley Jevons, el economista de la paradoja que lleva su nombre: así como la eficiencia del motor a vapor terminó aumentando la demanda de carbón, cada orden de magnitud que baja el costo de la inteligencia desbloquea órdenes de magnitud más de casos de uso.
Qué es Jev en términos simples
Jev es un modelo diseñado para hacer juicios acotados sobre texto o estado estructurado. La forma más clara de entenderlo es la que usa el propio fundador: pensalo como una llamada a función con inteligencia de frontera. Entra estado no estructurado, sale una decisión tipada con probabilidades.
La diferencia con un modelo de lenguaje tradicional está en el contrato de salida. En lugar de pedirle que "escriba un JSON" y esperar que respete el formato, con Jev el desarrollador define las respuestas posibles antes de la inferencia. El modelo devuelve uno de esos valores permitidos, o un puntaje, o una probabilidad, junto con su nivel de certeza.
Estado no estructurado → Jev → elección + puntaje + probabilidad → código de la aplicación
El modelo se ocupa del juicio semántico. El código sigue controlando la regla, el umbral, el efecto secundario, la auditoría y el plan alternativo.
LLM tradicional vs. System One: la comparación completa
Esta tabla resume la diferencia arquitectónica, según la documentación oficial:
| Dimensión | LLM existente | System One / Jev |
|---|---|---|
| Optimizado con | RLHF / RLVR | RLCD (decisiones calibradas) |
| Optimiza para | Preferencia humana y recompensas verificables | Probabilidades epistémicamente honestas |
| Entrada | No estructurada, énfasis en mensajes secuenciales | No estructurada, énfasis en estado estructurado de programa |
| Salida | Strings. Flexibles: respuestas, código, alucinaciones, rechazos. Requieren parseo y validación | Valores tipados. Definidos por adelantado. El modelo nunca comete errores de tipo |
| Muestreo | Secuencial, un token por vez | Paralelo, todas las salidas en una sola consulta |
| Costo de entrada | USD 0,20 – 10 / M tokens | USD 0,042 / M tokens |
| Costo de salida | ≈ 5× la entrada | Gratuito |
| Velocidad | 3 – 329 s | 70 – 500 ms |
| Confianza | Tiende al exceso de confianza y a la inconsistencia | Siempre la comunica. Calibrada y consistente |
Hay un punto en esa tabla que explica por qué la automatización con IA falla más de lo que debería, y aparece textualmente en el anuncio de TypeSafe:
Si un modelo resuelve bien una tarea el 95% de las veces pero no te avisa cuándo está en el 5% restante, no podés automatizar esa tarea.
Cuánto cuesta comparado con los modelos de frontera
El precio es la parte más llamativa del anuncio. Esta es la comparación que publicó TypeSafe, en dólares por millón de tokens:
| Modelo | Proveedor | Entrada | Salida |
|---|---|---|---|
| GPT-6 Astra | OpenAI | $10,00 | $50,00 |
| Claude Fable 5.1 | Anthropic | $10,00 | $50,00 |
| Claude Opus 5 | Anthropic | $5,00 | $25,00 |
| GPT-5.6 Sol | OpenAI | $4,00 | $20,00 |
| GPT-5.6 Terra | OpenAI | $2,00 | $12,00 |
| Claude Sonnet 5 | Anthropic | $2,00 | $10,00 |
| Claude Haiku 4.5 | Anthropic | $1,00 | $5,00 |
| GPT-5.6 Luna | OpenAI | $0,20 | $1,20 |
| Jev | TypeSafe AI | $0,042 | Gratis |
Precios por millón de tokens publicados por TypeSafe AI al momento del lanzamiento. Los de los demás proveedores pueden haber cambiado.
Contra el modelo más barato de la lista, Jev cuesta casi cinco veces menos en la entrada. Contra los de frontera, unas 238 veces menos. Y como la salida es gratuita, la brecha real es mayor todavía: en un LLM la salida suele costar cinco veces más que la entrada.
Precisión contra costo: el dato que importa
El precio solo no dice nada si el modelo acierta menos. TypeSafe publicó un gráfico de precisión contra costo promediando cuatro workflows, y lo interesante no es solo dónde cae Jev, sino la forma de la frontera: la línea que une los puntos donde no existe nada a la vez más barato y más preciso.
| Modelo | Enfoque | Costo por workflow | Precisión |
|---|---|---|---|
| Jev | workflow | ≈ $0,0004 | ≈ 68% |
| GPT-5.6 Luna | workflow | ≈ $0,003 | ≈ 67% |
| GPT-5.6 Terra | workflow | ≈ $0,03 | ≈ 68% |
| GPT-5.6 Sol | workflow | ≈ $0,08 | ≈ 74% |
| Claude Opus 5 | workflow | ≈ $0,13 | ≈ 73% |
| Claude Sonnet 5 | workflow | ≈ $0,12 | ≈ 68% |
| Claude Opus 5 | prompt | ≈ $0,30 | ≈ 65% |
| GPT-5.6 Luna | prompt | ≈ $0,008 | ≈ 52% |
Valores aproximados leídos del gráfico publicado por TypeSafe AI, redondeados. Sirven para comparar órdenes de magnitud, no como cifras exactas.
Dos lecturas salen de ahí, y la segunda vale para cualquiera que diseñe automatizaciones, use Jev o no:
- Jev iguala la precisión de Luna a un costo unas 75 veces menor, y la de Terra a unas 75 veces menos también. Solo Sol y Opus 5 lo superan en precisión, y lo hacen a doscientas veces el costo.
- El mismo modelo rinde mucho mejor dentro de un workflow estructurado que resolviendo todo en un prompt. Opus 5 pasa de ≈65% a ≈73% con la misma inteligencia detrás. La diferencia no es el modelo: es cómo está descompuesto el problema.
Los tres tipos de pregunta
Choice — elección entre opciones fijas
Se entrega una lista cerrada de etiquetas: facturación, soporte técnico, ventas, cancelación, otro. La respuesta incluye la etiqueta seleccionada, la distribución de probabilidad entre todas las opciones y un valor de confianza.
Sirve para clasificación de intención, enrutamiento de colas, selección de políticas, etiquetado de contenido o decidir qué herramienta recibe una tarea. Soporta hasta 255 opciones; para conjuntos mayores, el propio proveedor usa un sistema de dos etapas.
Score — puntuación en escala ordenada
Define un rango ordenado: urgencia del 1 al 5, calidad de un lead del 0 al 10. Devuelve el puntaje, la distribución sobre los valores permitidos y una señal de confianza.
Sirve cuando el orden importa. Un riesgo de 4 está más cerca de 5 que de 1, y un conjunto de etiquetas sueltas no expresa esa relación.
Noul — probabilidad de una afirmación
Pide un valor entre cero y uno. ¿Qué tan probable es que este pasaje responda a la consulta? ¿Que esta solicitud viole una regla? Devuelve la probabilidad directamente.
Acá está lo importante: en lugar de forzar al modelo a decir sí o no en un límite arbitrario, la aplicación recibe la probabilidad y elige el umbral según la consecuencia. Una personalización inofensiva puede aceptar 0,65. Una acción de pago puede exigir 0,98 más verificación adicional. El umbral lo decide el negocio, no el modelo.
Cero alucinaciones: qué significa exactamente
Acá hay que ser preciso, porque la frase se presta a malentendidos. La afirmación del proveedor es que el cumplimiento del esquema no es una probabilidad alta sino una garantía matemática: sería fácil falsearlo con un solo contraejemplo, pero es imposible que ocurra.
Jev no puede inventar una cuarta categoría cuando el esquema permite tres. No puede devolver un párrafo donde el código espera un número. La forma de la respuesta está garantizada por diseño, no por instrucciones que el modelo pueda ignorar bajo presión.
Pero eso no equivale a decir que el juicio siempre sea correcto:
| Tipo de error | Estado | Qué implica |
|---|---|---|
| Error de tipo | Imposible | La salida siempre se ajusta al tipo declarado |
| Error semántico | Sigue siendo posible | Una etiqueta válida puede ser la equivocada |
| Confianza | Ayuda a gestionarlo | Dispara revisión o fallback, pero no es prueba |
Por qué la distinción es práctica y no académica. Un error de criterio lo detectás, lo medís y lo contenés con umbrales. Un error de formato te rompe la automatización completa, en silencio, y generalmente te enterás cuando ya causó daño. Como lo plantea TypeSafe: una llamada a herramienta alucinada es un inconveniente dentro de un agente conversacional, pero es un problema terminal si está enterrada varias capas adentro de una cadena de dependencias.
Ficha técnica
| Dato | Detalle |
|---|---|
| Modelo actual | Jev 1.13 (jev-1.13.0) |
| Lanzamiento | 15 de septiembre de 2026 |
| Precio de entrada | USD 0,042 / millón de tokens |
| Precio de salida | Gratuito |
| Latencia publicada | 70 – 500 ms extremo a extremo |
| Capacidad de entrada | 64K tokens por solicitud |
| Cardinalidad máxima | 255 opciones por pregunta |
| Acceso | Early access vía API y Playground |
| SDKs | Python y JavaScript |
A ese precio, un millón de clasificaciones de 500 tokens costaría alrededor de 21 dólares en tokens de modelo, antes de infraestructura, red o revisión humana. La empresa aclara que espera que su precio baje, no suba, aunque reconoce que no puede demostrar hoy que no esté subvencionado.
Cómo midieron sus resultados, y por qué el método importa
Esta parte suele faltar en los artículos sobre lanzamientos, y es la que más sirve si estás evaluando adoptar algo.
TypeSafe creó un tipo de evaluación distinto al benchmark tradicional. En lugar de optimizar contra una clasificación de referencia fija o permitir que el modelo y su andamiaje cambien —lo que habilita sobreajuste por ingeniería de prompt— asumen que existe un grafo de cómputo correcto, un workflow representado en código. Todos los modelos reciben el mismo workflow, y se mide cómo se comparan contra el promedio de las predicciones de los modelos más grandes y caros disponibles.
Un hallazgo relevante para cualquiera que diseñe automatizaciones: los workflows más confiables del mundo real tienden a tener muchas preguntas independientes y descompuestas, con comportamiento fino que depende de probabilidades en lugar de decisiones discretas. El resultado final sí es una ramificación discreta, pero el camino hasta ahí involucra bastante ingeniería de dominio.
Las limitaciones que el propio proveedor reconoce
TypeSafe es transparente sobre el contexto de sus números, y eso merece señalarse:
- Las pruebas de velocidad se corren desde sus laptops en la costa oeste de Estados Unidos, donde está alojado el servicio.
- Los workflows no fueron elegidos para favorecer al modelo, pero fueron construidos por su propio equipo, por lo que puede existir sesgo.
- Usan el promedio de GPT-6 Astra y Fable 5.1 como respuesta de referencia, lo que sesga los resultados hacia los modelos de OpenAI y Anthropic.
- La cifra de cero alucinaciones no es empírica: se deriva de la garantía matemática del esquema.
- El titular de 193,6× más rápido y 444,6× más barato corresponde al extremo favorable, y ellos mismos esperan que las ganancias reales sean menores.
Existe además una pieza de evidencia externa: el ingeniero Malte Ubl reportó haber corrido Jev contra una evaluación de clasificador que ya tenía armada previamente con otro modelo. Jev saturó la métrica de calidad y corrió aproximadamente seis veces más rápido. Es relevante porque la evaluación precedía al modelo, pero sigue siendo el reporte de un solo desarrollador.
⚖️ Conclusión honesta: la evidencia alcanza para justificar una prueba seria con datos propios. No alcanza para declarar que Jev supera a todo clasificador, reranker o motor de reglas existente.
Dónde tiene sentido usarlo
1. Workflows con IA y "smart if-statements"
La categoría central. Las salidas estructuradas se insertan en software ordinario como reglas de decisión difusas: clasificar, enrutar, puntuar, extraer o ramificar donde la lógica escrita a mano resulta demasiado frágil. El código de alrededor limita la libertad del modelo, y eso los hace mucho más fáciles de componer en sistemas confiables.
2. Monitoreo de sensores y dispositivos en tiempo real
Un sistema que vigila equipos industriales o infraestructura recibe lecturas constantes. Cuando aparece una anomalía hay que decidir rápido: ¿falla real, mantenimiento programado o ruido del sensor? Esperar ocho segundos a que un modelo grande redacte un análisis no sirve. Una decisión en décimas de segundo sí.
3. Detección de fraude y decisiones transaccionales
Una transacción entra y hay que decidir si pasa, se frena o se deriva a revisión, antes de que el pago se complete. Acá el valor de Noul es directo: la aplicación recibe la probabilidad y define su umbral según monto, historial y apetito de riesgo.
4. Aplicaciones en tiempo real donde la experiencia importa
Velocidades de 100 milisegundos permiten meter IA donde antes era impensable por latencia: interfaces que reaccionan mientras el usuario escribe, validaciones instantáneas, asistencia contextual sin espera perceptible.
5. Map-reduce sobre grandes volúmenes de datos
Aplicar la misma pregunta de forma independiente sobre miles o millones de registros, y dejar que el código agregue los resultados. El modelo se enfoca en juicios semánticos locales; el código determinista se ocupa del conteo, los umbrales y la selección final.
6. Verificación y guardrails sobre otros modelos
Un agente propone una acción, y algo tiene que evaluar si está dentro de la política antes de ejecutarla. Ese control tiene que ser más rápido que la acción misma, o deja de tener sentido. Importante: esto no es un límite de seguridad completo, porque el modelo sigue siendo influenciable por entradas adversarias.
7. Triaje operativo
Tickets, facturas, leads, reportes de incidentes, reseñas. Todo lo que llega en lenguaje desordenado y termina en una cola o en un puntaje. El valor es mayor cuando la taxonomía cambia con suficiente frecuencia como para que mantener un clasificador propio resulte incómodo.
8. Mejorar sistemas RAG y búsqueda empresarial
En una arquitectura RAG ya hay capas especializadas: el parser recupera estructura, los embeddings traen candidatos, el reranker los ordena. Jev agrega una decisión más: ¿la evidencia alcanza? ¿es contradictoria? ¿está desactualizada? Recién cuando esa capa dice que sí, el modelo grande escribe la respuesta citada.
Dónde no es la herramienta adecuada
El proveedor es inusualmente directo sobre sus bordes irregulares:
- No lo uses para escribir. No redacta respuestas, explicaciones, resúmenes ni código.
- La aritmética va en el código. Hay debilidades documentadas en conteo, cálculo y precisión numérica.
- La lógica de fechas va en el código. Comparar marcas de tiempo es un punto flojo documentado.
- Escribí las preguntas de forma literal. Las instrucciones indirectas o anidadas reducen la fiabilidad.
- Limpiá el contexto irrelevante. Grandes cantidades de estado no relacionado perjudican la decisión, aunque entren en el límite de contexto.
- No confundas calibración con certeza. Un valor de alta confianza necesita validarse con los datos de tu propio producto.
Y algo que el propio anuncio deja claro: los LLM siguen siendo mejores para prototipar. La flexibilidad de los strings los hace excelentes para armar rápido algo que funciona a veces. Si estás en etapa de exploración, esa flexibilidad es una ventaja, no un defecto.
Cómo se compara con las alternativas que ya conocés
Contra la salida estructurada o modo JSON
La salida estructurada es la alternativa más cercana: le das un esquema al LLM y el proveedor restringe la respuesta para que sea parseable. Es excelente cuando necesitás un objeto rico con nombres, descripciones y fechas generadas.
Jev encaja mejor cuando el espacio de salida es chico y las respuestas ya existen: el modelo solo las selecciona o califica. Usá modo JSON cuando necesitás contenido generado dentro de una estructura; considerá Jev cuando cada respuesta válida ya se conoce de antemano.
Contra un clasificador tradicional
Un clasificador convencional puede ser rapidísimo y barato después del entrenamiento. Para un problema estable, de alto volumen y con suficientes datos etiquetados, probablemente siga siendo la mejor opción. El atractivo de Jev es traer flexibilidad de lenguaje natural y configuración con pocos ejemplos sin que cada equipo entrene y opere un modelo propio. El costo de eso es control: un clasificador propio se ajusta a tu taxonomía y puede desplegarse en entorno privado.
Contra un reranker
Un reranker toma una consulta y documentos candidatos y los ordena por relevancia. Jev puede preguntar si un pasaje responde a una consulta, pero no tiene el mismo objetivo de entrenamiento ni el contrato específico de búsqueda. En RAG se complementan.
La arquitectura recomendada: cascada, no reemplazo
El diseño más sólido no reemplaza nada. Reparte.
- El código hace las verificaciones estrictas. Autenticación, límites, campos obligatorios, fechas, reglas numéricas.
- Jev toma la decisión semántica acotada. Clasifica, evalúa riesgo, estima si la evidencia alcanza.
- El flujo interpreta la incertidumbre. Acepta lo confiable y de bajo riesgo, deriva lo ambiguo a un modelo más grande o a una persona.
- Un LLM maneja el trabajo generativo. Escribe la respuesta, investiga, usa herramientas aprobadas.
- El código es responsable de la acción. Registra la decisión y la versión del modelo, aplica la política, ejecuta el cambio de estado.
Un beneficio que suele pasarse por alto: el registro de auditoría deja de ser un párrafo opaco que otro componente interpretó, y pasa a contener la pregunta, las respuestas permitidas, la probabilidad, el umbral, la ruta elegida y la versión del modelo. Para quien trabaje con sistemas regulados, de salud o financieros, eso solo ya justifica evaluar el enfoque.
Cómo evaluarlo antes de llevarlo a producción
- Empezá por una decisión que ya exista y ya termine en una etiqueta, un puntaje ordenado o una probabilidad.
- Congelá un set de prueba representativo. Casos fáciles, ambiguos, etiquetas raras, entradas largas y ejemplos adversarios.
- Usá etiquetas revisadas por humanos. El consenso entre modelos sirve para explorar, no para medir precisión de producción.
- Medí calibración, no solo precisión. Agrupá predicciones por probabilidad y verificá si la confianza coincide con el acierto observado.
- Definí umbrales por consecuencia. Una etiqueta de marketing y una retención de pago no comparten umbral.
- Compará el costo total de la tarea. Reintentos, fallbacks, revisión humana e ingeniería, no solo el precio del token.
- Fijá la versión del modelo para evaluaciones reproducibles.
Privacidad y consideraciones para empresas
La política de privacidad de TypeSafe indica que la información provista por clientes no se usa para entrenar ni ajustar sus modelos, y que los servicios se alojan en Estados Unidos. La política pública no promete retención cero para cada solicitud de API: describe retención según sea razonablemente necesaria para los fines indicados.
Eso no lo descalifica para datos empresariales. Significa que, como con cualquier proveedor, hay que obtener por escrito los términos exactos de procesamiento, retención, subprocesadores, eliminación, seguridad y región que tu carga de trabajo requiera. El acceso anticipado es también el momento correcto para preguntar por compromisos de nivel de servicio y avisos de cambio de versión.
Preguntas frecuentes
¿Qué es Jev?
Jev es el primer modelo System One de TypeSafe AI. Convierte texto o estado estructurado en elecciones, puntajes y probabilidades definidas de antemano, que el código puede usar directamente sin parsear ni validar.
¿Jev es un LLM más chico?
No. Es una clase de modelo distinta, con arquitectura, muestreador y algoritmo de entrenamiento propios, orientada a tomar decisiones dentro de software y no a generar texto.
¿Realmente tiene cero alucinaciones?
No puede producir una salida fuera del tipo declarado: eso es una garantía estructural, no estadística. Pero sí puede tomar una decisión semánticamente incorrecta. Son dos problemas distintos: el de formato es imposible, el de criterio sigue existiendo.
¿Reemplaza a ChatGPT o a Claude?
No. No escribe, no explica, no programa, no navega ni opera herramientas. Puede reemplazar llamadas puntuales de clasificación o puntuación dentro de un flujo, y derivar los casos difíciles a un modelo general.
¿Sirve para RAG?
Como capa de decisión, sí: puede juzgar si la evidencia alcanza, clasificar pasajes o filtrar una respuesta antes de que el modelo grande la escriba. No genera embeddings ni redacta la respuesta final.
¿Cuánto cuesta usarlo?
La entrada cuesta 0,042 dólares por millón de tokens y la salida es gratuita. A ese precio, un millón de clasificaciones de 500 tokens ronda los 21 dólares en tokens de modelo, antes de infraestructura y revisión humana.
¿Está disponible para todos?
No. Al momento de publicar este artículo está en acceso anticipado mediante Playground y API, con lista de espera, y SDK para Python y JavaScript.
Conclusión: la lección que sobrevive al producto
Jev es interesante menos por lo que hace y más por lo que cuestiona.
Se volvió costumbre mandarle toda tarea semántica a un modelo construido para escribir. Pero muchas decisiones de producción no necesitan un ensayo: necesitan una etiqueta conocida, un puntaje ordenado o una probabilidad sobre la que el código pueda actuar.
Está en acceso anticipado, las pruebas son mayormente del proveedor y los precios pueden cambiar. Nada de eso lo descalifica, pero sí obliga a probarlo con datos propios antes de apostarle algo importante.
Lo que sí es permanente es la idea de fondo, y la resume bien la propia empresa: la IA necesita una interfaz de la que el software pueda depender. Mientras la salida de un modelo sea un texto que hay que interpretar, siempre habrá una capa de incertidumbre entre la inteligencia y la acción.
Es la misma lógica con la que armamos agentes de IA y automatizaciones: el modelo decide, el código manda. Y para cualquiera que esté diseñando sistemas con IA hoy, la pregunta que deja es más útil que cualquier benchmark: ¿estás usando la herramienta más potente, o la correcta?
Fuentes: artículo de lanzamiento oficial de TypeSafe AI (Diogo Almeida, 15 de septiembre de 2026), sitio oficial de TypeSafe AI, documentación de System One y guía de irregularidades de Jev 1.13.