---
title: "Jev, el modelo de TypeSafe que no escribe texto: decisiones tipadas para tu código"
excerpt: "Jev es el primer System One Model de TypeSafe: le mandas un estado y preguntas tipadas, y te devuelve decisiones con probabilidades calibradas. Ni una cadena de texto. Qué es, cómo se llama a la API y cuándo compensa frente a un LLM."
date: "2026-09-17T18:00:00.000Z"
category: "Inteligencia Artificial"
tech_article: true
author:
  name: "angel cruz"
  picture: "/images/me/angel-cruz.png"
ogImage:
  url: "/images/open-graph/og-image.png"
seo_title: "Jev de TypeSafe AI: qué es, cómo funciona y cómo usar su API"
seo_description: "Guía de Jev, el System One Model de TypeSafe: los primitivos noul, choice y score, el endpoint /v1/systemone, confianza calibrada, precios y límites."
---

**Jev es un modelo de IA que no genera texto: le pasas un estado y un mapa de preguntas tipadas, y te devuelve respuestas que tu código puede consumir directamente, cada una con su distribución de probabilidades.** Lo publicó TypeSafe AI el 15 de septiembre de 2026 en acceso anticipado, y es el primero de lo que su fundador llama *System One Models*.

No hay `content` que parsear, ni JSON que validar, ni reintento porque el modelo se salió del esquema. Las respuestas posibles las defines tú por adelantado y el modelo se mueve dentro de ellas.

## Qué es un System One Model

El nombre viene de *Thinking, Fast and Slow* de Daniel Kahneman: el Sistema 1 es el pensamiento rápido e intuitivo, el Sistema 2 el lento y deliberado. TypeSafe se queda con el primero a propósito. Su modelo se llama Jev por William Stanley Jevons, el economista de la paradoja que lleva su nombre: cuando el carbón se abarató, no se consumió menos, se consumió muchísimo más. La apuesta de la casa es que cada orden de magnitud que baja el coste de la inteligencia desbloquea órdenes de magnitud de casos de uso.

La empresa salió de modo sigiloso el mismo día del lanzamiento, con 40 millones de dólares en una ronda seed liderada por DCVC. La fundaron Diogo Almeida como CEO, Erik Gafni como CTO y Sasha Sheng como COO, y tiene sede en San Francisco.

La diferencia con un LLM no es de tamaño, es de objetivo de entrenamiento. Los modelos de chat se optimizan con RLHF (preferencia humana) o RLVR (recompensas verificables). TypeSafe entrena con lo que llama **RLCD, Reinforcement Learning for Calibrated Decisions**: el objetivo es que las probabilidades que devuelve el modelo sean honestas, no que el texto guste.

Hay tres consecuencias prácticas de ese cambio:

- **El muestreo es paralelo, no autorregresivo.** Un LLM genera un token a la vez, condicionado al anterior. Jev emite todas las salidas en una sola pasada. De ahí sale la velocidad.
- **No puede alucinar en el sentido de tipos.** El espacio de respuestas está definido de antemano, así que el modelo nunca comete un error de tipo. TypeSafe lo plantea como una afirmación falsable con un solo contraejemplo, y dice que es matemáticamente imposible que ocurra.
- **Siempre acompaña la respuesta de una probabilidad.** No hay que pedirle "dame tu confianza del 1 al 10" y cruzar los dedos. La calibración es el objetivo del entrenamiento.

A cambio, Jev no escribe respuestas, no genera código y no explica su razonamiento. Si lo que necesitas es una redacción, este no es el modelo.

## Los tres primitivos: noul, choice y score

Toda la API se reduce a tres tipos de pregunta. Las tres comparten `type` e `instructions`, y cada una añade su propio `criteria`.

**Noul** es una pregunta de sí o no. Devuelve un número entre 0 y 1 con la probabilidad de que la respuesta sea sí. No trae `confidence` aparte, porque el propio valor ya lo dice todo: cerca de 1 es un sí rotundo, cerca de 0 un no rotundo, cerca de 0.5 es que el modelo no lo tiene claro. La documentación recomienda formular la pregunta de forma que "alto" signifique "sí", para que el número no sea ambiguo.

**Choice** elige una opción de un conjunto que tú defines. Devuelve la opción ganadora, el mapa completo de probabilidades (que suman 1) y un `confidence`. Soporta hasta 255 opciones.

