¿Puede Jev reducir el costo de los agentes de IA? Un cálculo completo desde el enrutamiento de modelos hasta la verificación de resultados

Resumen

Una llamada a Jev es barata, pero añadir un modelo de decisión de bajo costo a un agente de IA no hace que toda la tarea sea automáticamente más barata.

La pregunta real es si Jev puede desviar parte de las solicitudes hacia código determinista o un modelo más económico, reducir el contexto enviado al modelo principal y evitar reintentos inútiles mediante la verificación de resultados. Al mismo tiempo, sus errores de clasificación, su latencia, la revisión humana y el mantenimiento de ingeniería también generan costos.

Este artículo desglosa tres arquitecturas habituales —enrutamiento de modelos, filtrado de contexto y verificación de resultados— y propone un marco completo para responder una pregunta práctica: ¿cuándo puede Jev reducir el costo total de un agente y cuándo se limita a añadir otra llamada de API?

---

Muchos problemas de costo en los agentes de IA parecen deberse a que el modelo principal es demasiado caro. En la práctica, el problema más profundo suele ser que el flujo de trabajo no distingue entre distintos tipos de tareas.

Una solicitud como «Consulta el estado de mi pedido» quizá solo necesite una búsqueda en la base de datos. Una petición como «Analiza las causas de las anomalías de los pedidos durante los últimos seis meses» puede requerir un modelo potente que sintetice varias fuentes. Otras solicitudes no contienen suficiente información, por lo que el paso más razonable no es llamar a ningún modelo, sino pedir una aclaración al usuario.

Si todas las solicitudes se envían directamente al mismo modelo potente, el sistema sigue siendo sencillo, pero paga el mismo precio por muchas tareas que podría haber resuelto el código convencional o un modelo pequeño.

Jev propone otro enfoque.

No está diseñado para conversar ni para generar textos largos. El desarrollador le entrega un state y formula un conjunto de preguntas tipadas; Jev devuelve decisiones estructuradas y probabilidades, como Choice, Score o Noul. A continuación, la lógica de negocio decide si debe llamar a una herramienta, utilizar un modelo más económico, escalar a un modelo más potente o enviar el caso a una persona. TypeSafe presenta Jev como el primer modelo System One: un modelo diseñado específicamente para tomar decisiones rápidas y estructuradas dentro del software. (typesafe.ai)

Desde el punto de vista del precio, este tipo de decisión parece casi insignificante.

Cuando lanzó Jev, TypeSafe publicó un precio de 0,042 dólares por millón de tokens de entrada, sin cobrar los tokens de salida. La empresa también declaró una latencia típica de extremo a extremo de 70 a 500 milisegundos, aunque indicó que esas cifras procedían de regiones y condiciones de prueba concretas y que no debían considerarse representativas de todos los entornos de despliegue. (typesafe.ai)

El problema es el siguiente:

Una decisión barata no abarata automáticamente todo el flujo de trabajo del agente.

Que Jev ahorre dinero depende de si cambia lo que sucede después, no solo de lo poco que cuesta la llamada a Jev.

La factura real de un agente de IA incluye más que las tarifas del modelo

Completar una tarea con un agente suele generar al menos seis tipos de costos:

Categoría de costo	Qué incluye
Costo de decisión	Clasificación de intención, enrutamiento de modelos, evaluación de riesgos y decisión sobre si hace falta una herramienta
Costo de contexto	Historial de conversación, resultados de búsqueda, salida de herramientas, registros y documentos
Costo de generación	Tokens de entrada, salida y razonamiento del modelo principal
Costo de reintentos	Tiempos de espera del modelo, fallos de herramientas, errores de formato y nueva generación
Costo humano	Revisión, corrección, gestión de excepciones y aprobación de acciones de alto riesgo
Costo de decisiones erróneas	Corrección de una ruta incorrecta, información omitida o ejecución de una acción equivocada

Por tanto, un costo por tarea más completo puede expresarse así:

