OpenRouter precios: cuánto cuesta realmente Jev Router

Jev Router, el endpoint gestionado typesafe/jev-router de OpenRouter, se lanzó el 25 de septiembre de 2026. Es un endpoint de chat que decide qué modelo debe responder en cada turno. Se trata de un producto distinto tanto del modelo de decisión Jev original como del wrapper CLI de código abierto con un nombre parecido.

OpenRouter precios: la respuesta verificada sobre Jev Router

La respuesta comprobada es más limitada de lo que sugiere la insignia verde de “gratis”: Jev Router se anuncia a $0 tanto para los tokens del prompt como para los de salida, pero el costo total del modelo que selecciona no está documentado con suficiente claridad como para afirmar que todas las sesiones enrutadas son gratuitas.

La página en vivo de Jev Router se revisó el 26 de septiembre de 2026. En sus preguntas frecuentes afirma que el router es gratuito y que no se cobran los tokens del prompt ni los de salida. La página también describe una ventana de contexto de 1,000,000 tokens y un único endpoint que cambia de modelo y de nivel de razonamiento a medida que evoluciona la conversación.

Hay dos datos del catálogo que impiden ser más categóricos. En esa misma fecha, la API de Models pública de OpenRouter devolvía -1, en lugar de un número fijo normal, para el precio de los tokens del prompt y de salida del router. Su registro de endpoint no devolvía endpoints de proveedores. Esos campos legibles por máquina no prueban que exista un cargo, pero tampoco convierten la etiqueta de $0 de la página en una factura desglosada de la sesión.

Este entorno de publicación no tenía una clave autorizada de la API de OpenRouter ni una sesión iniciada en OpenRouter, por lo que no se hizo ninguna solicitud facturable. En consecuencia, esta respuesta no está respaldada por un usage.cost observado ni por un registro en Activity. La decisión presupuestaria defendible es tratar los $0 como el precio anunciado del endpoint y comprobar después la llamada completa antes de prometer inferencia gratuita a un cliente o a un equipo financiero.

Qué cambió realmente el 25 de septiembre

El cambio es que Jev pasó de ser un componente con el que se podía construir un router a convertirse en la capa de decisión de un endpoint de chat gestionado.

Jev 1.13 es un modelo System One: devuelve decisiones restringidas, no texto en prosa. La aplicación le entrega un estado y solicita una decisión tipada de tipo Choice, Score o una pregunta Noul de sí/no. El modelo puede decidir “usar el nivel potente”, pero el código todavía debe llamar a ese nivel, conservar la conversación y contabilizar ambas solicitudes.

El router gestionado concentra ese proceso en typesafe/jev-router. Según el hilo de lanzamiento de OpenRouter, Jev evalúa la dificultad y la precisión del prompt antes de cada turno, valora si un modelo más grande o más razonamiento mejorarían la respuesta y comprueba si la tarea cambió. Después, OpenRouter envía el turno al modelo elegido y devuelve su texto.

Es especialmente fácil confundir el proyecto de código abierto gargpratyush/jev-router con el nuevo endpoint. Ese proyecto ejecuta la CLI real de Claude Code o Codex, toma una decisión con Jev en cada turno nuevo, asigna el resultado a niveles específicos de la cuenta y reenvía la autenticación ya existente de la CLI. No es el slug del modelo gestionado de OpenRouter y su facturación sigue otro recorrido.

La diferencia cambia la arquitectura. El flujo original de Jev aporta una primitiva de decisión. El router DIY añade una política local en torno a las suscripciones de programación. El endpoint gestionado ofrece una sola llamada a la API cuya respuesta la genera un modelo elegido por el propio servicio.

Cómo gestiona Jev Router una conversación

Jev Router está diseñado para no cambiar de modelo solo porque el siguiente mensaje parezca distinto. Es importante porque un cambio puede descartar la conversación almacenada en caché por un proveedor y obligar al nuevo modelo a leer de nuevo todo el historial.

OpenRouter afirma que el router mantiene un modelo que funciona durante el resto de la sesión, puede subir o bajar el nivel de razonamiento sin cambiar de modelo y solo cambia cuando la mejora esperada compensa el costo de la caché que perdería. Para decidirlo, lee el texto de la conversación. El hilo de lanzamiento indica que los archivos adjuntos no se envían a Jev y que se admiten solicitudes con zdr: true.

