Cómo empezar con Jev y TypeSafe: guía práctica

Abres la consola, creas una clave y en diez minutos tienes una decisión tipada saliendo de tu terminal. Sin lista de espera, sin formulario de ventas, sin «te contactaremos».

Eso es lo que ha cambiado con Jev, el modelo de TypeSafe que no genera texto y solo devuelve decisiones con probabilidades. Ya analizamos qué es un System One Model y qué hay de marketing en el anuncio. Esto es lo otro: sentarte a usarlo.

Y aviso desde el principio, porque me ahorré una tarde el día que lo entendí: programar con Jev no se parece a escribir prompts. Se parece a diseñar un formulario. Un formulario que rellena una máquina muy rápida y muy barata, pero un formulario.

En esta guía vas a encontrar:

• Cómo sacar tu primera respuesta sin escribir una línea de código
• La primera llamada real con el SDK de TypeScript, comentada línea a línea
• Las tres primitivas (Choice, Score, Noul) y cuándo usar cada una
• Qué hacer con la confianza y dónde poner los umbrales
• Los límites reales del modelo y las tres cosas que hace mal
• Un problema serio si escribes en español, y cómo lo he resuelto

¿Qué necesitas para empezar con Jev? ¶

Una cuenta y nada más. No hay invitación, no hay acceso anticipado y no hay contrato de empresa.

Entra en console.typesafe.ai, regístrate y ya tienes dentro dos cosas: el playground para lanzar preguntas desde el navegador y la sección de claves de API para cuando quieras código. La documentación completa vive en docs.typesafe.ai.

El coste no debería frenarte. Jev cobra 0,042 dólares por millón de tokens de entrada y la salida es gratis, porque técnicamente no hay salida que cobrar: unas probabilidades no son tokens generados. Traducido: una tarde entera probando cosas te va a costar céntimos.

💡 Si vienes de las APIs de los modelos grandes, resetea la intuición de precio. Aquí procesar un documento largo cuesta menos que el café que te estás tomando mientras lo lees.

¿Cómo lanzo mi primera pregunta sin escribir código? ¶

Con el playground, y es el sitio por donde deberías empezar aunque seas capaz de montar la llamada HTTP con los ojos cerrados.

El flujo son tres pasos:

1. Pega cualquier texto en el campo de estado. Un ticket de soporte, un correo, un comentario de Slack. Lo que tengas a mano.
2. Añade una pregunta. La más sencilla es un Noul, que es una pregunta de sí o no.
3. Dale y mira lo que sale.

Prueba con esto como estado:

Llevo tres días intentando conectar la pasarela de pago y la integración
falla sin darme ningún error claro. Estoy perdiendo ventas. Ayuda, por favor.

Y esta pregunta:

{
  "urgencia": {
    "type": "noul",
    "instructions": "¿Este mensaje transmite urgencia?"
  }
}

Lo que vuelve es un número entre 0 y 1. No una frase que diga «sí, parece urgente», no un JSON envuelto en markdown, no una explicación de tres párrafos. Un número.

Ese salto mental es el que más cuesta, y por eso conviene darlo con el ratón antes que con el teclado.

Cuando le cojas el gusto, añade más preguntas a la misma llamada y fíjate en que el tiempo de respuesta apenas se mueve. Ahí está media gracia del modelo, y volvemos a ello más abajo.

Curso gratis · paso a paso

Escribir el qué antes de que nadie decida el cómo

Acabas de declarar el tipo y las opciones de una decisión antes de recibir ninguna respuesta. Con los agentes de código el método es el mismo. En este curso gratis recorres un ciclo completo de Spec Driven Development con OpenSpec sobre un proyecto real, en modo asistido y de principio a fin.

Empezar el curso gratis →

¿Cómo hago la primera llamada desde código? ¶

Sacas una clave en console.typesafe.ai/keys, la metes en el entorno y montas el cliente. Con el SDK de TypeScript son cuatro líneas.