**Score** puntúa el estado sobre una rúbrica ordenada de entre dos y diez niveles. Devuelve un valor ponderado por probabilidad, así que puede caer entre niveles: un `score: 1.6` sobre `["Calm", "Frustrated", "Very angry"]` es información que un entero te habría escondido. También devuelve un `legend` que mapea cada índice a su descripción. La recomendación de la documentación es usar tantos niveles como puedas describir de forma distinguible y no más: tres está bien, y un nivel que no sabes describir sobra.

Las preguntas se evalúan en paralelo dentro de la misma llamada. Descomponer un juicio grande en diez preguntas atómicas cuesta un solo viaje de red.

## Cómo se llama a la API de TypeSafe

Un solo endpoint, autenticación por Bearer:

```http
POST https://api.typesafe.ai/v1/systemone
Authorization: Bearer <API_KEY>
Content-Type: application/json
```

El cuerpo lleva tres cosas: el `state` (una cadena, un objeto o un array), el `model` y el mapa de `questions`, donde tú eliges las claves. Este ejemplo, tomado de la referencia de TypeSafe, mezcla los tres primitivos sobre el mismo estado:

```json
{
  "state": "Help! My payouts have been failing for 3 days.",
  "model": "jev-latest",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "Does this convey urgency?",
      "criteria": {
        "true": "Explicitly time-sensitive",
        "false": "No urgency expressed"
      }
    },
    "department": {
      "type": "choice",
      "instructions": "Which team should handle this?",
      "criteria": {
        "billing": "Payments, invoicing, refunds",
        "technical": "Bugs, outages, integrations",
        "sales": "Pricing, upgrades, new accounts"
      }
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated is the customer?",
      "criteria": ["Calm", "Frustrated", "Very angry"]
    }
  }
}
```

Las respuestas vuelven bajo las mismas claves que tú pusiste:

```json
{
  "model": "jev-latest",
  "answers": {
    "is_urgent": { "type": "noul", "noul": 0.92 },
    "department": {
      "type": "choice",
      "choice": "technical",
      "probabilities": { "billing": 0.08, "technical": 0.85, "sales": 0.07 },
      "confidence": 0.82
    },
    "frustration": {
      "type": "score",
      "score": 1.6,
      "legend": { "0": "Calm", "1": "Frustrated", "2": "Very angry" },
      "probabilities": { "0": 0.05, "1": 0.3, "2": 0.65 },
      "confidence": 0.78
    }
  },
  "usage": { "input_tokens": 312, "output_tokens": 48 }
}
```

Un detalle sobre las claves: la documentación aclara que **el nombre que le das a cada pregunta no se envía al modelo ni participa en la inferencia**. Es tuyo, para que el código lea bonito.

### SDK de JavaScript y TypeScript

El cliente oficial está en npm como `@typesafe-ai/sdk`, con licencia MIT y Node.js 20 o superior. La versión 0.6.0 se publicó el 15 de septiembre de 2026, tres días después de que apareciera el paquete en el registry:

```bash
npm install @typesafe-ai/sdk
```

```ts
import { choice, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();
const response = await client.systemOne({
  state: { document: "I was charged twice. Please fix this ASAP." },
  questions: {
    category: choice("What is this ticket about?", {
      billing: null,
      technical: null,
      other: null,
    }),
  },
});

console.log(response.answers.category.choice);
```

Los tipos de las respuestas se infieren de las preguntas, y el paquete trae ESM, CommonJS y declaraciones de TypeScript. El cliente lee `TYPESAFE_API_KEY` del entorno.

### SDK de Python

`typesafe-sdk` está en PyPI, requiere Python 3.10 o superior, y también va por la 0.6.0. Trae cliente síncrono y asíncrono:

```bash
pip install typesafe-sdk
```

```python
from typesafe_sdk import AsyncTypeSafeClient, Choice, Noul, Score


async def main() -> None:
    async with AsyncTypeSafeClient() as client:
        response = await client.system_one(
            state={"document": "I was charged twice. Please fix this ASAP."},
            questions={
                "billing": Noul(instructions="Is this ticket about billing?"),
                "tone": Choice(
                    instructions="What is the customer's tone?",
                    criteria={"calm": None, "frustrated": None, "angry": None},
                ),
                "urgency": Score(
                    instructions="How urgent is this ticket?",
                    criteria=["can wait", "this week", "today"],
                ),
            },
        )

    print(response.nouls["billing"].noul)
    print(response.choices["tone"].choice)
    print(response.scores["urgency"].score)
```