Costo total
= costo de decisión
+ costo de procesamiento del contexto
+ costo de modelos y herramientas posteriores
+ costo de reintentos y rutas alternativas
+ costo de revisión humana
+ costo de corregir las consecuencias de decisiones erróneas

La llamada a Jev suele representar solo una fracción muy pequeña de ese total.

La verdadera oportunidad está en reducir lo que viene después: evitar una llamada al modelo caro, no enviar contexto irrelevante, impedir que una tarea fallida se ejecute de nuevo o permitir que las personas revisen solo los casos realmente inciertos.

Los patrones de ahorro más comunes pueden agruparse en tres categorías:

1. Enrutamiento previo: decidir primero y después elegir qué llamar.
2. Filtrado de contexto: eliminar información innecesaria antes de llamar al modelo principal.
3. Verificación posterior: dejar que actúe primero un modelo barato y escalar solo cuando la verificación falle.

---

Primera forma de ahorrar: colocar Jev delante del modelo principal como enrutador

La arquitectura más directa es:

Solicitud del usuario
   ↓
Jev evalúa la intención, la complejidad y el riesgo
   ↓
Código determinista / modelo barato / modelo potente / persona

El patrón oficial de enrutamiento de TypeSafe sigue la misma idea: no todas las solicitudes tienen que entrar en el mismo LLM. Algunas pueden ir a código determinista, otras a un modelo especializado, y las solicitudes complejas o de alto riesgo pueden escalarse a un modelo más caro o a una persona. (docs.typesafe.ai)

Por ejemplo, un agente de soporte podría determinar primero:

• ¿Es solo una consulta sobre el estado de un pedido?
• ¿Implica un reembolso o un contracargo?
• ¿Debe ir a facturación, soporte técnico o ventas?
• ¿Requiere intervención humana?
• ¿Necesita realmente un modelo de razonamiento de frontera?

Jev solo toma esas decisiones.

La consulta a la base de datos, la operación de reembolso, la generación de la respuesta y la gestión humana del ticket siguen siendo responsabilidad del sistema que lo rodea.

¿Cuánto cuesta una decisión de enrutamiento?

En una prueba real de API registrada en el material de referencia, se incluyeron diez tickets de soporte en una sola solicitud. Cada ticket se evaluó para determinar su ruta y si requería revisión humana, con un total de 20 preguntas:

• Entrada total: 2.571 tokens;
• Duración de la llamada: unos 405 milisegundos;
• Costo total al precio público: aproximadamente 0,000108 dólares;
• Costo medio por ticket: aproximadamente 0,0000108 dólares;
• Extrapolado con el mismo perfil de tokens: aproximadamente 10,8 dólares por millón de tickets.

Cuando los mismos diez tickets se enviaron mediante diez llamadas separadas, el tiempo total fue de unos 3.664 milisegundos. Los resultados principales de enrutamiento permanecieron iguales, pero algunas probabilidades de los casos limítrofes cambiaron de manera apreciable. Esto demuestra que el procesamiento por lotes puede reducir mucho la sobrecarga de las solicitudes, pero no demuestra la precisión del enrutamiento en todos los dominios ni que el mismo umbral sea adecuado para compuertas de alto riesgo.

El punto de equilibrio del enrutamiento de modelos

Supongamos que:

• C_high: costo de una llamada al modelo potente;
• C_low: costo de una llamada al modelo barato;
• C_jev: costo de la decisión de Jev;
• P_code: proporción de solicitudes que puede resolver el código determinista;
• P_low: proporción de solicitudes que puede resolver el modelo barato;
• P_error: proporción de solicitudes que necesitan corrección porque el enrutamiento fue incorrecto.

Si todas las solicitudes se envían directamente al modelo potente, el costo esperado es:

C_direct = C_high

Después de añadir el enrutamiento, el costo esperado pasa a ser:

