Jev 1.13 Explicado: Por qué el modelo responde con etiquetas en lugar de oraciones

Jev 1.13 (typesafe/jev-1.13) no es un modelo de chat, y la forma más rápida de entenderlo es dejar de leer su ficha técnica como se lee la de cualquier otro. TypeSafe lo lanzó el 2026-09-15 como el primer miembro de una clase que la empresa denomina modelos System One: le entregas un estado y un conjunto de preguntas con nombre, y te devuelve una respuesta tipada por pregunta: una etiqueta de una lista que tú proporcionaste, un nivel en una escala que tú definiste, o un verdadero/falso con una probabilidad asociada. Sin prosa, sin código, sin explicación. Este no es un artículo de lanzamiento. El modelo en sí es del 2026-09-15, tiene quince días y queda fuera de la ventana de siete días sobre la que escribe este blog, así que no se gana una página por su propio lanzamiento. Lo que ocurrió dentro de la ventana es que OrcaRouter añadió typesafe/jev-1.13 a su propio catálogo el 2026-09-24 y abrió la ficha del modelo Jev 1.13 en https://www.orcarouter.ai/models/typesafe/jev-1.13 — la primera vez que se puede invocar Jev a través de una pasarela de terceros y no solo mediante el endpoint propio de TypeSafe, y los primeros datos de servicio en vivo que alguien ajeno a TypeSafe ha publicado sobre él. Ese es el cambio que merece la pena leer: el modelo pasó a ser ejecutable donde antes no lo era.

La forma práctica de ese cambio es pequeña y concreta. Antes del 2026-09-24, adoptar Jev significaba una segunda relación con un proveedor — una cuenta de TypeSafe, una clave de TypeSafe, una factura de TypeSafe y una forma de solicitud personalizada contra la que escribir. Después, Jev se asienta sobre la misma clave que el resto de un stack: una API para más de 200 modelos, 0% de margen (el precio de lista del proveedor se transfiere tal cual, por lo que los recortes de precio del proveedor están activos aquí el mismo día) y el modelo accesible en typesafe/jev-1.13 mediante POST /v1/systemone. Sigues llamándolo con su propia forma — el endpoint no es la ruta chat-completions de OpenAI, y fingir lo contrario produciría un 404 en lugar de una decisión —, pero el contrato que firmas y la clave que rotas son los mismos que ya tienes.

¿Qué tipo de modelo es Jev?

La publicación de lanzamiento de TypeSafe lo afirma en una frase: "Nuestro primer modelo público es Jev, disponible hoy en acceso anticipado". La publicación luego presenta el modelo como "una llamada a función de inteligencia de frontera: estado no estructurado de entrada, decisiones probabilísticas tipadas de salida". Esa es una descripción justa de la interfaz, y una importante, porque casi todas las expectativas erróneas sobre Jev provienen de evaluarlo como un modelo de lenguaje pequeño. No es un modelo de lenguaje pequeño. Es un modelo de decisión con una gramática de salida fija, y la gramática es el producto.

La interfaz tiene exactamente dos entradas. El estado es el material que se va a evaluar: un correo electrónico, un ticket de soporte, una línea de registro, un registro JSON, un arreglo de coordenadas de juego. Las preguntas son un mapa de elementos con nombre, cada uno con un tipo, sus propias instrucciones y —para los dos tipos estructurados— sus criterios. Cada pregunta se evalúa con ese mismo estado, y las respuestas vuelven como una única carga útil JSON estructurada. La documentación de TypeSafe describe las preguntas como ejecutándose de forma concurrente e independiente, y hace dos afirmaciones que se derivan de ese diseño y no del ajuste: añadir preguntas apenas cambia el tiempo de respuesta, y añadir preguntas no genera deterioro del contexto, porque cada pregunta se juzga de forma aislada en lugar de después de las anteriores.

Vale la pena repetir la propia guía de diseño de TypeSafe, porque es la declaración más clara de para qué sirve el modelo. Mantén cada pregunta atómica y bien delimitada: «el tipo de juicio que una persona con grandes conocimientos podría hacer en unos segundos». Si una decisión requiere razonamiento extenso o combina de verdad varios factores independientes, divídela en preguntas separadas y vuelve a combinarlas en tu propio código. Su ejemplo: en lugar de un único prompt de «valora este pitch de startup», pregunta por separado sobre el tamaño del mercado, la viabilidad técnica y la diferenciación, y luego aplica tu propia ponderación. La razón por la que eso importa es que la ponderación pasa a estar en un coeficiente que puedes cambiar, en lugar de en un prompt que tienes que reescribir.