Los dos SDK reintentan con backoff por defecto y respetan la cabecera `retry-after` cuando la respuesta la trae.

### Desde el AI Gateway de Vercel

Jev está en el catálogo del AI Gateway de Vercel con el identificador `typesafe-ai/jev`, declarado como tipo `evaluation` y con el mismo precio que en TypeSafe: 0,000000042 dólares por token de entrada y salida a cero. El catálogo lo marca además con retención de datos cero y sin entrenamiento sobre tus peticiones.

Para el AI SDK hay un proveedor propio, `@ai-sdk/typesafe-ai`, publicado en npm el 16 de septiembre de 2026 y hoy en la versión 3.0.2. Si ya tienes el gateway configurado en un proyecto de Next.js, esa es la vía con menos fontanería: una clave menos que gestionar y la facturación en el mismo sitio que el resto de tus modelos.

### Desde PHP o Laravel

No hay SDK oficial de PHP, pero tampoco hace falta: es un POST con JSON. Con el cliente HTTP de Laravel queda así:

```php
use Illuminate\Support\Facades\Http;

$response = Http::withToken(config('services.typesafe.key'))
    ->post('https://api.typesafe.ai/v1/systemone', [
        'state' => [
            'ticket' => $ticket->message,
            'plan' => $ticket->customer->plan,
        ],
        'model' => 'jev-latest',
        'questions' => [
            'department' => [
                'type' => 'choice',
                'instructions' => '¿Qué equipo debe atender esto?',
                'criteria' => [
                    'billing' => 'Cobros, facturas, reembolsos',
                    'technical' => 'Errores, caídas, integraciones',
                    'sales' => 'Precios, mejoras de plan, cuentas nuevas',
                ],
            ],
        ],
    ])
    ->throw()
    ->json();

$answer = $response['answers']['department'];
```

A partir de ahí, `$answer['choice']`, `$answer['confidence']` y `$answer['probabilities']` son datos normales sobre los que escribir un `match` o un `if`.

## La confianza calibrada y los umbrales por acción

Un LLM te da una respuesta y tú decides si te la crees. Jev te da una respuesta **y el reparto de probabilidad que hay detrás**, así que puedes poner el umbral donde te convenga.

TypeSafe propone tres caminos, con un umbral distinto por acción según lo que cueste equivocarse:

- **Confianza alta.** Actúa en automático.
- **Confianza media.** Actúa con cautela: pide confirmación, marca para revisión, recoge más contexto.
- **Confianza baja.** No actúes. Escala a una persona o cae a otro sistema.

En código, ese reparto se ve así (adaptado del ejemplo de la documentación):

```python
action = response.answers["action"]

if action.confidence < 0.5:
    # El modelo dice honestamente que no lo sabe.
    route_to_human(user_message)
elif action.choice == "check_balance":
    # Bajo riesgo: mostrar la pantalla equivocada se deshace solo.
    show_balance(account_id)
elif action.choice == "approve_transfer":
    if action.confidence > 0.9:
        confirm_then_execute(account_id)
    else:
        ask_user_to_confirm(account_id)
```

La propia documentación marca dos límites. La calibración se mide sobre grupos de predicciones, así que no garantiza que una respuesta concreta sea correcta. Y `confidence` es un estadístico derivado de `probabilities`: si tu caso pide otra forma de medir la incertidumbre, tienes la distribución completa para calcularla tú.

## Fan-out especulativo: pregunta de más, y en una sola llamada

Como las preguntas se evalúan en paralelo contra el mismo estado, **añadir preguntas no cuesta tiempo**. Así que la recomendación de TypeSafe es mandar también las preguntas que quizá no necesites, y dejar que tu código descarte las que no aplican.

En su ejemplo de triaje de tickets se preguntan a la vez la categoría, la severidad del bug, si hay pasos para reproducir, si se pide un reembolso y el nivel de frustración. La severidad solo importa si resulta ser un bug y el reembolso solo si resulta ser facturación, pero las cinco van en la misma petición. Si el ticket acaba siendo una petición de función, tu código ignora las otras cuatro y no ha pagado un viaje extra por averiguarlo.

La documentación publica una medición concreta de esto: un informe regulatorio de 13 preguntas sobre el artículo de Wikipedia del RGPD, resuelto de las dos formas.

| Forma | Llamadas | Coste | Tiempo total |
| --- | --- | --- | --- |
| Una llamada con las 13 preguntas | 1 | 0,000497 $ | 0,27 s |
| 13 llamadas de una pregunta | 13 | 0,006090 $ | 2,71 s |