C_route
= C_jev
+ P_low × C_low
+ P_high × C_high
+ P_error × C_repair

Por tanto, el enrutamiento solo ahorra dinero cuando:

Costo del modelo potente evitado
>
costo de Jev + costo de corregir errores de enrutamiento

Como Jev es barato, la economía final suele depender de dos preguntas:

1. ¿Cuántas solicitudes pueden evitar realmente el modelo potente?
2. ¿Cuánto cuestan las consecuencias de los errores de enrutamiento?

Un cálculo puramente ilustrativo

Los siguientes precios solo sirven para explicar la lógica y no representan las tarifas reales de ningún modelo concreto:

• Modelo potente: 0,01 dólares por llamada;
• Modelo barato: 0,002 dólares por llamada;
• Jev: aproximadamente 0,0000108 dólares por llamada;
• Volumen total: 100.000 solicitudes.

Supongamos que, después del enrutamiento:

• El 20% se completa con código determinista;
• El 50% va al modelo barato;
• El 30% va al modelo potente;
• Un 5% adicional requiere una llamada de corrección al modelo potente por un error o un fallo.

Entonces:

Concepto	Costo
Sin enrutamiento: todas las solicitudes usan el modelo potente	1.000 dólares
100.000 decisiones de Jev	1,08 dólares
50.000 llamadas al modelo barato	100 dólares
30.000 llamadas al modelo potente	300 dólares
5.000 llamadas de corrección	50 dólares
Costo total después del enrutamiento	451,08 dólares

Con estas hipótesis, el costo total disminuye aproximadamente un 55%.

Pero si solo el 10% de las solicitudes puede ir al modelo barato, el 90% termina igualmente en el modelo potente y otro 5% necesita corrección, el costo total sería de unos 971,08 dólares.

El ahorro sería de aproximadamente un 2,9%.

Si además se incluyen el desarrollo, la monitorización, la calibración de umbrales y la latencia adicional, quizá ya no compense construir esta capa de enrutamiento.

Por eso, lo primero que debe medirse no es el precio unitario de Jev, sino:

¿Qué porcentaje de su tráfico real no necesita realmente un modelo potente?

---

Segunda forma de ahorrar: reducir el contexto enviado al modelo principal

El contexto es otra gran fuente de costo para los agentes.

Un agente de larga duración puede acumular:

• Historial de conversación;
• Varias rondas de salida de herramientas;
• Registros de Bash o de compilación;
• Contenido de páginas web;
• Fragmentos recuperados por búsqueda;
• Planes y resultados intermedios que ya han quedado obsoletos.

Muchos sistemas reenvían todo esto al modelo principal. Aunque la tarea actual solo necesite una pequeña parte, se pagan todos los tokens de entrada.

Jev puede colocarse antes del modelo principal para decidir:

• Qué resultados de búsqueda son relevantes para la pregunta actual;
• Qué salidas de herramientas podrían seguir siendo útiles;
• Qué mensajes anteriores contienen restricciones o tareas pendientes;
• Qué fragmentos podrían contener prompt injection;
• Qué información puede eliminarse o conservarse solo como resumen.

El mapa oficial de casos de uso de TypeSafe también incluye selección de contexto, recuperación semántica, filtrado de fragmentos RAG y gestión de contexto dentro de agent harnesses. (docs.typesafe.ai)

El efecto económico puede aproximarse así:

Beneficio neto del contexto
= tokens eliminados × precio de entrada del modelo principal
- costo del filtrado con Jev
- costo de recuperación y reintentos causado por información omitida

Los dos primeros términos son fáciles de calcular. El tercero suele ignorarse.

Eliminar decenas de líneas de registro irrelevantes suele ser una ganancia clara. Eliminar una restricción importante del usuario en un mensaje anterior puede hacer que el modelo principal produzca un resultado completamente incorrecto, lo que obliga a recuperar información, volver a llamar al modelo o corregir el resultado manualmente.