El modelo es cerrado en todos los sentidos que le importan a un ingeniero que razona sobre el riesgo. La arquitectura de Jev, su número de parámetros, el cómputo de entrenamiento y los pesos no están publicados. No hay ningún repositorio de pesos en la organización de TypeSafe en GitHub: los once repositorios públicos que hay son herramientas, SDKs, flujos de trabajo y tres forks no relacionados, y ninguno de ellos es el modelo.

"Typed" es todo el producto

La tarjeta de modelo de OrcaRouter publica las tres primitivas y, lo que es importante, los límites de cada una. Cada pregunta que le haces a Jev es una de exactamente tres formas:

• noul — un juicio de verdadero/falso, devuelto con una probabilidad calibrada en lugar de un booleano simple, de modo que "probablemente verdadero" y "ciertamente verdadero" sean valores distinguibles.

• choice — elige una de hasta 255 opciones etiquetadas, cada opción con su propio texto de criterios para que el modelo sepa qué distingue tus etiquetas.

• puntuación — calificar en una escala ordenada de 2–10 niveles, con las definiciones de los niveles proporcionadas como criterios.

La consecuencia de esa restricción es que no hay nada que extraer de la prosa y nada que validar contra un esquema que esperabas que el modelo hubiera seguido. La publicación de lanzamiento de TypeSafe es inusualmente directa sobre la garantía: la cifra de discrepancia de esquema del "0%" en sus gráficos "no es empírica. La coincidencia de esquemas está garantizada, por lo que podemos añadir con confianza 0% a los gráficos." Cuando tu espacio de respuestas es un conjunto cerrado que tú proporcionaste, un valor devuelto o bien está en el conjunto, o bien no provino del modelo —no hay un tercer resultado en el que el modelo escribiera algo plausible con la forma incorrecta y tu expresión regular lo aceptara en silencio.

Los tres tipos son también la razón por la que un revisor no puede evaluar a Jev de la misma manera en que evalúa un modelo de chat. No hay una puntuación de MMLU-Pro para comparar, ni una muestra de escritura para leer, ni una traza de razonamiento para inspeccionar. La única pregunta que significa algo es si la respuesta escrita es correcta, y si la probabilidad asociada a ella es honesta. Ambas cosas son medibles, pero solo contra tus datos y tus etiquetas.

Una diferencia documentada merece señalarse en lugar de resolverse: la propia documentación de TypeSafe muestra un ejemplo de Score que está indexado desde cero, mientras que la tarjeta de OrcaRouter publica la escala como 2–10 niveles. El proveedor documenta niveles; nuestra tarjeta publica 2–10. Si estás creando una rúbrica sobre Score, lee las definiciones de niveles en tu propia respuesta en lugar de asumir un índice.

¿Por qué no hay tokens de salida para facturar?

El precio es la expresión más clara de la arquitectura. Jev cuesta $0.042 por millón de tokens de entrada en OrcaRouter, y la tarifa de salida es $0.000000 por millón — no un descuento, no una promoción de lanzamiento, sino la ausencia de una cantidad medible. A un modelo generativo se le cobra por el texto que escribe; Jev no escribe texto. Devuelve una etiqueta, un nivel y una probabilidad. No hay nada que contar del lado de la salida, así que no se cobra nada allí.

TypeSafe declara el mismo número desde la dirección opuesta en su página de inicio —«$42 por mil millones de tokens de entrada»— y le añade una afirmación comparativa: «Precio de entrada 238 veces menor que Claude Fable 5.1». Esa comparación, como todo lo demás en la página de inicio, es del propio proveedor, sin que nadie la haya replicado. Pero la aritmética en la que se apoya es fácil de contrastar por un lector con su propia factura, que es la parte útil. El volumen de una carga de trabajo de decisión se determina casi por completo por cuánto estado introduces, y el estado es barato de una forma en que los tokens generados no lo son.

