¿Es Jev de código abierto? Los pesos están cerrados, las herramientas no

No. Jev 1.13 (typesafe/jev-1.13) no es de código abierto, no hay ningún repositorio de pesos que encontrar, y por más que se desplace por la organización de TypeSafe en GitHub no aparecerá un checkpoint, un documento de arquitectura ni un recuento de parámetros. Lo que sí hay es el software alrededor del modelo: once repositorios públicos, todos ellos MIT o Apache-2.0, ninguno de los cuales contiene Jev en sí. Esa es la respuesta honesta en una línea —las herramientas son abiertas, el modelo no—, y es la mitad de la historia que un lector nunca obtiene solo con «cerrado, alojado, no publicado». Dos fechas lo enmarcan. TypeSafe lanzó el modelo el 15 de septiembre de 2026, lo cual queda fuera de la ventana de siete días sobre la que escribe este blog, así que esto no es un artículo de lanzamiento y nada de lo que contiene debería leerse como tal. El evento fechado es el 24 de septiembre de 2026, cuando OrcaRouter añadió typesafe/jev-1.13 a su propio catálogo: la primera vez que se puede llamar a Jev a través de una pasarela de terceros en lugar de solo a través del endpoint propio de TypeSafe. Esa es la excepción sobre la que funciona esta página: un modelo que se volvió ejecutable donde antes no lo era.

Lo que eso cambia para un lector es acotado y práctico. Antes del 2026-09-24, evaluar Jev implicaba abrir una segunda relación con un proveedor antes de que pudieras probar una sola decisión. Después de eso, Jev se encuentra bajo la misma clave que la mitad generativa del mismo flujo de trabajo: una API para más de 200 modelos, 0 % de recargo (el precio de lista del proveedor se pasa tal cual, de modo que los recortes de precios del proveedor están vigentes aquí el mismo día), con el modelo accesible en typesafe/jev-1.13. Sigues llamándolo con su propia forma —POST /v1/systemone, sin streaming— porque esa no es la ruta chat-completions de OpenAI, pero el contrato que firmas y la clave que rotas son los que ya tienes.

La respuesta son dos respuestas, y ambas son necesarias.

"¿Jev es de código abierto?" suena como una pregunta de sí o no y se comporta como una de dos partes. Parte uno: el modelo. Es cerrado. TypeSafe no ha publicado pesos, ni arquitectura, ni cifra de cómputo de entrenamiento, ni recuento de parámetros para Jev 1.13, y no hay ningún repositorio que lleve su nombre. Parte dos: el software que lo rodea. Es abierto, se mantiene activamente y es genuinamente útil, y es la razón por la que un lector que busca un repositorio no se queda simplemente sin suerte.

Confundir ambas cosas produce la conclusión equivocada en las dos direcciones. Supón que todo el conjunto está abierto y te pasarás una tarde buscando un punto de control que no existe. Supón que todo el conjunto está cerrado y te perderás la pieza que de verdad importa si te preocupa el lock-in: un adaptador con licencia MIT que te permite compilar contra la interfaz de decisiones tipadas y cambiar lo que hay detrás de ella.

Lo que realmente publica TypeSafe

Leído el 2026-09-30, la organización tiene once repositorios públicos. Los recuentos de estrellas y las fechas de push cambian, así que considera esto una instantánea y no una propiedad fija del proyecto. Todas las licencias son MIT o Apache-2.0 salvo que se indique lo contrario.

• skills — MIT, aproximadamente 2,4 mil estrellas, último push el 2026-09-12. «Habilidades de agente para construir con la API System One de TypeSafe.»

• system-one-adapter-python — MIT, 356 estrellas, última actualización 2026-09-22. "Reemplazo directo de TypeSafeClient respaldado por API de LLM."

• typesafe-sdk-js — MIT, 257 estrellas, última actualización 2026-09-15. La biblioteca oficial de TypeScript/JavaScript para la API de TypeSafe.

• typesafe-sdk-python — MIT, 254 estrellas, última subida 2026-09-26. La biblioteca oficial de Python; v0.7.2 añadió un extra `http2` ese día, y v0.7.1 el 2026-09-21 añadió ejemplos de uso con pasarelas de IA.

• daggerverse — Apache-2.0, 23 estrellas, última actualización 2026-09-25. Una colección de módulos de Dagger.

• WorkflowEvals — Apache-2.0, 7 estrellas, último push 2026-09-29. "código de flujo de trabajo de evals.typesafe.ai publicado".

• n8n-nodes-typesafe-ai — MIT, 1 estrella, último push 2026-09-29.

• typesafe-ai.github.io — sin licencia declarada, 2 estrellas, último push el 2026-06-04.

Tres más son bifurcaciones de proyectos no relacionados y se abordan a continuación: pulumi-clickhouse, LLaDA y vllm.