Una sola repetición puede consumir el ahorro de muchas operaciones de filtrado exitosas.

Por eso, Jev es más adecuado para decidir qué material probablemente es relevante que para actuar como único gestor permanente de memoria. Un sistema de producción debería, como mínimo:

• Conservar siempre las instrucciones del sistema, las restricciones firmes del usuario y las reglas de seguridad;
• Guardar un índice o una copia original del contenido eliminado;
• Permitir que el agente recupere el material omitido cuando la información resulte insuficiente;
• Evaluar el éxito mediante el resultado de la tarea posterior, no solo mediante la tasa de compresión.

Para la compresión de contexto, la cantidad más significativa es:

Tokens totales después de la compresión
+ tokens de nueva recuperación
+ tokens de reintentos causados por omisiones

no solo «cuántos tokens se eliminaron en este turno».

---

Tercera forma de ahorrar: dejar que actúe primero un modelo barato y usar Jev para verificar

En otra arquitectura habitual, Jev no decide qué modelo llamar. En su lugar, comprueba el resultado de otro modelo.

El flujo es el siguiente:

El modelo barato genera un resultado
       ↓
Jev comprueba soporte factual, campos extraídos, riesgo de políticas o grado de finalización
       ↓
Aprobado: utilizar el resultado
Rechazado: reintentar, escalar al modelo potente o enviar a una persona

TypeSafe denomina Universal Verification a esta clase de patrones. Sus materiales oficiales incluyen comprobación de citas en RAG, validación de llamadas a herramientas, evaluación de calidad de resultados y cascadas de extracción de datos estructurados. El ejemplo oficial SDE Cascade utiliza «extracción con modelo barato → verificación campo por campo con Jev → escalado a un modelo de razonamiento solo cuando aparece una señal de alerta». Son resultados de un cookbook del proveedor y no deben interpretarse como prueba de que todas las tareas de extracción conseguirán el mismo ahorro. (docs.typesafe.ai)

El costo esperado de esta cascada es aproximadamente:

C_cascade
= C_low
+ C_jev
+ P_escalate × C_high
+ C_failure

La variable principal es P_escalate: la proporción de resultados del modelo barato que de todos modos deben pasar al modelo potente.

Si se ignora el costo de los fallos, la cascada es más barata que enviar todo directamente al modelo potente cuando:

P_escalate
<
1 - (C_low + C_jev) / C_high

Utilicemos los mismos precios hipotéticos:

• Modelo potente: 0,01 dólares;
• Modelo barato: 0,002 dólares;
• Jev: aproximadamente 0,0000108 dólares.

La tasa de escalado de equilibrio es de aproximadamente el 80%. Es decir, mientras menos de aproximadamente el 80% de las solicitudes terminen escalando, la factura nominal de modelos puede seguir siendo inferior al escenario «modelo potente para todas las solicitudes».

Pero ese es el punto de equilibrio del precio, no el de la calidad.

«Cerca del modelo potente» y «la misma calidad que el modelo potente» son objetivos económicos distintos

Una evaluación independiente prerregistrada probó una cascada Jev → modelo potente sobre una muestra de CLINC150:

• Cuando se permitió que la precisión final fuera un punto porcentual inferior a la del modelo potente, Jev solo tuvo que escalar aproximadamente el 22% de las solicitudes;
• Cuando se exigió exactamente la misma precisión que el modelo potente, la cascada tuvo que escalar todas las solicitudes y, en la práctica, se convirtió en «llamar siempre al modelo potente».

Los investigadores subrayaron que el resultado debía interpretarse como «acercarse a la calidad del modelo potente a menor costo», no como «conseguir idéntica calidad con menos llamadas». El experimento utilizó solo 200 muestras, un dataset y una ruta de servicio, por lo que no puede generalizarse directamente a otros agentes. Sin embargo, ilustra un patrón económico importante: un pequeño aumento del objetivo de calidad puede provocar un gran salto en la tasa de escalado. (github.com)