Las cifras destacadas del proveedor son mayores que la línea de precio y merecen el mismo etiquetado. TypeSafe anuncia «193,6x más rápido, 444,6x más barato» con una nota al pie que lo restringe a «flujos de trabajo para tareas de System One», y publica debajo un ejemplo práctico: TypeSafe AI, a $0,000081, completó en 0,114 s, frente a los LLMs, a $0,013880, que completaron en 8,566 s. La propia publicación de lanzamiento admite el riesgo del encuadre —se describe que los 193,6x y 444,6x probablemente se sitúan «en el extremo superior de las ganancias del mundo real»— y señala que la demostración comparativa usó una consulta «muy simplificada» con claves legibles para humanos elegidas por el proveedor para «presentar nuestro modelo bajo una luz ventajosa». Ninguna de estas cifras ha sido replicada de forma independiente, y la propia ficha de benchmark del proveedor sigue marcada como pendiente.

Qué significa «calibrado» y qué es RLCD

TypeSafe denomina su propio método de entrenamiento «Reinforcement Learning for Calibrated Decisions (RLCD)». RLCD es un término propio de TypeSafe, no un acrónimo general de aprendizaje automático anterior a la empresa, y su objetivo de optimización se indica en la tabla comparativa de la publicación de lanzamiento como «decisiones calibradas: respuestas con probabilidades epistémicamente honestas en tareas de System One». El contraste que establece esa misma tabla es con RLHF, que optimiza la preferencia humana —textos y respuestas de chat que les gustan a los evaluadores—, y con RLVR, que optimiza resultados que pueden verificarse programáticamente. RLCD optimiza una tercera cosa: la probabilidad asociada a que una respuesta sea una declaración precisa de la propia incertidumbre del modelo.

En la práctica, "calibrado" es una afirmación sobre las confianzas, no una garantía de que las respuestas sean correctas. Un modelo calibrado que dice 0,8 en un conjunto de preguntas debería ser correcto aproximadamente el 80% de las veces en ese conjunto; aún puede estar equivocado en cualquier pregunta individual. Esa distinción es la forma honesta de leer la línea de la página de inicio de TypeSafe: "Cero alucinaciones — Cada decisión de Jev viene con una estimación de confianza, para que tu software pueda actuar cuando la confianza es alta y escalar cuando no lo es". Es una afirmación de estimación de confianza, no una prueba de cero errores, y el contrapeso son nuestros propios datos: durante los siete días que terminaron el 2026-09-30, nuestra tarjeta mide una tasa de error del 0,49% en el tráfico de Jev a través de OrcaRouter — una cifra que marcaba 0,57% antes en la misma ventana, porque se calcula sobre siete días móviles de tráfico en vivo del playground en lugar de un conjunto de pruebas fijo. Ambos hechos pertenecen al mismo párrafo: las confianzas son el punto del modelo, y el modelo aún falla aproximadamente una llamada de cada doscientas en nuestro tráfico.

El relato de calibración también explica un comportamiento de latencia que, de otro modo, parecería un error. La publicación de lanzamiento de TypeSafe dice: «Para opciones de mayor cardinalidad, hacemos un sistema de 2 etapas: puntuamos de forma independiente y luego tomamos una decisión explícita; de ahí la ralentización ocasional». Una elección de 255 opciones no es una sola comparación hacia adelante; el proveedor puntúa y luego elige. Si ves que una solicitud contra un conjunto grande de etiquetas tarda notablemente más que un noul, ese es el mecanismo documentado, no la congestión.

¿Cómo lo llamas hoy?

En OrcaRouter el modelo es typesafe/jev-1.13, llamado "TypeSafe: Jev 1.13" en el catálogo, con un context_length de 65,536 tokens y exactamente un tipo de endpoint compatible: systemone. Se llama con POST /v1/systemone con tu clave de OrcaRouter, enviando un campo model, un campo state (string, object o array), y un mapa questions donde cada entrada lleva un type (noul, choice o score), sus instructions y sus criteria. Las respuestas son un único payload JSON estructurado y no se transmiten en streaming — no hay ningún modo de streaming al que optar.