Nada de esa lista es el modelo. No hay un repositorio Jev, ni archivos de pesos, ni tokenizador, ni configuración de serving — nada que te permita levantar una copia funcional. Los repos son mobiliario del lado del cliente: dos SDK oficiales, un paquete de habilidades para agentes, una colección de módulos de CI, una suite de evaluación publicada, un nodo de n8n, el sitio de la organización y el adaptador. Esa es una superficie real y bien mantenida, y no es el modelo.

El único repositorio que importa si intentas evitar el lock-in

system-one-adapter-python es la entrada con mayores consecuencias para cualquiera que tome una decisión de adopción, y su propia descripción lo señala: un "reemplazo directo de TypeSafeClient respaldado por API de LLM".

Lee eso con atención, porque está haciendo algo específico. El activo duradero en una integración de System One es la interfaz, no el endpoint que hay detrás: defines una pieza de estado y un conjunto de preguntas con nombre, y algo devuelve una respuesta tipada por pregunta. Ese contrato es aquello en torno a lo cual termina moldeándose tu base de código. El adaptador desacopla el contrato de la implementación: sigues construyendo contra la interfaz de decisiones tipadas, y lo que produce las decisiones es, por debajo, una llamada a una API de LLM intercambiable.

Dos salvedades honestas. Un adaptador no es el modelo: las respuestas producidas por un LLM general a través de esta vía no son las probabilidades calibradas que devuelve Jev, así que es una forma de mantener la interfaz portátil, no una forma de obtener el comportamiento de Jev sin Jev. Y es explícitamente un proyecto de TypeSafe: la válvula de escape la construye el proveedor del que quizá quieras escapar, lo cual es mejor que nada y no es lo mismo que una independiente.

Las dos bifurcaciones, y la inferencia que invitan

Tres de los once repositorios son forks. pulumi-clickhouse es un proveedor de Pulumi para ClickHouse Cloud, Apache-2.0, 3 estrellas, último push: 2026-07-08. Los otros dos son los que se leen como evidencia, y ambas lecturas son incorrectas.

• vllm — Apache-2.0, 3 estrellas, último push 2025-05-23. Una bifurcación del motor de inferencia y servicio de alto rendimiento.

• LLaDA — MIT, 12 estrellas, último push: 2025-06-17. Un fork de la implementación oficial de PyTorch para «Large Language Diffusion Models».

La inferencia perezosa se escribe sola: hicieron un fork de un repositorio de diffusion-language-model, así que Jev debe de estar basado en difusión. No lo está, y el fork no te dice nada sobre la arquitectura de Jev. Un fork es una copia del código de otra persona bajo la licencia de otra persona, que está en una organización por razones que su propia fecha del último push deja en evidencia —mayo y junio de 2025, más de un año antes de que Jev se lanzara públicamente, y sin tocar desde entonces. Ninguno de los dos repositorios forma parte de lo que TypeSafe publicó en septiembre. Si quieres saber cómo funciona Jev, TypeSafe no lo ha publicado, y ningún fork en su organización llena ese vacío.

Lo que realmente te cuesta cerrar los pesos

Cuatro cosas, y son concretas más que filosóficas.

• No puedes alojarlo por tu cuenta. No hay ningún artefacto que ejecutar, así que una caída del proveedor o un cambio de acceso no es algo que puedas sortear levantando tu propia copia.

• No puedes auditar. TypeSafe sí publica una página de irregularidades para Jev 1.13 —revisada por última vez el 2026-09-17— que señala dónde el modelo no es fiable: la lectura literal de la redacción por encima de la intención, cualquier cosa que implique aritmética, la comparación de fechas y horas, la indirección y las dobles negaciones, estados grandes llenos de detalles irrelevantes, contenido adversario en el estado, instrucciones y criterios contradictorios, e invariantes estructurales que no garantiza, como que una respuesta de verdadero/falso y su opción equivalente de sí/no no coincidan. Esa página es inusualmente sincera, y aun así es el proveedor corrigiendo su propia tarea. Nadie fuera de TypeSafe ha inspeccionado los pesos.

• No puedes hacer ajuste fino. No hay un modelo base que adaptar, así que una tarea de decisión que Jev maneja mal seguirá manejándose mal hasta que el proveedor la cambie: los propios remedios de la página de irregularidades son soluciones alternativas en tu código, no ejecuciones de entrenamiento.

• No puedes fijar una versión más allá del alias del proveedor. typesafe/jev-1.13 es un nombre alojado, así que lo que responda a una llamada el mes que viene será lo que TypeSafe esté sirviendo bajo ese nombre en ese momento.

Nada de eso es exclusivo de Jev y nada de eso es un escándalo; es el intercambio que hace un modelo de decisión alojado, y la contrapartida es que nunca cargas con un checkpoint, una factura de GPU ni una pila de inferencia. Vale la pena saber en qué lado del intercambio estás antes de construir sobre él.

Qué es Jev, ahora que puedes llamarlo