Por tanto, una evaluación de cascada no puede limitarse a informar:

• Cuántas llamadas al modelo potente se evitaron;
• Qué porcentaje del tráfico se gestionó automáticamente.

También debe informar:

• La precisión del subconjunto gestionado automáticamente;
• La tasa final de éxito de extremo a extremo;
• Cuánta calidad se pierde frente a enviar todo al modelo potente;
• Qué errores se amplifican en las etapas posteriores.

---

Hacer varias preguntas en una llamada suele ser más importante que agrupar las solicitudes

Jev permite hacer varias preguntas sobre un mismo state y devolver las respuestas en paralelo. La documentación oficial recomienda descomponer una decisión compleja en preguntas atómicas y combinar los resultados en código, en lugar de introducir varios juicios dentro de una pregunta ambigua. (docs.typesafe.ai)

Por ejemplo, en lugar de preguntar:

¿Cómo debe gestionarse este ticket de soporte?

Conviene dividirlo en:

• ¿A qué cola de negocio debe enviarse?
• ¿Solicita explícitamente un reembolso?
• ¿Menciona un contracargo, una acción legal o un regulador?
• ¿En qué nivel de urgencia se encuentra?
• ¿Necesita intervención humana?
• ¿Vale la pena llamar a un modelo más potente?

En las mediciones del material de referencia, aumentar un mismo state de una pregunta a ocho y después a 32 mantuvo la latencia, tras el calentamiento, aproximadamente dentro del mismo rango de 350–400 milisegundos. Los tokens de entrada aumentaron con el número de preguntas, pero los viajes de red no crecieron linealmente.

Por tanto, un patrón razonable es:

Hacer en una sola solicitud todas las preguntas atómicas que sean realmente necesarias para el paso actual, en lugar de enviar una llamada de API distinta por cada decisión.

Sin embargo, agrupar no significa introducir a todos los usuarios, todos los documentos y todas las tareas en un state gigantesco. El experimento con tickets también mostró que la agrupación mediante arrays conservó las clasificaciones principales, pero desplazó algunas probabilidades limítrofes.

La estrategia de batching debe seguir validándose con la distribución real de datos de la aplicación.

---

Cuatro costos ocultos fáciles de omitir

1. confidence no es precisión

La salida tipada puede garantizar que la respuesta cumple la interfaz, pero no que la decisión de negocio sea correcta.

Una evaluación independiente encontró que, entre 200 muestras, Jev devolvió un confidence exactamente igual a 1.0 en 102 casos, y seis de ellos eran incorrectos. Los investigadores tampoco encontraron que la confianza de Jev fuera mejor que la confianza autodeclarada de un LLM pequeño para ordenar sus propios errores. (github.com)

Eso significa que la lógica de producción no debería reducirse a:

if (confidence === 1) {
  executeDestructiveAction();
}

Un enfoque más seguro consiste en:

• Dar prioridad a las probabilities de cada opción cuando se necesita una regla concreta;
• Elegir umbrales sobre un conjunto etiquetado específico de la aplicación;
• Utilizar umbrales distintos para niveles de riesgo distintos;
• Mantener confirmación humana para pagos, borrados, suspensiones y acciones similares;
• Registrar versión del modelo, probabilidades y resultado final para vigilar el drift.

Otra evaluación prerregistrada de calibración también produjo resultados mixtos: el ECE fue de 0,0204 en CLINC150 y de 0,0936 en Banking77, con sobreconfianza sistemática en el segundo. Esto indica que la calibración depende de la tarea y del corpus; un umbral ajustado para un dataset no debe trasladarse directamente a otro dominio de negocio. (systemonemodels.org)

2. Los errores de enrutamiento no son gratis

Si un enrutador envía una solicitud sencilla al modelo potente, la consecuencia principal puede ser que se pierde una oportunidad de ahorro. Si envía una solicitud compleja a código determinista, el resultado puede ser una respuesta incorrecta, trabajo duplicado o abandono del usuario.