La redacción de la propia tarjeta para el contrato es «texto de entrada, JSON estructurado de salida», y los límites publicados son los que hay que considerar al diseñar: sin streaming, hasta aproximadamente 64K tokens de entrada en total, sumando el estado y las preguntas, y las solicitudes que superen ese límite se rechazan antes de llegar al modelo. La entrada del catálogo indica el precio de lista como $0.042 por millón de tokens de entrada y muestra la tasa de finalización como cero. Esos son los números del proveedor trasladados sin cambios: la forma proporcional de cómo fijamos los precios: 0 % de recargo sobre las tarifas de lista del proveedor.

Para este modelo circulan dos presupuestos de tokens y no están en conflicto, así que manténlos separados. La cifra de 65.536 es el context_length de la tarjeta y está documentada como aproximadamente 64K de entrada entre el estado y las preguntas combinados. El «aproximadamente 32.000 tokens» que citan artículos anteriores de OrcaRouter es solo el presupuesto de estado: el espacio que obtiene tu material antes de que las preguntas tomen su parte. Si estás presupuestando una solicitud, el presupuesto de estado es el número que limita la carga útil que construyes; la cifra combinada es el techo de toda la llamada.

Lo que Jev no puede hacer, dicho sin rodeos

No puede escribir prosa, resumir, traducir ni conversar. Eso es el diseño, no una limitación por la que disculparse: el artículo de lanzamiento dice que Jev «renuncia a la generación de cadenas», y la propia página de jaggedness de TypeSafe incluye «Generation» como un modo de fallo con nombre propio, junto a la instrucción «Usa un modelo generativo». La generación forzada es lenta y mala. Si tu pipeline necesita un resumen escrito, Jev es el componente equivocado, y por mucho que se depuren los prompts, eso no cambia.

No es un reemplazo de un modelo generativo. El flujo de trabajo al que pertenece Jev tiene dos modelos: uno generativo que lee, escribe y razona en texto, y Jev a su lado haciendo las llamadas tipadas en milisegundos. Ese es el encuadre honesto de cada comparación de costos en la página de inicio del proveedor: la columna de los "LLMs" no es un competidor al que se esté desplazando, es la otra mitad del mismo sistema, y la razón por la que la combinación es interesante es que la mitad de decisión ahora está en la misma clave que la mitad generativa, en lugar de detrás de su propio contrato.

Y "calibrado" no significa correcto. Significa que el número adjunto a una respuesta está pensado para poder leerse como una probabilidad. Un 0,62 en un noul es el modelo diciéndote que no está seguro, lo cual es información útil que un simple sí/no habría destruido — y no es una promesa de que el sí sea correcto. La lógica de escalado construida sobre la confianza es el patrón previsto; tratar la respuesta como verdad absoluta no lo es.

Leyendo los números honestamente

Cada cifra de servicio de nuestra ficha procede de nuestro propio tráfico a través del playground de OrcaRouter en una ventana móvil de siete días, no del benchmark del proveedor, y la ventana se movió mientras se escribía este artículo; trátala como una lectura, no como una especificación. Para los siete días que terminan el 2026-09-30: mediana del tiempo hasta el primer token, 151 ms; p95, 247 ms; rendimiento de salida de alrededor de 349 tokens por segundo; tasa de error del 0,49 %; y 76,2 millones de tokens servidos. El p50 diario a lo largo de la ventana se sitúa en 175, 170, 163, 161, 170, 147 y 143 ms: una línea que mejora suavemente. El p95 del 09-28 de 2.448 ms es un auténtico valor atípico de un solo día dentro de esa serie, y citarlo como la norma sería erróneo del mismo modo que omitirlo por completo sería deshonesto.

Una advertencia adicional sobre la cifra de tráfico: 349 tokens de salida por segundo suena al rendimiento de un modelo generativo hasta que recuerdas que Jev no produce texto generado. El medidor está midiendo lo que nuestro playground cuenta del lado de la respuesta para una carga útil estructurada, y es útil para detectar degradación entre días más que para comparar a Jev con un modelo de chat.