12,2 veces más barato y 10 veces más rápido, con las mismas respuestas. Salen iguales porque cada pregunta se puntúa por su cuenta contra el documento, así que su respuesta no depende de qué más venga en la petición.

## Velocidad, precio y límites

Los números que publica TypeSafe, con fecha del anuncio del 15 de septiembre de 2026:

- **Latencia de extremo a extremo: de 70 a 500 ms.** La comparación que hacen es contra los 3 a 329 segundos de los modelos frontera, lo que les da entre 40 y 200 veces más rápido para consultas con esta forma.
- **Precio: 0,042 dólares por millón de tokens de entrada**, o 42 dólares por cada mil millones. Los tokens de salida son gratis, "demasiado baratos para medirlos".
- **Límites de tasa del modelo actual, Jev 1.13 (`jev-1.13.0`): 250.000 tokens por segundo y 1.200 peticiones por minuto.** TypeSafe avisa de que estos límites se están ajustando de forma dinámica y pueden cambiar sin previo aviso mientras absorben demanda.
- **Contexto: 64.000 tokens para el estado y las preguntas juntos, y 32.000 para el estado más la pregunta más larga.** Ese segundo límite son unos 150.000 caracteres de texto en inglés. Como Jev ingiere el estado una vez y luego procesa todas las preguntas en paralelo, la forma eficiente de gastar ese presupuesto es meter muchas preguntas en cada consulta.

Los alias funcionan como en cualquier otro proveedor: `jev-latest` apunta a la última versión estable y es el valor por defecto de los SDK, y `jev-preview` apunta a la última publicada sea oficial o no (hoy, la misma). Como un alias se mueve solo, la recomendación de la casa es fijar el ID versionado si tienes umbrales de confianza ajustados contra una versión concreta. El campo `model` de la respuesta siempre te dice qué versión contestó.

Sobre los benchmarks conviene ser prudente, y TypeSafe lo es más que la media. En sus evaluaciones de workflow dicen que Jev "posee la frontera de Pareto durante casi dos órdenes de magnitud", y de ahí salen las cifras de 193,6 veces más rápido y 444,6 veces más barato que aparecen en su portada. Ellos mismos matizan tres cosas: que esperan que esas ganancias estén en el extremo alto de lo real, que los workflows los construyó su propio equipo de capacidades del modelo (con el sesgo que eso implica), y que usan como referencia el promedio de GPT-6 Astra y Fable 5.1, lo que inclina la comparación hacia los modelos de OpenAI y Anthropic.

## Errores y reintentos

La tabla de estados es corta:

| Estado | Significado |
| --- | --- |
| `401 Unauthorized` | Falta la clave o no es válida. |
| `422 Unprocessable Entity` | El cuerpo no pasó la validación. La respuesta detalla el campo. |
| `429 Too Many Requests` | Pasaste el límite de tasa. Espera y reintenta. |
| `529 Overloaded` | El servicio está saturado. Reintenta tras una pausa breve. |

Si usas los SDK, el backoff exponencial ya viene puesto. Si llamas por HTTP directamente, ese código lo escribes tú.

## Dónde encaja Jev

La documentación lo plantea así: **el control de flujo, las reglas deterministas y los efectos secundarios se quedan en el código; a Jev le mandas los juicios semánticos, descompuestos en preguntas estrechas y tipadas.** Si tu aplicación ya sabe que un ticket cerrado no se procesa, ese `if` no tiene por qué pagar una llamada a un modelo.

Los casos donde esto cambia el cálculo económico:

- **Clasificación y enrutado masivo.** Triaje de tickets, moderación, detección de fraude, extracción de features para un modelo de ML. Cosas que se ejecutan un millón de veces sin nadie mirando.
- **Verificación de otras IA.** Comprobar citas, detectar jailbreaks, puntuar trazas de razonamiento, poner guardarraíles a un LLM por una fracción del coste de la llamada al LLM. Esto conecta directamente con el [harness engineering](/post/loop-harness-engineering): un bucle de agente puede consultar a Jev para decidir el siguiente paso sin quemar un modelo de frontera en cada iteración.
- **Aplicaciones en tiempo real.** Con respuestas de 100 ms puedes meter una decisión de IA dentro de una interacción de interfaz. TypeSafe enseña un bot jugando al Doom a unas 10 consultas por segundo, que les sale por unos 7 dólares la hora.
- **Map-reduce sobre datasets grandes.** Cuando el coste por decisión cae dos órdenes de magnitud, procesar el corpus entero deja de ser una locura presupuestaria.