Esto va más allá de clasificar cada prompt por separado. Un modelo económico puede mantenerse para una consulta de seguimiento sencilla porque conservar su caché quizá valga más que cambiarlo. Un turno difícil puede recibir más razonamiento sin pagar el costo de reiniciar el contexto que supondría mover toda la conversación. Cuando la tarea cambia de verdad, el router puede migrarla.

También existe un límite importante en producción. Si la decisión de Jev agota el tiempo de espera o devuelve una salida no válida, OpenRouter afirma que la solicitud falla en vez de pasar a otro router como respaldo. El proyecto DIY separado, en cambio, funciona en modo fail-open y conserva el modelo actual o uno de respaldo. Por tanto, quien elige el endpoint gestionado incorpora una dependencia nueva en la ruta crítica; no se limita a añadir un optimizador de precios.

Qué cubre la ficha de $0 y qué no demuestra

La ficha de $0 cubre exactamente lo que publica OpenRouter: los precios del prompt y de la salida en la página de Jev Router. No ofrece un desglose de cómo se reflejan dentro de esa cifra un modelo de pago seleccionado, los tokens de razonamiento, las lecturas de caché, las herramientas y la compra de créditos.

Las reglas generales de facturación de OpenRouter indican que una solicitud normal se cobra según la tarifa del modelo y del proveedor seleccionados. Su nueva página de Jev afirma que el router es gratuito. Ninguna fuente aclara de forma explícita si el endpoint gestionado subsidia temporalmente el modelo seleccionado, repercute esa inferencia en una línea separada o aplica algún otro acuerdo propio del lanzamiento. Trasladar aquí la regla habitual de Auto Router sería una suposición, igual que lo sería declarar gratuita toda inferencia de un modelo de pago.

La primera fuente fiable es la propia respuesta. La documentación de contabilidad de uso de OpenRouter indica que cada respuesta incluye información sobre el prompt, la salida, el razonamiento, los tokens almacenados en caché y el costo. usage.cost es el importe total cargado a la cuenta. El campo model de la respuesta identifica el modelo que contestó.

El registro de generación es la segunda fuente. Los Logs de OpenRouter muestran el modelo, el proveedor, el costo, la cantidad de tokens, la latencia, los descuentos de caché, el costo BYOK y los cargos por búsqueda web, recuperación web o procesamiento de archivos. El panel agregado de Activity muestra después el gasto, las solicitudes, los tipos de tokens y la tasa de aciertos de caché, con filtros por modelo, proveedor, clave, aplicación o usuario.

Así, cada importe discutido tiene un lugar donde comprobarse:

• Modelo seleccionado: comparar el model devuelto con usage.cost y el total_cost de la generación.
• Razonamiento: guardar completion_tokens_details.reasoning_tokens y la explicación de routing del turno.
• Reutilización de caché: guardar prompt_tokens_details.cached_tokens y revisar después el detalle de la generación para localizar cualquier descuento de caché.
• Herramientas: excluirlas de la prueba base y leer luego sus líneas separadas en la generación antes de activarlas en producción.
• Comisión de los créditos: asignar aparte la comisión de compra. Las preguntas frecuentes actuales de OpenRouter indican 5.5%, con un mínimo de $0.80, para los créditos pagados con tarjeta y 5% para criptomonedas. Es una comisión de financiación, no una prueba de que Jev Router aplique un recargo.

Los números: una decisión de routing gratis no vuelve gratis la sesión

La línea de la decisión del router ya es mínima. La pregunta económica más importante es si Jev elige un modelo adecuado, conserva una caché útil y produce un resultado aceptado.

Primero, el recorrido anterior con una decisión explícita. Jev 1.13 cuesta $0.042 por millón de tokens de entrada y $0 por millón de tokens de salida. Supongamos 500 tokens de entrada por cada decisión de routing y 100,000 turnos. El resultado son 50 millones de tokens de entrada para Jev, es decir, $2.10 por la capa de decisión. El modelo generativo que responde en cada turno se cobra aparte.

Con la tarifa anunciada en la página gestionada, esa misma línea del router queda en $0. El ahorro aparente es, por tanto, de $2.10 por cada 100,000 decisiones con esta carga de trabajo. Es útil, pero no basta para elegir el producto. Un solo cambio de modelo desacertado puede pesar más que miles de decisiones de Jev.

Pensemos en una conversación con 20,000 tokens previos en el prompt. Con una tarifa ilustrativa de entrada de $2 por millón de tokens para el modelo seleccionado, hacer que un modelo nuevo vuelva a leer ese historial cuesta $0.04 antes de aplicar descuentos de caché o generar una salida nueva. Cincuenta y tres cambios innecesarios cuestan $2.12, algo más que toda la línea de decisiones de Jev 1.13 en el ejemplo de 100,000 turnos.