Esas son nuestras cifras. Las cifras del proveedor son las de 193.6x, las de 444.6x, el ejemplo resuelto de $0.000081 y la comparación de 238x con Claude Fable 5.1 — todas propias de TypeSafe, ninguna replicada de forma independiente, y todas restringidas por sus propias notas al pie específicamente a los flujos de trabajo de tareas de System One. La única afirmación de rendimiento que hace TypeSafe que no es un benchmark en absoluto, y que vale más que los multiplicadores, es estructural: como las respuestas están tipadas, la integración no tiene paso de parseo ni paso de validación de esquema, y ese es un costo que no aparece en ninguna tabla de latencia.

¿Qué está abierto y qué no?

El 30/09/2026 se comprobó que la organización de TypeSafe en GitHub había publicado once repositorios. Ninguno contiene Jev. Los que importan a un desarrollador que integra el modelo son todos MIT o Apache-2.0: skills (MIT), system-one-adapter-python (MIT, descrito como un «reemplazo directo de TypeSafeClient respaldado por API de LLM»), typesafe-sdk-js (MIT), typesafe-sdk-python (MIT), daggerverse (Apache-2.0), WorkflowEvals (Apache-2.0, con código de flujo de trabajo publicado en evals.typesafe.ai), n8n-nodes-typesafe-ai (MIT), typesafe-ai.github.io y pulumi-clickhouse. Los recuentos de estrellas y las fechas de push cambian, así que, si lees esto más tarde, vuelve a comprobarlo en lugar de confiar en la lista.

Tres de las once son bifurcaciones de proyectos no relacionados y no demuestran nada sobre cómo funciona Jev: una bifurcación de vLLM a la que se hizo el último push en mayo de 2025, una bifurcación de LLaDA de junio de 2025 —LLaDA es un lanzamiento de modelo de lenguaje de difusión no relacionado— y un proveedor de Pulumi para ClickHouse Cloud. Es tentador deducir la arquitectura de una lista de bifurcaciones. No lo haga: nada sobre el diseño de Jev se sigue de esas tres, y en particular Jev no es un modelo de difusión, por mucho que la presencia de una bifurcación de LLaDA pueda sugerirlo.

La respuesta honesta en una línea a "¿Jev es de código abierto?" es que las herramientas son abiertas y el modelo no. Esa es una disposición normal para un modelo de frontera alojado, y es la disposición que deberías asumir cuando planificas en torno a Jev: una API con un precio publicado, un contrato documentado y un número de parámetros no publicado.

Donde el proveedor dice que Jev no es confiable

TypeSafe publica su propia página de irregularidades para jev-1.13, revisada por última vez el 2026-09-17, en la que señala dónde falla el modelo. Es inusualmente sincera y es el lugar adecuado para comenzar una sección de limitaciones, porque es la lista del propio proveedor y no la de un competidor:

• Lectura literal — toma las palabras al pie de la letra. Las palabras de alcance, las negaciones y las condiciones implícitas no se infieren; «responde a la pregunta que escribiste, no a la que querías hacer». La solución del proveedor es escribir la condición exacta y los criterios para cada opción.

• Matemáticas y números — no es una calculadora y no cuenta de forma fiable. Deja la aritmética al código.

• Comparación de fechas y horas — las fechas se leen como texto, no como cantidades ordenadas, por lo que el orden, los huecos y las ventanas no son fiables, y empeora con formatos mixtos.

• Indirección — las dobles negaciones y el razonamiento de varios saltos reducen la precisión. Reduzca los saltos y apunte al estado relevante.

• Estado grande lleno de detalles irrelevantes — el contenido no relacionado actúa como distractor y la precisión disminuye a medida que crece el estado. Filtra primero.

• Contenido adversarial — el estado no se trata como hostil, por lo que las instrucciones inyectadas o el encuadre engañoso pueden alterar las respuestas.

• Instrucciones y criterios contradictorios — cuando ambos piden cosas diferentes, el modelo «podría confundirse».

• Invariantes estructurales de sentido común — no se garantiza que P(noul) y 1 − P(no noul) sean consistentes. Pregunta cada decisión de una sola manera y haz cumplir las identidades en el código.

• Generación — ya cubierto, y el propio consejo del proveedor es usar un modelo generativo.

Dos de estos merecen énfasis. El adversarial importa porque toda la propuesta de valor de Jev consiste en juzgar material no confiable, y un estado que contiene instrucciones puede influir en una respuesta; si tu estado proviene de los usuarios, esa es una superficie de inyección de prompt con la misma forma que cualquier otra. El de las invariantes estructurales importa porque un modelo "calibrado" te invita a hacer aritmética con sus probabilidades, y el proveedor te está diciendo que no asumas que la aritmética cuadra.