Y donde no: cualquier cosa que necesite una cadena de texto de salida. Jev además **solo acepta texto de entrada** por ahora, en forma de cadenas, objetos JSON o arrays, sin imágenes, audio ni vídeo.

## Dónde falla Jev

TypeSafe mantiene una página de *jaggedness* por versión, con los fallos conocidos del modelo. La de `jev-1.13` está revisada al 17 de septiembre de 2026 y lista nueve modos de fallo. Vale la pena leerla entera antes de meter esto en producción. Los que más muerden:

- **Lectura literal.** Jev responde la pregunta que escribiste, no la que querías escribir. Las negaciones, los matices de alcance y las condiciones implícitas se leen al pie de la letra. La documentación da un criterio para detectarlo: si al mirar una respuesta equivocada te descubres explicando lo que en realidad querías decir, esa explicación es la mitad que le faltaba a la instrucción.
- **Matemáticas y conteo.** No es una calculadora y no cuenta de forma fiable, ni caracteres, ni apariciones de un término, ni elementos de una lista larga. Reconoce la forma de la respuesta en lugar de contar, y el error crece con el tamaño. Para contar cuántos elementos cumplen un criterio, la receta oficial es un `noul` por elemento y la suma en tu código.
- **Representaciones numéricas.** Rinde mejor con representaciones semánticas que numéricas. Preguntar por colores con nombres en inglés funciona mejor que con valores hexadecimales, y dados dos hex no distingue de forma fiable si están cerca.
- **Fechas.** Las lee como texto, no como cantidades ordenadas. Qué fecha va antes, cuánto distan o si una cae dentro de una ventana son preguntas poco fiables. La extracción sí es un juicio, así que lo que funciona es sacar mes, día y año como `choice` sobre conjuntos cerrados, cada uno con su opción de "no consta", y montar la fecha y compararla en código.
- **Estado grande y lleno de ruido.** La precisión baja según crece el estado con contenido que no tiene que ver con la decisión. Filtra antes en código y manda solo los campos que la pregunta necesita.
- **Contenido adversario.** El estado se trata como datos, no como hostil. Una instrucción inyectada o un texto que argumenta a favor de su propia clasificación pueden mover la respuesta. TypeSafe dice que espera mejorar esto.

Hay una trampa menos obvia: **no esperes invariantes estructurales entre preguntas distintas.** La misma pregunta como `noul` y como `choice` de sí o no no devuelve números comparables, y una pregunta y su negación como dos `noul` tampoco suman 1. El ejemplo que publican, sobre el ticket "me cobraron dos veces por el mismo pedido, ¿alguien puede mirarlo?", da 0,72 a "pide un reembolso" y 0,47 a "pide algo que no es un reembolso". Suman 1,19. La consecuencia práctica es que un umbral ajustado sobre un `noul` no se puede trasladar a un `choice`.

## Instalar la skill en tu agente de código

TypeSafe publica una skill para agentes que les da el contexto completo de la API, los tres primitivos y los patrones. En Claude Code son dos comandos, y encaja con el mismo mecanismo de [plugins y skills](/post/skills-claude-code) que ya usas para el resto:

```bash
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai
```

En otros agentes:

```bash
npx skills add typesafe-ai/skills --skill typesafe-ai
```

La documentación avisa de que los agentes no son buenos escribiendo las preguntas, así que espera editarlas a mano. El otro consejo sirve con cualquier herramienta: **pon las preguntas y los umbrales en un único archivo de constantes**. Es lo que un humano tiene que revisar en una integración así, y convierte un cambio de política en una edición de una constante que cabe en un pull request.

## Preguntas frecuentes

### ¿Qué es Jev de TypeSafe?

Es el primer System One Model de TypeSafe AI: un modelo que entiende lenguaje natural pero devuelve decisiones tipadas con probabilidades calibradas en lugar de texto generado. Se lanzó en acceso anticipado el 15 de septiembre de 2026 tras dos años en modo sigiloso.

### ¿Jev es un LLM más pequeño?

No es un LLM recortado. Es una arquitectura distinta, con muestreo paralelo en lugar de autorregresivo y un método de entrenamiento propio, RLCD, orientado a que las probabilidades de salida reflejen la incertidumbre real en lugar de a que el texto guste a un evaluador humano.

### ¿Cuánto cuesta Jev?