En tareas de alto riesgo, el costo de una sola decisión errónea puede superar el costo de todas las llamadas de modelo implicadas.

Por eso conviene registrar por separado cuatro tipos de error:

• Escalado falso: una solicitud que podía gestionarse de forma barata se envía al modelo potente;
• Degradación falsa: una solicitud que necesitaba el modelo potente se asigna a una ruta barata;
• Aprobación falsa: el verificador no detecta un resultado defectuoso;
• Bloqueo falso: un resultado correcto se obliga a reintentarse o pasar por revisión humana.

Una única cifra de precisión agregada no representa el costo de estos cuatro errores.

3. La latencia y los fallos también son costos

En el material de referencia, las llamadas seriales tras el calentamiento estuvieron en su mayoría alrededor de 340–450 milisegundos. En una prueba con 24 solicitudes concurrentes, la latencia mediana aumentó a aproximadamente 1,2 segundos y se produjeron tres fallos de transporte. Fue una prueba pequeña en un entorno concreto y no describe la disponibilidad general del servicio oficial, pero basta para demostrar que una arquitectura de producción no puede tratar la capa de decisión como una función local infalible.

Como mínimo, el sistema debe definir de antemano:

• Si un timeout provoca fail-open, fail-closed o escalado humano;
• Si se reintenta y cuántas veces;
• Si la indisponibilidad de Jev debe provocar una llamada directa al modelo principal;
• Si un fallo del servicio de enrutamiento puede bloquear al agente completo;
• Si las latencias p95 y p99 siguen encajando en el presupuesto de interacción del producto.

Una evaluación prerregistrada de terceros observó una mediana por llamada de Jev de aproximadamente 0,42–0,44 segundos, y señaló explícitamente que ese dato reflejaba un cliente, gateway, región y carga concretos, no la velocidad pura de inferencia del modelo. (github.com)

4. Si ya hay datos etiquetados, Jev quizá no sea la opción más barata

Una ventaja importante de Jev es el arranque en frío: cuando no hay datos etiquetados, puede tomar decisiones zero-shot a partir de descripciones en lenguaje natural.

Pero si un proceso estable ya ha acumulado muchos ejemplos etiquetados por personas, un modelo pequeño convencional puede resultar más atractivo.

En una evaluación prerregistrada de Banking77, un modelo de embeddings bge-small congelado más regresión logística, entrenado con 10.003 ejemplos, alcanzó una precisión de 0,933, mientras que Jev alcanzó 0,832. El encoder funcionó en unos 9 milisegundos en el hardware de prueba y no tenía costo de API por solicitud. Los investigadores también subrayaron que las condiciones de información eran diferentes: el encoder había visto un gran conjunto etiquetado de la misma distribución, mientras que Jev se evaluó zero-shot. Por tanto, no era una comparación de capacidad bajo las mismas condiciones, sino una comparación entre alternativas de despliegue realistas. (github.com)

Una ruta práctica de evolución puede ser:

Etapa	Opción que conviene evaluar
No hay datos etiquetados y las reglas cambian con frecuencia	Un modelo de decisión zero-shot como Jev
Se ha acumulado un pequeño conjunto etiquetado	Jev + calibración de umbrales + revisión humana
Las etiquetas son estables y existe un gran dataset	Encoder local, clasificador o modelo ajustado
Las tareas de larga cola siguen cambiando	Mantener Jev como fallback

Jev puede ser especialmente útil como acelerador del arranque en frío y capa de decisión para la larga cola, sin que tenga que ser el destino permanente de todas las tareas estables de clasificación.

---

Cómo calcular la economía antes del lanzamiento

Empiece con un conjunto de tareas históricas de la aplicación real y compare offline tres rutas:

A. Enviar todas las tareas al modelo potente
B. Enrutamiento de Jev → código / modelo barato / modelo potente
C. Modelo barato → verificación con Jev → escalado al modelo potente cuando sea necesario