A qué se compromete la publicación de lanzamiento y a qué no

Casi todas las afirmaciones del proveedor citadas en este artículo se remontan a una página: el propio anuncio de TypeSafe, archivado en la sección Company News y fechado el 2026-09-15, firmado por el fundador Diogo Almeida. Vale la pena dedicarle dos minutos a leerlo directamente, porque la redacción de una sola línea establece las condiciones de todo lo que ha ocurrido desde entonces. «Nuestro primer modelo público es Jev, disponible hoy en acceso anticipado». El acceso anticipado es la propia descripción del proveedor sobre la disponibilidad en su propia plataforma, y es una afirmación más limitada de lo que parece: compromete a TypeSafe a servir el modelo a usuarios aprobados y no dice nada sobre quién más puede servirlo. Ese es precisamente el vacío que cerró la incorporación al catálogo del 2026-09-24, y la razón por la que la ficha del modelo importa más que la publicación para cualquiera que evalúe Jev hoy.

La misma página es igualmente clara sobre sus propios límites, por lo que se cita en lugar de parafrasearse arriba. No publica ningún recuento de parámetros, ninguna descripción de arquitectura más allá de «una nueva arquitectura de modelo», ningún cómputo de entrenamiento y ningún repositorio de pesos, y no da fecha ni condiciones para la disponibilidad general. Esas ausencias son las restricciones de planificación: una API con un precio publicado por un lado, y un stack cuyo interior no puedes inspeccionar por el otro. La publicación también enmarca el modelo con la suficiente honestidad como para ser útil como especificación —«una llamada a función de inteligencia de frontera: entrada de estado no estructurado, salida de decisiones probabilísticas tipadas»—, que es la única frase en ella que describe la interfaz en lugar de la ambición.

Preguntas que plantea esta interfaz

¿Qué ocurre cuando un conjunto de opciones es mayor de 255 opciones? Está limitado: 255 opciones etiquetadas es el techo en una pregunta de elección, y el enfoque de dos etapas del proveedor —primero puntuar y luego elegir— es lo que hace a medida que aumenta la cardinalidad, que además es la fuente documentada de ralentizaciones ocasionales en conjuntos grandes de etiquetas. Si tu taxonomía es mayor que eso, la respuesta de diseño es descomponerla en varias preguntas y recombinar en código, que es el mismo consejo que da TypeSafe para juicios compuestos.

¿El contexto de 65,536 tokens significa 65,536 tokens de estado? No. El presupuesto publicado es de aproximadamente 64K tokens para el estado y todas las preguntas en conjunto, y la cifra de "aproximadamente 32,000 tokens" que aparece en coberturas más antiguas es solo el presupuesto de estado. Presupueste su carga útil con base en la cifra de estado, no en la combinada, y recuerde que las solicitudes que superan el límite se rechazan antes de que lleguen al modelo.

Qué hacer con esto

Jev 1.13 vale la pena echarle un vistazo por una razón específica y no por una general. Si tienes un paso en tu pipeline que actualmente es un modelo de chat al que se le pide que devuelva una etiqueta y en el que se confía para que la devuelva con la forma correcta —un enrutador, un evaluador, una verificación de políticas, una puntuación de rúbrica aplicada a miles de registros—, ese paso es el que este modelo reemplaza, a $0.042 por millón de tokens de entrada, sin nada medido del lado de la salida. Si tienes un paso que necesita una respuesta escrita, Jev no es la herramienta, y su propio proveedor lo dice.

Lo que cambió en la última semana no es el modelo. Es que probarlo dejó de requerir una segunda relación con un proveedor. Hace ocho días, una evaluación de Jev implicaba una cuenta separada y una integración separada; hoy es un solo id de modelo en una clave que ya llega a más de 200 modelos, con el precio de lista del proveedor trasladado sin cambios y las respuestas escritas volviendo desde el mismo lugar que todo lo demás. Para un modelo tan inusual, la capacidad de probarlo con tus propias etiquetas sin comprometerte con un nuevo contrato es la mayor parte de la decisión.