Instalación (necesitas Node.js 20 o superior):

npm install @typesafe-ai/sdk
export TYPESAFE_API_KEY=tu-clave-aqui

Y la primera llamada de verdad:

import { noul, TypeSafeClient } from "@typesafe-ai/sdk";

// Lee TYPESAFE_API_KEY del entorno y usa jev-latest por defecto
const client = new TypeSafeClient();

const response = await client.systemOne({
  state: "Llevo tres días intentando conectar la pasarela y estoy perdiendo ventas.",
  questions: {
    urgencia: noul("¿Este mensaje transmite urgencia?"),
  },
});

console.log(response.answers.urgencia.noul); // 0.97
console.log(response.usage.input_tokens);    // 312

Mira lo que no hay en ese bloque: ni un JSON.parse, ni un try/catch de parseo, ni un esquema de validación con Zod, ni un reintento por si el modelo ha devuelto el JSON envuelto en un bloque de código. Nada de eso existe porque no puede fallar por ahí.

response.answers.urgencia está tipado según la pregunta que enviaste. Si preguntas un Noul, TypeScript sabe que hay un .noul. Si preguntas un Choice, sabe que hay un .choice y cuáles son sus valores posibles. Esa inferencia es una de las cosas que más se agradecen en el día a día.

¿Prefieres Python? pip install typesafe-sdk y la API es equivalente. ¿Prefieres curl? También:

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "Llevo tres días intentando conectar la pasarela.",
    "model": "jev-latest",
    "questions": {
      "urgencia": { "type": "noul", "instructions": "¿Transmite urgencia?" }
    }
  }'

Un endpoint, un método, un cuerpo. La superficie de la API cabe en una servilleta.

¿Qué son Choice, Score y Noul y cuándo uso cada uno? ¶

Son las tres formas que tiene Jev de contestar, y elegir mal es el error de principiante más común. La regla corta: mira la forma de la respuesta que necesita tu código, no la forma de la pregunta que tienes en la cabeza.

Choice: elegir una de la lista ¶

Enruta, clasifica, decide entre caminos. Las opciones las defines tú con un nombre y una descripción, y el modelo nunca devuelve algo que no esté en esa lista.

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

const client = new TypeSafeClient();

const response = await client.systemOne({
  state: ticket,
  questions: {
    equipo: choice("¿Qué equipo debería atender este mensaje?", {
      facturacion: "Cobros, facturas, reembolsos o suscripciones",
      envios: "Estado del pedido, retrasos o paquetes perdidos",
      cuenta: "Acceso, contraseña, perfil o seguridad",
      otro: "No encaja en ninguna de las anteriores",
    }),
  },
});

response.answers.equipo.choice;        // "facturacion"
response.answers.equipo.confidence;    // 0.81
response.answers.equipo.probabilities; // { facturacion: 0.88, envios: 0.02, ... }

Dos detalles que ahorran disgustos. El primero: mete siempre una opción de escape tipo otro o ninguna. Como las probabilidades de un Choice suman 1, sin esa válvula el modelo se ve obligado a repartir entre opciones que no encajan y te devuelve la menos mala con cara de convencido.

El segundo: caben hasta 255 opciones por pregunta. Si tienes una taxonomía de 3.000 categorías, no es un muro, es una invitación a bajarla por niveles: una pregunta elige la rama, la siguiente elige dentro de la rama.

Score: colocar algo en una escala ¶

Aquí lo importante no es el número, son las descripciones. Tú escribes los niveles en lenguaje natural y el modelo coloca el estado entre ellos.