0,042 dólares por millón de tokens de entrada, 42 dólares por cada mil millones. Los tokens de salida no se cobran.

### ¿Jev puede alucinar?

No puede producir un error de tipo: el conjunto de respuestas posibles se define en la petición y el modelo se queda dentro. Eso no significa que la respuesta sea siempre la correcta, y por eso la confianza calibrada importa tanto: la calibración se mide sobre conjuntos de predicciones, no sobre una respuesta individual.

### ¿Hay SDK de PHP para TypeSafe?

No hay cliente oficial de PHP. La API es un único POST con JSON contra `https://api.typesafe.ai/v1/systemone`, así que el cliente HTTP de Laravel o cualquier envoltorio de cURL sirven sin problema. Eso sí, el backoff ante un `429` lo tienes que escribir tú.

### ¿Se puede usar Jev desde el AI SDK de Vercel?

Sí. Jev está en el catálogo del AI Gateway con el identificador `typesafe-ai/jev` y hay un proveedor dedicado en npm, `@ai-sdk/typesafe-ai`. El catálogo del gateway aplica el mismo precio que TypeSafe y marca el modelo con retención de datos cero.

### ¿Quién está detrás de TypeSafe AI?

La fundaron Diogo Almeida como CEO, Erik Gafni como CTO y Sasha Sheng como COO. Almeida trabajó en OpenAI en los métodos que hicieron útiles a los modelos para seguir instrucciones y conversar, el trabajo que acabó siendo la investigación detrás de ChatGPT. La empresa está en San Francisco, salió de modo sigiloso el 15 de septiembre de 2026 con 40 millones de dólares en una ronda seed liderada por DCVC, y el servicio se sirve desde una sola región en la costa oeste de Estados Unidos.

## Lo que vale la pena probar

Si tienes en producción un `if` frágil que hoy resuelves con una llamada a un modelo de chat, con su prompt de tres párrafos y su parseo defensivo del JSON, ese es el sitio por donde empezar. La ganancia ahí no es de inteligencia, que TypeSafe declara comparable, sino de forma: una respuesta que llega en 70 ms, que no hay que validar y que te dice cuánto se fía de sí misma.

El acceso hoy sigue siendo anticipado, con lista de espera y límites de tasa que la propia empresa avisa que pueden moverse sin previo aviso. Los SDK, en cambio, ya están públicos en npm y en PyPI, los dos en la versión 0.6.0.

## Fuentes

- [Introducing System One Models & Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev), anuncio de TypeSafe AI firmado por Diogo Almeida, 15 de septiembre de 2026.
- [Referencia de la API de TypeSafe](https://docs.typesafe.ai/api).
- [System One](https://docs.typesafe.ai/concepts/system-one), [Confidence](https://docs.typesafe.ai/confidence) y [Models](https://docs.typesafe.ai/models) en la documentación oficial.
- [SDK de JavaScript](https://docs.typesafe.ai/sdk/javascript) y [SDK de Python](https://docs.typesafe.ai/sdk/python).
- [Jev 1.13 jaggedness](https://docs.typesafe.ai/model-jaggedness/jev-1.13), los fallos conocidos del modelo, revisado el 17 de septiembre de 2026.
- [Speculative fan-out](https://docs.typesafe.ai/patterns/fan-out) y el cookbook de preguntas en paralelo, de donde salen las cifras del informe sobre el RGPD.
- Catálogo de modelos del [AI Gateway de Vercel](https://vercel.com/docs/ai-gateway), consultado el 17 de septiembre de 2026, y el registry de npm para las versiones de `@typesafe-ai/sdk` y `@ai-sdk/typesafe-ai`.
- [TypeSafe AI's new models work with machines, not humans](https://www.infoworld.com/article/4223468/typesafe-ais-new-models-work-with-machines-not-humans.html), InfoWorld, y [el comunicado de la ronda seed](https://www.businesswire.com/news/home/20260915525333/en/TypeSafe-AI-Emerges-From-Stealth-With-$40M-in-Funding-With-New-Model-for-Composable-AI) en BusinessWire.
- Para una versión larga en inglés, el [deep dive de Flavio Copes sobre Jev](https://flaviocopes.com/jev/).

---

## Sitemap

Índice completo del sitio: [/sitemap.md](https://www.angelcruz.dev/sitemap.md)

Canónico HTML: [https://www.angelcruz.dev/post/jev-typesafe-system-one-model](https://www.angelcruz.dev/post/jev-typesafe-system-one-model)