Como mínimo, registre estas métricas:

Métrica	Pregunta que responde
Costo total medio	¿Cuánto costó realmente cada tarea completada con éxito?
Tasa de llamadas al modelo potente	¿Cuántas llamadas caras evitó Jev de verdad?
Cobertura de gestión automática	¿Cuántas tareas evitaron tanto a las personas como al modelo potente?
Precisión de las tareas gestionadas automáticamente	De las tareas automatizadas, ¿cuántas fueron realmente correctas?
Tasa de escalado	¿Cuántas tareas de la cascada terminaron igualmente en el modelo potente?
Tasa de reintentos	¿Cuántas llamadas adicionales causaron los errores de enrutamiento o verificación?
Tasa de revisión humana	¿Se redujo el trabajo humano o solo se trasladó a otro punto?
Latencia p95	¿Qué latencia de cola experimentaron realmente los usuarios?
Tasa de éxito de extremo a extremo	¿Cayó la calidad final por debajo de la línea base?

La métrica más significativa no es «precisión de las decisiones de Jev», sino:

Costo por tarea completada con éxito

Incluso una API de decisiones extremadamente barata puede empeorar la economía del agente si provoca más reintentos, revisión humana o ejecución incorrecta.

---

Cuándo merece la pena probar Jev primero

Cuantas más de las siguientes condiciones se cumplan, más probable es que Jev genere valor práctico:

• El volumen de solicitudes es alto y las decisiones son frecuentes;
• Los límites de la tarea están claros y pueden dividirse en preguntas semánticas de un solo paso;
• Muchas solicitudes pueden resolverse con código determinista o un modelo barato;
• Todavía no hay suficientes datos etiquetados para entrenar un clasificador dedicado;
• La llamada al modelo principal es sustancialmente más cara que la llamada de decisión;
• Los errores pueden contenerse mediante escalado, reintento o revisión humana;
• El sistema puede registrar probabilidades, umbrales y resultados finales;
• Los criterios de decisión deben añadirse o modificarse rápidamente.

Por el contrario, añadir Jev no debería ser la primera medida cuando:

• Casi todas las solicitudes terminan necesitando el modelo potente;
• El tráfico es bajo y el ahorro de API no compensa la complejidad de ingeniería;
• La tarea requiere razonamiento de varios pasos, aritmética, comparación de fechas o generación de texto largo;
• Una decisión incorrecta puede ejecutar directamente una acción irreversible;
• Ya existe un conjunto etiquetado grande y estable con el que entrenar un modelo local pequeño;
• No se pueden construir rutas fiables de fallback y revisión humana;
• El plan consiste en copiar directamente a producción los umbrales de una demostración oficial.

---

Conclusión: Jev no ahorra en la decisión, sino en el trabajo que viene después

Una llamada a Jev es realmente barata, pero eso no determina si reducirá el costo de un agente de IA.

Su verdadero valor consiste en dividir un flujo de trabajo que, de otro modo, enviaría todo a un único modelo potente:

• Las solicitudes sencillas van a código determinista;
• Las solicitudes rutinarias van a un modelo barato;
• Las solicitudes complejas van al modelo potente;
• Las solicitudes inciertas van a una persona;
• El contexto redundante no se envía;
• Los resultados defectuosos se detienen antes de llegar al usuario.

Si Jev se coloca delante del modelo principal pero todas las solicitudes siguen llegando a ese modelo, solo habrá añadido otra llamada de API.

Si reduce de forma fiable las llamadas caras, el tamaño del contexto o el trabajo repetido, se convierte en una verdadera palanca de costos.

Por tanto, la pregunta correcta no es:

¿Cuánto cuesta una llamada a Jev?

Sino:

Después de esta decisión, qué trabajo caro dejó de tener que hacer el sistema?

Esa es la cuenta completa que debe calcular un agente de IA.