Ese es el argumento económico duradero a favor de un router que entiende la sesión: conservar la caché adecuada puede importar más que hacer gratuito el clasificador de routing. El cálculo es un escenario explícito, no una afirmación de que Jev Router vaya a elegir un modelo de $2 o a evitar 53 cambios.

La evidencia sobre rendimiento es prometedora, pero incompleta. OpenRouter asegura que Jev Router resolvió 237 frente a 130 de 423 tareas, un 82% más que Auto Router, en cuatro benchmarks de agentes. También afirma que obtuvo una mediana de tiempo hasta el primer token inferior a la de todos los demás routers evaluados en cinco benchmarks de agentes. Son resultados del proveedor, no una reproducción independiente.

Theo Browne aportó un contrapunto útil en un informe de benchmark del 26 de septiembre. Dijo haber gastado $1,000 y haber observado que el rendimiento de DeepSWE era aproximadamente igual al de GPT-6 Astra con un nivel de razonamiento bajo, pero con un precio ligeramente mayor y una espera casi cinco veces más larga. Es un resultado atribuido de un benchmark. No demuestra que exista una comisión de $1,000 por el router, y la publicación no ofrece suficientes datos de facturación por solicitud para resolver la pregunta económica de este artículo.

Para quien compra el servicio, el dato decisivo sigue siendo el costo por tarea aceptada:

(selected-model cost + tools + allocated funding fee + retries + review time) / accepted tasks

Una línea de routing de $0 puede mejorar ese numerador. No puede hacer desaparecer el resto de la ecuación.

Qué implica para equipos de desarrollo, operaciones y compras

Los equipos de desarrollo obtienen una integración más sencilla y una dependencia más exigente. Un solo slug de modelo compatible con OpenAI puede sustituir un clasificador propio, una tabla de políticas, una llamada al modelo y parte de la lógica de sesión. A cambio, el router se interpone antes de cada respuesta. El comportamiento fail-closed documentado obliga a preparar una respuesta en la aplicación ante un fallo de Jev, por ejemplo, reintentar una vez, pedir al usuario que lo intente de nuevo o llamar deliberadamente a un modelo fijo con una política propia.

El registro mínimo útil debe incluir el ID de la respuesta, el slug solicitado, el modelo seleccionado, la razón del routing, el nivel de razonamiento, los tokens del prompt, los tokens almacenados en caché, los tokens de salida, los tokens de razonamiento, usage.cost, la latencia y el resultado. Sin esos campos, un cambio de modelo parece una variación aleatoria del precio y una pérdida de calidad parece un error del agente.

Los equipos de operaciones deben gestionarlo por sesión, no por el precio visible de cada token. Un copiloto de soporte, un agente de investigación o un flujo de programación pueden reunir turnos fáciles, turnos difíciles y un cambio de tarea dentro de una misma conversación. El comportamiento valioso consiste en gastar más solo cuando el turno difícil lo justifica y conservar la caché cuando no. Hay que medir conjuntamente las tareas aceptadas, los reintentos, las correcciones humanas y el total de la sesión.

Los equipos de compras deben separar inferencia, routing y financiación en el presupuesto. Los $0 anunciados del endpoint pertenecen a la línea de routing. El total del modelo seleccionado va en la línea de uso una vez observado. La búsqueda, la recuperación web, el procesamiento de archivos y las demás herramientas se mantienen en líneas propias. La comisión del 5.5% por tarjeta pertenece a la compra de créditos, no a un recargo ficticio por solicitud.

Para entender la factura general de la plataforma, el análisis de precios de OpenRouter ya cubre los créditos compartidos, BYOK y las comisiones de financiación. Para conocer el flujo original del modelo de decisión, Cómo usar Jev explica el routing tipado de tickets y la tarifa de $0.042/M de Jev 1.13.

Quién debería probarlo ya, quién debería esperar y a quién no le cambia nada

Conviene actuar ya si existe un flujo de agente acotado y reversible, se puede limitar el gasto de evaluación a menos de $1 y ya se registra cada generación. Una tarea de programación no crítica, un ciclo interno de investigación o un asistente de soporte en modo shadow son superficies razonables para evaluar. El objetivo no es demostrar que el routing parece inteligente, sino comparar el costo por tarea aceptada y la latencia frente a un modelo fijo con los mismos prompts.