import { score, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const response = await client.systemOne({
  state: ticket,
  questions: {
    // Los niveles describen SITUACIONES, no grados abstractos
    gravedad: score("¿Cómo de grave es el problema que reporta?", [
      "Cosmético: no afecta a la funcionalidad",
      "Función degradada, pero existe una alternativa",
      "Bloqueante: no hay forma de seguir adelante",
    ]),
  },
});

response.answers.gravedad.score;      // 1.43
response.answers.gravedad.confidence; // 0.35

Un 1.43 en una escala de tres niveles significa que el modelo está partido entre el nivel 1 y el 2, tirando al 1. Y la confianza de 0.35 lo confirma: el caso es ambiguo de verdad, no es que el modelo se haya despistado.

⚠️ Escribe niveles que describan situaciones («función degradada, pero existe una alternativa»), no adjetivos de intensidad («moderadamente grave»). Con adjetivos abstractos el modelo no tiene contra qué comparar y los números se vuelven ruido.

Admite entre 2 y 10 niveles. Si no sabes describir el séptimo nivel con palabras distintas del sexto, no lo pongas.

Noul: la pregunta de sí o no ¶

Es la más sencilla y la que más vas a usar. Devuelve la probabilidad de que la respuesta sea sí, y ya está.

import { noul, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const response = await client.systemOne({
  state: ticket,
  questions: {
    pideReembolso: noul("¿El cliente pide un reembolso de forma explícita?", {
      true: "Pide de forma directa que le devuelvan el dinero o un abono",
      false: "No pide dinero de vuelta, aunque se queje del cobro",
    }),
  },
});

response.answers.pideReembolso.noul; // 0.93

El criteria con true y false es opcional, y la mayoría de las veces sobra. Añádelo solo cuando la frontera entre el sí y el no sea sutil, que es justo cuando se nota.

Ojo con una trampa: un Noul no mide grados. Si preguntas «¿es fuerte este candidato en TypeScript?», un 0.5 no significa «nivel medio», significa que el modelo reparte la apuesta a partes iguales entre sí y no. Para medir niveles está el Score.

¿Cómo interpreto la confianza y dónde pongo los umbrales? ¶

La confianza es un número de 0 a 1 que resume cómo de concentradas están las probabilidades. Si toda la masa cae en una opción, la confianza es alta. Si se reparte, baja.

El patrón que funciona parte la confianza en tres tramos, no en dos:

• Alta: actúa de forma automática, el modelo lo tiene claro
• Media: actúa con red — pide confirmación, marca para revisión o busca más contexto
• Baja: no actúes — manda a una persona o a un modelo caro

Y lo importante: el umbral no es uno, es uno por acción. Enseñar un saldo y aprobar una transferencia no merecen la misma exigencia.

const equipo = response.answers.equipo;

if (equipo.confidence < 0.5) {
  // El modelo no lo tiene claro. Que lo vea alguien.
  await enviarARevisionHumana(ticket);
} else if (equipo.choice === "envios") {
  // Bajo riesgo: si me equivoco, el ticket cambia de cola y ya
  await asignar(ticket, "envios");
} else if (equipo.choice === "facturacion") {
  // Aquí hay dinero de por medio: subo el listón
  if (equipo.confidence > 0.9) {
    await asignar(ticket, "facturacion");
  } else {
    await marcarParaSupervision(ticket);
  }
}

Los números de ese bloque no son sagrados. Empieza conservador, mide con tus propios datos y muévelos.

Una advertencia que TypeSafe reconoce en su propia documentación y que conviene tener presente: la calibración es la afirmación central del modelo y la que menos evidencia independiente tiene. Trata los umbrales como algo que hay que validar contra tus casos etiquetados, no como una garantía que te viene de fábrica.

🔑 Un Noul no trae confianza. No le falta nada: su distribución solo tiene dos salidas, así que el propio número ya la describe entera. Lo que sí necesitas es decidir en qué franja central mandas el caso a una persona.

¿Por qué debería hacer muchas preguntas en la misma llamada? ¶

Porque las preguntas se evalúan en paralelo contra el mismo estado, y el estado es lo que ocupa casi todos los tokens.

Esto es lo que más cambia la forma de programar contra Jev. Si mandas el documento una vez y cuelgas quince preguntas, pagas el documento una vez. Si haces quince llamadas, lo pagas quince veces y esperas quince veces.

const response = await client.systemOne({
  state: ticket,
  questions: {
    equipo: choice("¿Qué equipo debería atender esto?", { /* ... */ }),
    gravedad: score("¿Cómo de grave es?", [ /* ... */ ]),
    pideReembolso: noul("¿Pide un reembolso de forma explícita?"),
    esCliente: noul("¿Menciona un número de pedido o de cliente?"),
    // Esta solo importa si el equipo resulta ser "envios".
    // La preguntas igual: el código decide después si la mira.
    tipoIncidencia: choice("Si es un problema de envío, ¿de qué tipo?", {
      no_entregado: "El paquete no ha llegado",
      retrasado: "Va con retraso pero sigue en camino",
      danado: "Ha llegado roto",
      ninguno: "No es un problema de envío",
    }),
  },
});

Fíjate en tipoIncidencia. Es una pregunta especulativa: solo tiene sentido si el ticket va a envíos, y aun así se lanza siempre. Si el ticket resulta ser de facturación, tu código ignora esa respuesta y no pasa nada. Te has ahorrado un viaje de ida y vuelta a cambio de unos pocos tokens de pregunta.

En la documentación de TypeSafe hay un caso medido: trece preguntas sobre un mismo artículo en una sola llamada salen 12,2 veces más baratas y 10 veces más rápidas que trece llamadas de una pregunta, con las mismas respuestas.

Lo que va contra la costumbre: aquí optimizar no es preguntar menos, es preguntar todo de golpe.

¿Qué preguntas funcionan bien y cuáles no? ¶

Las atómicas funcionan. Las compuestas no.

Si te sale una pregunta del tipo «analiza este ticket y decide qué hacer», párate. Eso no es una pregunta, es un encargo, y necesita deliberación. Jev es para juicios rápidos: lo que una persona con contexto contestaría en un segundo sin pensárselo.

Lo que sí funciona es partir ese encargo en pedazos y recomponerlo en tu código:

// Mal: una pregunta que esconde tres juicios dentro
const malo = noul("¿Es este correo spam?");

// Bien: tres señales independientes que tú combinas con tus pesos
const respuesta = await client.systemOne({
  state: correo,
  questions: {
    pideCredenciales: noul("¿Pide al destinatario su contraseña o un código?"),
    premioInesperado: noul("¿Anuncia un premio o pago que nadie ha solicitado?"),
    remitenteNoCuadra: noul(
      "¿La organización del remitente contradice el dominio del correo?",
    ),
  },
});

const a = respuesta.answers;
const riesgo =
  0.45 * a.pideCredenciales.noul +
  0.30 * a.remitenteNoCuadra.noul +
  0.25 * a.premioInesperado.noul;

Y ahí ganas algo que un prompt largo no te da: cuando el resultado no te convence, cambias un coeficiente en tu código y vuelves a medir. No reescribes una instrucción y rezas.

Con las escalas pasa lo mismo. Si una valoración depende de tres cosas distintas, no la metas en un Score que las mezcle. Saca tres Score, normaliza cada uno dividiendo por su nivel más alto y pondéralos tú.

¿Qué límites tiene Jev hoy? ¶

Estos, y conviene tenerlos delante antes de diseñar nada:

• Solo texto: cadenas, objetos JSON y arrays de texto. Ni imágenes, ni audio, ni vídeo
• Contexto de 64.000 tokens por petición, con un tope de 32.000 para el estado más la pregunta más larga
• 255 opciones como máximo en un Choice y 10 niveles en un Score
• 250.000 tokens por segundo y 1.200 peticiones por minuto de límite de tasa
• No genera texto, no escribe código y no mantiene conversación

Sobre los modelos: en la petición mandas jev-latest, que es un alias y apunta hoy a jev-1.13.0. La respuesta siempre te dice qué versión contestó, así que si has ajustado umbrales contra una versión concreta, guárdate su identificador y fija esa versión en lugar del alias. Un alias se mueve solo cuando sale una versión nueva.

Y ahora el apartado que menos gusta pero más falta hace.

¿Qué hace Jev francamente mal? ¶

Tres familias de cosas, y TypeSafe las publica sin adornos en su página de limitaciones. Me parece de lo más útil de toda su documentación.

Números y cuentas. No cuenta bien. Ni caracteres de una palabra, ni apariciones de un término, ni elementos de una lista larga. Si necesitas contar, cuenta en tu código: itera y haz una pregunta por elemento, luego suma tú. Tampoco hagas aritmética con la salida de un Score: el número sirve para cruzar un umbral, no para reconstruir una magnitud interpolando entre niveles.

Fechas. Lee las fechas como texto, no como cantidades ordenadas. Preguntarle cuál de dos fechas va antes, o cuántos días hay entre ellas, es pedirle lo que peor se le da. El patrón correcto reparte el trabajo: que el modelo extraiga las piezas (mes, día, año, día de la semana) con Choice sobre conjuntos cerrados, y que tu código haga las cuentas.

Indirección. Cuanto más saltos tenga que dar entre una cosa y otra, peor. Las dobles negaciones, las propiedades de propiedades y las preguntas que exigen encadenar tres razonamientos bajan la calidad. Escribe la pregunta más literal que puedas y nombra en ella las partes del estado a las que te refieres.

A esto súmale dos avisos finos. Uno: Jev lee de forma muy literal, contesta a la pregunta que escribiste y no a la que tenías en la cabeza, así que cuando una respuesta te parezca absurda relee tu propia instrucción antes de culpar al modelo. Dos: el estado grande lleno de campos irrelevantes empeora la precisión, así que filtra antes de mandar en vez de volcar el objeto entero.

🛡️ Y el límite que más vale la pena tatuarse: Jev no ejecuta la regla determinista que tú escribes, emite un juicio probabilístico. Si necesitas que una condición se cumpla siempre, eso es un if de los de toda la vida, no una llamada a un modelo.

¿Funciona igual de bien en español? ¶

No, y es la pregunta que más me importaba de toda esta guía.

La documentación oficial lo dice con todas las letras: el idioma principal de entrenamiento de Jev es el inglés, y el resto de idiomas están aceptados pero con menor precisión hoy. Eso nos afecta de lleno a los que trabajamos con tickets, correos y comentarios en castellano.

No significa que no lo uses. Significa que no des por buenos los umbrales de nadie y midas con tus propios datos.

Lo que me ha funcionado, por orden de rentabilidad:

1. Escribe las instrucciones y los criterios en inglés aunque el estado esté en español. El estado es el contenido de tu negocio y va como viene; las preguntas son tuyas y te cuesta lo mismo escribirlas en inglés.
2. Sube el listón de confianza en las decisiones que importan mientras no tengas medidas propias. Lo que en inglés mandarías a revisión por debajo de 0,5, aquí empieza por 0,7.
3. Etiqueta a mano treinta o cuarenta casos reales tuyos antes de conectar nada a producción. Es media tarde y es la única forma de saber si la calibración aguanta en tu idioma y en tu dominio.

Esa tercera sigue siendo el consejo más aburrido y más rentable de esta guía.

¿Cómo manejo errores y reintentos? ¶

Los SDK ya reintentan por ti con espera progresiva, así que lo que te queda es decidir qué haces cuando se agotan los intentos.

Los códigos que te vas a encontrar son cuatro: 401 si la clave está mal, 422 si el cuerpo no valida (típicamente un Score con menos de dos niveles), 429 si te pasas del límite de tasa y 529 si el servicio está saturado.

import { RateLimitError, APIError, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient({
  timeout: 5000,              // milisegundos por intento
  retry: { maxRetries: 3 },   // reintentos tras el primer intento
});

try {
  const response = await client.systemOne({ state, questions });
  return decidir(response.answers);
} catch (error) {
  if (error instanceof RateLimitError) {
    return encolarParaMasTarde(ticket);
  }
  if (error instanceof APIError) {
    // requestId es lo que le mandas a soporte si algo huele raro
    console.error(error.status, error.requestId);
  }
  // Y lo más importante: qué pasa si Jev no contesta
  return rutaPorDefecto(ticket);
}

Esa última línea es la que se olvida siempre. Si has metido a Jev en el camino de una petición de usuario, tu sistema necesita saber qué hacer cuando el modelo no está. La respuesta correcta casi nunca es «reventar»: es una ruta por defecto conservadora y un aviso.

Construye agentes con criterio

Dónde vive cada decisión cuando el sistema crece

Colocar bien las decisiones es un problema de arquitectura, no de modelo. Verás los seis niveles —tools, guardarraíles, memoria, skills, MCP y orquestación— con código sobre Mastra y Open Code.

Ver la masterclass →

Acceso con suscripción Web Reactiva Premium · 15€/mes · Sin permanencia

¿Dónde meto Jev en mi sistema y dónde no? ¶

La regla que más veces me ha salvado: si ya tienes una señal determinista buena, Jev te va a empeorar el resultado. Una expresión regular que funciona, un campo de base de datos, el orden que ya devuelve tu buscador. Eso no se toca.

Donde sí encaja es en los sitios donde hoy tienes una de estas tres cosas: una lista interminable de if sobre texto, una llamada a un modelo caro para una decisión tonta, o un hueco que rellena una persona a mano. Y si estás montando el sistema desde cero, repasa antes los errores más comunes al construir agentes de IA, porque casi todos se cometen justo en ese reparto.

Sitios concretos por los que yo empezaría:

• Enrutar lo que entra: tickets, correos, formularios, mensajes
• Filtrar antes de generar: decidir qué fragmentos recuperados merecen llegar al modelo grande
• Comprobar en los bordes del sistema: antes de una acción destructiva y antes de dar una respuesta por buena
• Extraer señales de texto libre para alimentar un modelo de los de siempre

Del cuarto punto se habla poco y me parece el más práctico. Convertir texto suelto en columnas numéricas es lo que necesita un modelo clásico de toda la vida para funcionar, y ese puente siempre había sido caro.

Si trabajas con agentes, el sitio natural son los límites del arnés, no una herramienta más que el agente puede decidir no llamar. Una comprobación opcional no es una comprobación. De esto hablamos largo en la guía de harness engineering en 12 pasos.

¿Y si quiero que mi agente de código me ayude con esto? ¶

TypeSafe publica una skill de agente con toda la API dentro, y ahorra bastantes idas y venidas a la documentación.

En Claude Code:

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

En otros agentes:

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

Con la skill instalada, tu agente conoce la forma de la petición y de la respuesta, los tres tipos de pregunta y los patrones de arquitectura. Te evita el clásico de que se invente campos que no existen.

Un aviso de mi experiencia: los agentes tienden a montar una llamada por pregunta, que es justo lo contrario de lo que conviene aquí. Si ves ese patrón en el código que te propone, córtalo y agrupa.

TL;DR ¶

• 🔑 La consola está abierta en console.typesafe.ai: te registras, sacas una clave y pruebas en el playground sin escribir código
• ⚡ Primera llamada real en cuatro líneas con npm install @typesafe-ai/sdk y la clave en TYPESAFE_API_KEY
• 🎯 Tres primitivas: Choice para listas cerradas, Score para escalas que tú describes y Noul para preguntas de sí o no
• 📦 Manda todas las preguntas en una sola llamada: se evalúan en paralelo y el estado se paga una vez, no quince
• ⚠️ No cuenta, no compara fechas y no ejecuta reglas deterministas: eso se queda en tu código
• 🇪🇸 Su idioma de entrenamiento principal es el inglés, así que escribe las preguntas en inglés y mide con tus propios datos antes de fiarte de los umbrales

Preguntas frecuentes sobre cómo empezar con Jev ¶

¿Necesito invitación para usar Jev?
No. La consola de TypeSafe está abierta en console.typesafe.ai: te registras, creas una clave de API y ya puedes usar el playground y los SDK. También está disponible en OpenRouter como typesafe/jev-1.13 y en el AI Gateway de Vercel.

¿Cuánto cuesta probar Jev una tarde?
Céntimos. El precio es de 0,042 dólares por millón de tokens de entrada y la salida no se cobra, porque el modelo devuelve probabilidades en lugar de texto generado. Una sesión de pruebas con documentos normales no llega al dólar.

¿Qué SDK hay disponibles?
Hay SDK oficial para JavaScript y TypeScript (npm install @typesafe-ai/sdk, Node.js 20 o superior) y para Python (pip install typesafe-sdk). También puedes llamar al endpoint HTTP POST /v1/systemone desde cualquier lenguaje.

¿Cuál es la diferencia entre Choice, Score y Noul?
Choice elige una opción de una lista cerrada que tú defines. Score coloca el estado en una escala cuyos niveles describes con palabras. Noul responde una pregunta de sí o no devolviendo la probabilidad del sí. Elige según la forma que necesita tu código, no según cómo suena la pregunta.

¿Cuántas preguntas puedo mandar en una llamada?
Las que quieras dentro del presupuesto de contexto: 64.000 tokens por petición para el estado y todas las preguntas juntas. Se evalúan en paralelo, así que añadir preguntas apenas afecta al tiempo de respuesta y solo suma los tokens de la pregunta.

¿Jev funciona bien en español?
Con menor precisión que en inglés. La documentación oficial reconoce que el inglés es su idioma principal de entrenamiento. Lo práctico es escribir las instrucciones y los criterios en inglés aunque el estado vaya en español, y validar los umbrales con casos etiquetados propios.

¿Puedo usar Jev para contar o para calcular fechas?
No conviene. No cuenta con fiabilidad y lee las fechas como texto en lugar de como cantidades ordenadas. El patrón correcto es que el modelo extraiga las piezas con preguntas de opciones cerradas y que tu código haga la aritmética.

¿Qué pasa si la API falla o me pasa del límite?
Los SDK reintentan con espera progresiva de serie. Los errores típicos son 401 por clave inválida, 422 por cuerpo mal formado, 429 por límite de tasa y 529 por saturación. Lo que tienes que definir tú es la ruta por defecto cuando se agotan los reintentos.

¿Cómo sé si puedo fiarme de la confianza que devuelve?
Midiéndola contra tus propios datos etiquetados. La calibración es la afirmación central de TypeSafe y la que menos evidencia independiente tiene hoy. Empieza con umbrales conservadores, separa un tramo de revisión humana y ajusta según lo que veas.

¿Dónde no debería usar Jev?
Donde ya tengas una señal determinista que funcione, en cualquier condición que deba cumplirse siempre, y en tareas de generación de texto o código. También rinde peor con estados enormes llenos de campos irrelevantes, así que filtra antes de mandar.

Fuentes ¶

• Quick start de TypeSafe — playground, API, SDK y skill de agente
• Primitives (Questions) — los tres tipos de pregunta y cuándo usar cada uno
• Confidence — cómo se deriva la confianza y cómo poner umbrales
• How to build with TypeSafe — el reparto entre código y modelo
• Models — precio, alias, contexto, límites de tasa e idiomas
• Jev 1.13 jaggedness — lo que el modelo hace mal, según TypeSafe
• Parallel questions — la medición de 13 preguntas en una llamada
• SDK de JavaScript y SDK de Python — instalación y referencia
• Agent skill — la skill oficial para tu agente de código

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter