Nota sobre el modelo Jev (traducción al español)
Jev es un nuevo tipo de modelo que nos hace replantearnos cómo deberíamos pensar realmente la optimización de los LLM. Siguiendo la vía ortodoxa que arranca con ChatGPT, lanzado en 2022, los modelos se han optimizado para ayudar a los humanos en aplicaciones de chat. Y por supuesto, cuando los agentes de código como Claude Code y Codex se volvieron mainstream alrededor de 2025, también optimizamos los modelos para eso. Pero cuando miramos el stack de IA — cómo se acaba usando la IA en la capa de aplicación — esa presión se transmite hacia abajo sobre las capas inferiores, y en consecuencia tienden a transformarse para optimizar el mejor resultado en la capa de aplicación. Así, los modelos siguen optimizándose para ser más útiles a los humanos y también para ser más útiles en agentes de código.
Pero un área que siempre se quedó corta en los casos de uso fue la automatización de flujos de trabajo. Incluso un modelo muy inteligente como Astra y Fable no podía cruzar ese umbral sin un coste enorme por el camino. Y Type Scheme AI, la compañía detrás de Jev, sostiene que la razón por la que ese umbral es notoriamente difícil de cruzar incluso para modelos muy inteligentes es que los modelos de última generación están optimizados para cosas distintas. La forma en que lo articulan es una escisión en la línea ortodoxa: optimizar el modelo para la preferencia humana y después optimizarlo más para una recompensa verificable no se traslada bien cuando las decisiones deben ser rápidas en condiciones de incertidumbre.
Lo que se discute aquí no es que una vía sea superior a la otra, sino que Jev es una especie de antítesis de nuestra trayectoria actual en IA, argumentando que hemos estado descuidando los casos de uso que pueden marcar una gran diferencia en la automatización. Type Scheme AI sostiene que intentar forzar un modelo optimizado para la interacción humana y para usos agénticos hacia la automatización es fundamentalmente el enfoque equivocado.
Cuando miramos todos los proyectos que la gente muestra en redes sociales usando Jev, muchos en realidad demuestran la velocidad de ejecución, no la profundidad de comprensión. Ordenar correos, mejorar RAG, jugar a juegos, enrutado de modelos: todas son tareas que los LLM actuales pueden hacer, pero desde luego no a la velocidad de Jev, que según ellos es de 40 a 200 veces más rápido, con tiempos de respuesta de extremo a extremo de 70 a 500 milisegundos.
Funcionalmente, los LLM actuales pueden hacer todo lo que ofrece Jev, incluido imitar la respuesta para devolver un resultado igual que haría Jev. Pero igualar la latencia de 70 a 500 ms no es algo que los modelos autorregresivos puedan hacer fácilmente, sobre todo porque los tokens se generan uno tras otro hasta completar. En cambio, Jev está diseñado intrínsecamente para muestreo en paralelo y decisiones probabilísticas tipadas, algo que los LLM no hacen en su arquitectura. Así que el punto no es tanto qué es capaz de hacer Jev funcionalmente, sino para qué se está optimizando el modelo para cubrir más terreno en la capa de aplicación, de modo que la automatización, los juegos, los ordenamientos masivos — ese tipo de tareas — sean prácticamente posibles.
Ahora veamos el modelo Jev más de cerca y cómo funciona realmente. Pero antes, tenemos que hablar de los agentes de código, que pueden resultar complicados de usar. Por eso Juny CLI, un agente de código de JetBrains, podría ser perfecto para ti. Juny es lo que puntuó cerca del top en el leaderboard SWE-bench, con un 61,8% resuelto. Puedo traer este agente de código directamente a mi terminal y pedirle a Juny que trabaje en tareas de código complejas. Por ejemplo, aquí le pido a Juny que mantenga mi web actualizada, y como hay mucha información por actualizar, pulso shift+tab para poner a Juny en modo plan primero. En lugar de cambiar el código inmediatamente, Juny descompone la tarea en múltiples requisitos: el diseño, las etapas de implementación y los tests que quiere ejecutar. Y este plan queda guardado en la carpeta .juny/plans, así que puedo revisarlo antes de que Juny empiece a implementar. También puedo llevar mi propia API key y elegir qué modelo usar por tarea, lo que me da más control sobre los límites de uso. Por tiempo limitado, Gemini 3.8 Flash corre a un 75% de descuento del precio base en Juny, mientras que tu conductor diario puede seguir siendo Gemini 3.7 por defecto. Puedes abrir el plugin del IDE o el CLI de Juny, ejecutar una tarea real y ver cuánto puedes ahorrar.
A diferencia de los LLM tradicionales, donde les damos una instrucción y el modelo responde en texto, Jev es diferente porque te obliga a alejarte del texto crudo como entrada, poniéndola en un formato estructurado que se parece a esto. Y Jev responde en un formato estructurado similar, pero con una distribución de probabilidad.
¿Y qué hago con esto? Aquí es donde mucha gente acostumbrada a interactuar con IA a través de LLM tradicionales se queda atascada, porque las reglas de interacción son totalmente distintas con Jev. Los tipos primitivos básicos de Jev son choice, score y null. Puedes hacerle a Jev una pregunta categórica, una puntuación sobre opciones ordenadas, o una probabilidad de sí/no. Y estos son los bloques de construcción sobre los que el software puede construir encima. Casi se siente como si volviéramos a las puertas lógicas y registros, y ahora tenemos que construir muchas abstracciones por encima para crear aplicaciones más complejas.
Por ejemplo, puedo tomar esta larga lista de plantas para clasificar y procesarlas con modelos autorregresivos como Claude Opus 5, lo que sería inherentemente distinto a pedirle a Jev que haga la misma tarea, que se completa en uno o dos segundos. Y por supuesto puedes seguir distintos patrones de diseño según las permutaciones de estos bloques de construcción.
Cuando miramos la frontera de Pareto, Jev compite más cerca de modelos flash o nano como GPT-5.6 Luna, DeepSeek V4 Flash o Sonnet 5, pero solo en casos de uso concretos de flujos de trabajo. Así que lo que espero ver de aquí en adelante es más cobertura en esta frontera de Pareto, que no solo nos permita usar modelos optimizados para ayudar a humanos en tareas complejas y creativas, y modelos de uso diario para ayudar en tareas mundanas, sino que, con modelos como Jev, veamos una explosión de casos de uso en esta sección, a medida que más modelos siguen apareciendo y ayudan a hacer posible la automatización real en empresas que construyen sobre estos primitivos para crear algo útil y valioso. Y mientras exista demanda y casos de uso, probablemente veremos más modelos en esta sección.
Aunque Type Scheme AI no ha revelado los detalles de cómo funciona realmente su método RLCE, hemos tenido muchas ideas similares en el pasado sobre lo mismo. De hecho, alguien en Reddit ya hizo un modelo muy similar usando BERT bidireccional. Y este modelo de 421 millones de parámetros, open source, puede ejecutarse fácilmente en hardware de consumo.
Así que, cómo proceso yo toda esta noticia sobre Jev es realmente más sobre nuestros casos de uso creciendo horizontalmente que sobre la novedad de Jev en sí. Porque modelos estrechos y especializados como este es algo que ya teníamos antes de que la IA generativa se apoderara por completo de la narrativa pública. Y creo que esto es netamente positivo para el ecosistema: ahora apreciamos un panorama más amplio de modelos que no necesariamente recurre a la fuerza bruta de un modelo fundacional de propósito general para todas las tareas. Y a medida que chocamos con las limitaciones impuestas por la arquitectura y los objetivos de entrenamiento, podemos empezar a construir modelos optimizados para las restricciones adecuadas.
Nota práctica (Nura, 2026-10-11) — Disponibilidad vía OpenRouter
Probado typesafe/jev-router en OpenRouter. Conclusión:
- Existe en OpenRouter (ID
typesafe/jev-router, 1M tokens de contexto, pricing dinámico). - ¿Funciona como motor de decisión rápida? De momento NO. En una llamada de prueba (pregunta sí/no) el router sirvió un fallback:
stepfun/step-5-preview(un modelo de razonamiento general), no el modelo Jev descrito. No devolvió una respuesta limpia (finish_reason: length,content: null) ni el formato estructuradochoice/score/nullcon distribución de probabilidad. - El formato propio de inferencia de Jev (decisiones tipadas con probabilidad) no se expone tal cual por la API estándar de chat de OpenRouter — llega como un chat normal.
Conclusión: la idea de automatizar decisiones de bajo nivel (sí/no, elegir opción) hacia un modelo especializado es arquitectónicamente válida, pero hoy el router no sirve un motor de decisión fiable — automatizar sobre él empeoraría los resultados. Para decisiones interactivas es mejor el modelo principal del agente (con contexto de la sesión); un motor externo de decisiones solo tendría sentido en automatización en lote (scoring/clasificación de alto volumen desde código), y solo si el router llegara a servir el modelo real de Jev.