Jev no es un modelo de chat y no genera prosa. Usted envía un estado —el material que se va a juzgar, ya sea texto, un objeto o un arreglo— más un conjunto de preguntas con nombre, y devuelve una respuesta estructurada por cada pregunta. Cada pregunta es una de tres primitivas:

• noul — un juicio de verdadero/falso, devuelto con una probabilidad calibrada.

• selección — elige una de hasta 255 opciones etiquetadas.

• score — puntuar en una escala ordenada de 2 a 10 niveles.

La propia documentación de TypeSafe muestra un ejemplo de puntuación indexada desde 0; la ficha del modelo Jev 1.13 publica niveles de 2 a 10. Ambos son material del propio proveedor y esta página no inventa una reconciliación entre ellos.

El método de entrenamiento es un término acuñado por la propia TypeSafe: Reinforcement Learning for Calibrated Decisions (RLCD), descrito en la publicación de lanzamiento frente a RLHF y RLVR en el eje de las decisiones calibradas con probabilidades honestas. RLCD es un término propio de TypeSafe, no un acrónimo genérico de aprendizaje automático, y debe leerse como una descripción del proveedor en lugar de como una técnica caracterizada de forma independiente.

El acceso ya no está restringido: Jev está disponible de forma general desde 2026-09-21, y se ha retirado «waitlisted». «Early access» sigue siendo la formulación actual y propia de TypeSafe en su página de inicio, así que no es una afirmación que deba descartarse: es simplemente la etiqueta del proveedor, y los límites operativos que publica junto a ella son concretos.

Las cifras de nuestra tarjeta: un contexto de 65,536 tokens, con el proveedor documentando aproximadamente 64K de entrada entre el estado combinado y las preguntas. Si has visto una cifra menor citada para Jev, esa es solo el presupuesto del estado, no una medición rival, y no deberían presentarse como una contradicción. El precio es de $0.042 por millón de tokens de entrada, con la salida facturada a cero: no hay tokens de salida que medir, porque una decisión tipada no es prosa.

Nuestros propios datos de servicio, procedentes de nuestro tráfico y no del benchmark del proveedor, durante los siete días hasta el 2026-09-30: p50 151 ms, p95 247 ms, alrededor de 349 tokens de salida por segundo, una tasa de errores del 0,49% y 76,2 M de tokens servidos. El p50 diario a lo largo de esa ventana fue de 175 → 170 → 163 → 161 → 170 → 147 → 143 ms, con un auténtico valor atípico: un p95 de 2.448 ms el 2026-09-28 que forma parte de la serie sin ser la norma.

Las afirmaciones principales de TypeSafe, etiquetadas como del proveedor y no replicadas de forma independiente: «193,6x más rápido, 444,6x más barato», con nota al pie referida a los flujos de trabajo de System One; un ejemplo práctico de 0,000081 $ en 0,114 s frente a 0,013880 $ en 8,566 s para LLMs; «42 $ por mil millones de tokens de entrada»; y «Cero alucinaciones», que es una afirmación sobre estimaciones de confianza más que una prueba de cero errores —la tasa de error del 0,49 % de nuestra ficha es el contrapeso honesto. TypeSafe también dice claramente que no puede demostrar que su precio no esté subvencionado, y que sus evaluaciones publicadas generalmente se ejecutaron desde portátiles en la Costa Oeste, donde tiene su sede el servicio. Su propia ficha de benchmark sigue marcada como pendiente.

Los repositorios de terceros existen, y no respondemos por ellos.

Las búsquedas de "jev github" acaban mostrando repositorios que no son de TypeSafe: wrappers, colecciones de prompts, experimentos de adaptadores y la conocida lista "awesome" que aparece en torno a cualquier modelo nuevo. No forman parte de lo que publica el proveedor, no cuentan con revisión del proveedor, y sus recuentos de estrellas miden la curiosidad, no la corrección. Pueden ser útiles; no son documentación, y nada de lo que contienen constituye una declaración sobre cómo funciona Jev.

¿Qué cambiaría esta respuesta?

Un lanzamiento de pesos, una arquitectura publicada o una evaluación independiente de la calidad de la decisión en lugar de la latencia. Cualquiera de los tres cambiaría la primera palabra de esta página. Hasta entonces, la búsqueda tiene una respuesta estable, y la parte sobre la que vale la pena actuar es la cadena de herramientas: si la interfaz de decisiones tipadas es contra la que estás construyendo, un adaptador con licencia MIT que intercambia el modelo de respaldo es la diferencia entre una decisión que puedes revisar y una que no.

Jev 1.13 está en nuestro catálogo bajo typesafe/jev-1.13, en la misma clave que el resto de un stack y se enruta a través del endpoint dedicado de systemone en lugar de la forma de chat-completions. El modelo es cerrado, las herramientas son abiertas, y ambas mitades de eso ahora son accesibles desde un solo lugar.