Es mejor esperar si una solicitud de cara al cliente no admite otra dependencia fail-closed, si finanzas necesita una regla de facturación firmada antes de poner en producción una ruta variable o si los prompts contienen datos regulados que aún no superaron una revisión de privacidad. La compatibilidad con retención de datos cero es útil, pero no sustituye la aprobación interna del flujo de datos.

El impacto es mínimo si un solo modelo fijo ya cumple los objetivos de calidad y latencia, si la carga es una decisión tipada y acotada que corresponde a Jev 1.13 o si se enrutan deliberadamente suscripciones de Claude Code y Codex mediante el proyecto DIY local. Un router gestionado no es automáticamente mejor que una llamada directa estable.

Si el control determinista del proveedor importa más que la selección adaptativa, conviene comparar las alternativas a OpenRouter para routing multimodelo antes de trasladar la ruta crítica.

Qué se exagera al decir que Jev Router es gratis

La exageración más clara es afirmar que una ficha de modelo con $0 vuelve gratuito todo el ecosistema de modelos. OpenRouter no ha publicado suficientes detalles de facturación específicos de Jev para sostenerlo, y el catálogo público legible por máquina no muestra una ruta fija convencional.

La exageración opuesta consiste en dar por hecho que debe existir un recargo oculto del router. En esta revisión no se documentó ni se observó ningún recargo. Añadir uno a una previsión sería inventar un dato.

Los benchmarks también exigen perspectiva. La mejora del 82% en tareas que declara OpenRouter es una comparación del proveedor frente a su propio Auto Router. El informe de $1,000 de Theo sobre DeepSWE es el benchmark de una persona frente a una configuración concreta de un modelo fijo. Ningún resultado revela el costo por tarea aceptada del agente de cada usuario ni sustituye una conciliación breve a nivel de cuenta.

Por último, una ventana de contexto de 1,000,000 tokens no vuelve económica una conversación de un millón de tokens. El modelo seleccionado, el comportamiento de la caché, el nivel de razonamiento y los cambios de tarea determinan si una sesión larga resulta eficiente. El límite de contexto indica capacidad, no presupuesto.

La prueba de costos con cuatro solicitudes para el lunes

Cuatro solicitudes sintéticas pequeñas pueden aclarar más que otra semana interpretando páginas de precios. Hay que desactivar las herramientas, evitar datos privados, pedir respuestas breves y detenerse si el usage.cost acumulado se acerca a $1.

La primera solicitud puede usar exactamente este formato:

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-OpenRouter-Metadata: enabled" \
  -d '{
    "model": "typesafe/jev-router",
    "messages": [
      {"role": "user", "content": "Return only the word READY."}
    ]
  }' | tee jev-router-response.json

Después, hay que recuperar los metadatos de la generación correspondiente mediante el ID de la respuesta:

GENERATION_ID=$(jq -r '.id' jev-router-response.json)
curl --get https://openrouter.ai/api/v1/generation \
  --data-urlencode "id=$GENERATION_ID" \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

La regla de decisión es mecánica:

• Si las cuatro respuestas muestran usage.cost: 0, los cuatro registros de generación indican un costo total de cero y la vista Activity de la misma clave no añade gasto, se habrá observado una sesión sintética sin costo en esa cuenta y fecha.
• Si algún registro es distinto de cero, se debe usar el modelo seleccionado y su desglose de costos. Para esa solicitud, el endpoint no es gratuito de principio a fin, independientemente de lo que diga la insignia del catálogo.
• Si la respuesta, la generación y Activity no coinciden, no se debe extrapolar. Hay que guardar los ID y preguntar al soporte de OpenRouter qué registro determina la facturación.

No conviene añadir herramientas hasta conciliar la prueba base. Cuando la búsqueda, la recuperación web o el procesamiento de archivos se incorporen al agente, hay que repetir una solicitud controlada y tratar esas líneas de la generación como costos separados. No deben inferirse a partir de la ficha del modelo Jev Router.

La tarea del lunes es ejecutar esas cuatro solicitudes junto a cuatro controles con un modelo fijo y comparar el costo de la sesión, la latencia, las respuestas aceptadas y la tasa de fallos. Jev Router solo debe adoptarse si la decisión de routing mejora el resultado completo, no porque una fila del catálogo contenga dos ceros.

Recibe el próximo cambio verificado en el routing de modelos y su consecuencia presupuestaria en el boletín.