Jev redujo el coste de este agente de IA en un 61%

En julio escribí que los modelos pequeños deberían decidir qué ven los modelos grandes: no se trata de redirigir una tarea a un modelo más barato, sino de colocar modelos pequeños junto al grande para elegir qué tokens llega a leer. Terminé aquel artículo diciendo que la economía era un motivo para experimentar, pero no una prueba, y que alguien tenía que hacer la prueba.

Entonces Jev se lanzó el 15 de septiembre. Es el primer modelo System One de TypeSafe: no escribe texto en absoluto, devuelve probabilidades calibradas sobre respuestas que define tu código, cuesta $0.042 por millón de tokens de entrada y responde en unos pocos cientos de milisegundos. Esa combinación hace que dos versiones muy concretas de la idea de julio sean lo suficientemente baratas como para medirse realmente.

Así que probé esas dos.

Precarga de habilidades. Un agente al que se le da un catálogo de documentos internos gasta todo un viaje de ida y vuelta decidiendo cuál leer y llamando a una herramienta para obtenerlos. Jev puede tomar esa decisión antes del primer turno, por una fracción de centavo, y los documentos llegan ya integrados en el prompt.

Filtrado de la carga útil (payload) de la herramienta. Una respuesta de API real consiste mayormente en campos sobre los que ningún agente actuará y, en una configuración MCP, todo eso cae en la ventana de contexto y se vuelve a enviar en cada turno siguiente. Jev puede puntuar cada campo de una respuesta antes de que el agente la vea.

Ambos son problemas de clasificación, no de escritura. Esto es lo que ocurrió en 192 ejecuciones de 8 tareas, con precios basados en Claude Opus 5:

La mejor tarea resultó un 61% más barata. La media de las ocho es del 29%, y la peor del 13%. El 99% de los controles de calidad pasaron en cada variante, incluida la simple, por lo que no se sacrificó nada para lograrlo.

Todo el experimento costó $1.17 ejecutarlo.

Qué es Jev

No genera texto. Le envías un state y un conjunto de preguntas tipadas, y devuelve una distribución de probabilidad calibrada sobre las respuestas que definió tu código. TypeSafe lo llama un modelo System One, entrenado con lo que describen como aprendizaje por refuerzo para decisiones calibradas.

La propiedad que hace que este experimento funcione es el procesamiento por lotes (batching). Cada pregunta va en una sola llamada HTTP con el state enviado una vez. Puntuar 264 campos de un payload es una sola solicitud, no 264.

Mecanismo uno: precarga de habilidades

Antes del primer turno del agente, Jev lee la solicitud y la descripción de una línea de cada habilidad. Nunca ve el cuerpo de una habilidad. Cualquier cosa que puntúe 0.55 o más se inyecta completa en el prompt del sistema.

La herramienta read_skill sigue disponible, por lo que el agente aún puede buscar cualquier cosa que el router haya omitido. Esto es importante, porque el router sí omite cosas.

Mecanismo dos: filtrado de la carga útil de la herramienta

Después de que una herramienta devuelva un resultado y antes de que su salida llegue al agente, cada campo hoja de la respuesta es puntuado según su relevancia para la solicitud actual. Cualquier campo por debajo de 0.35 se elimina.

Vale la pena notar en esas puntuaciones: los campos que se cortan en esta llamada están entre 0.31 y 0.34 y los que se quedan están entre 0.35 y 0.37. El límite es realmente un límite, y algunos campos lo cruzan entre ejecuciones. trial_end puntuó 0.34 en una ejecución y 0.37 en otra. Nada de lo que la tarea necesitaba estuvo nunca cerca.

De dónde viene realmente la seguridad

Ese tercer paso, el estado, es donde se decide todo. El mismo umbral con un estado pobre es peligroso. Con uno más rico es, a la vez, más seguro y más agresivo.

Medido aisladamente en el campo que decide la tarea de dunning:

Las dos columnas centrales son las puntuaciones dadas al campo del que la tarea realmente depende. La última es cuántos de los 124 campos sobreviven al corte de 0.35.

Añadir las habilidades no cambia nada. El historial ayuda un poco. El detonante es la lista de acciones restantes. Hasta que el calificador no sabe que hay una llamada a billing_set_account_state(account_id, …) esperando, un id de cuenta es solo otra cadena de texto.

La forma general de esto, que es la parte aplicable a otra configuración:

Un campo no es útil por sí mismo. Es útil por lo que el agente está a punto de hacer con él, y esa información no está en el payload. Está en el esquema de las herramientas que aún están disponibles.

Dónde están las ganancias, y dónde no

Los dos mecanismos rastrean cosas completamente diferentes, y saber cuál se aplica a tu carga de trabajo importa más que la media.

La dispersión es amplia. En la tarea donde llegan seis artículos del centro de ayuda y solo importa updated_at, el filtrado elimina el 84% del payload y el 63% de los tokens de entrada. En la tarea de incidentes, donde casi cada campo se usa, elimina el 5%. Mismo agente, mismo umbral, un factor de 17 entre ellas.

Coste en Opus 5, por tarea, agente simple frente a ambos mecanismos:

Un agente Opus 5 que gestione 10,000 tareas al mes pasa de $419 a $299, de los cuales $9 van a Jev.

El precio de tu modelo principal decide si el filtrado merece la pena

Este es el resultado que debería cambiar lo que haces.

El filtrado consume tokens de Jev en cada llamada a la herramienta. Esos tokens tienen un precio fijo. Los tokens que ahorra tienen el precio de lo que cueste el modelo de tu agente. Por lo tanto, todo es una proporción, y esta cambia.

Los recuentos de tokens son los mismos en todo momento. Solo cambia la tarifa del agente. En el modelo barato Jev representa el 42% de la factura y el filtrado cuesta más de lo que ahorra. En Opus 5 es el 3% de la factura.

Calculando el punto de equilibrio, manteniendo los recuentos de tokens medidos y la estructura de tarifas habitual, se sitúa en $0.55 por millón de tokens de entrada con el almacenamiento en caché de prompts activado, y $0.37 sin él. Por debajo de eso, no filtres. Por encima, filtra.

La precarga de habilidades es rentable en todas partes, incluso en el modelo más barato, porque no cuesta casi nada: unos 1,500 tokens de Jev por ejecución, $0.00006, frente a un turno ahorrado.

Hay un efecto de segundo orden que conviene conocer. El almacenamiento en caché reduce aproximadamente a la mitad la factura y disminuye el valor relativo del filtrado, porque la mayor parte de lo que el filtrado elimina habrían sido lecturas de caché baratas. El filtrado es más valioso para un despliegue sin caché que para uno con ella.

El modo de fallo

El umbral de 0.35 solo es seguro gracias al estado rico. Una versión anterior sin él produjo el peor tipo de fallo.

El filtro eliminó account.id de una suscripción de Stripe, puntuándolo con 0.18, y también eliminó metadata.account_id, la segunda copia. El agente tomó el único identificador restante y hizo esto:

llamada:   billing_set_account_state(account_id="cus_PmT4k9WqLr2XbN", state="read_only")
                                              ↑ el id de cliente de Stripe, no el de la cuenta

informe: "He puesto la cuenta asociada en modo lectura, de acuerdo con la política del día 10."

El identificador correcto era acct_borealis_4c77. El agente actuó sobre el objeto equivocado y presentó un informe seguro al respecto.

Cualquier cosa que despliegues necesita rutas críticas declaradas y un umbral calibrado contra ellas. Dos centésimas de umbral separaron “ahorrar un turno” de “no ahorrar nada” en la parte del enrutamiento, y una brecha mucho mayor en la parte del filtrado.

Lo que extraigo de esto

Trabajar en la eficiencia de la IA merece la pena, y combinar modelos de diferentes tamaños y tipos es donde reside gran parte de ella. Lo interesante es que un modelo que no puede escribir texto en absoluto resulta ser un buen juez de lo que un modelo que escribe texto debería tener permitido ver.

Aquí se probaron dos puntos de partida. Hay muchos más lugares donde el mismo patrón podría aplicarse: elegir qué archivos abre un agente, decidir cuándo debe compactarse una conversación, puntuar si un documento recuperado merece sus tokens, bloquear una escritura antes de que ocurra. Nada de eso se midió, y no asumiría que funciona hasta que se compruebe.

El registro completo está más abajo: el entorno, cada tarea, cada umbral, todas las tablas y las cosas que esto no muestra.

Los detalles completos

Todo a partir de aquí es el experimento completo. Es largo a propósito. Si solo querías el resultado, ya lo tienes.

La configuración

El agente

Cerca de 80 líneas. Sin frameworks, sin SDK de agente, sin librería de orquestación. Un bucle while alrededor de fetch:

1. POST al endpoint de chat completions de OpenRouter con la lista de mensajes y los esquemas de herramientas en formato de llamadas a funciones de OpenAI.
2. Si la respuesta tiene tool_calls, ejecuta cada una localmente, envía el resultado como un mensaje de role: "tool" y vuelve al bucle.
3. Si la respuesta no tiene tool_calls, ese texto es la respuesta final y el bucle termina.

Sobre el razonamiento específicamente: nunca se pasó el parámetro reasoning, por lo que el modelo funcionó con el valor por defecto del proveedor. Una llamada de control posterior devuelve reasoning_tokens: 0, por lo que no se gastó presupuesto de razonamiento separado y ninguno de los recuentos de tokens incluye tokens de razonamiento ocultos. Volver a ejecutar esto con un esfuerzo de razonamiento mayor produciría cifras absolutas diferentes.

Dos medidas de seguridad, porque un bucle de agente descontrolado quema dinero: máximo 8 turnos por ejecución y máximo 6 llamadas a herramientas por turno. Ninguna se alcanzó en las 192 ejecuciones. Una tercera medida suma cada llamada y corta cuando el total supera un límite, fijado en $2.60 para la campaña.

El mundo

Una SaaS B2B ficticia llamada Northwind Analytics, con el agente como su asistente de operaciones.

17 herramientas cuyos payloads imitan la forma real de Stripe, Zendesk, HubSpot, Statuspage, PagerDuty, Slack, Linear y un CMS de centro de ayuda: mismos nombres de claves, mismo anidamiento, mismo ruido. Son funciones locales que devuelven datos fijos (fixtures), por lo que nada sale de la máquina. Las escrituras se registran para la calificación y devuelven un acuse de recibo plausible.

11 habilidades, archivos Markdown con una description de una línea en el front matter y un cuerpo que contiene los umbrales, cifras y formatos reales: churn-save-offers, docs-review-cadence, dunning-playbook, enterprise-contract-terms, escalation-matrix, gdpr-data-requests, incident-comms, oncall-handover, refund-policy, release-notes-format, slack-style-guide. Varias no afectan a ninguna tarea. Son distractores para el router.

8 tareas, elegidas para abarcar dos ejes independientes: longitud, desde una sola llamada a la herramienta hasta siete turnos, y densidad del payload, desde “cada campo importa” hasta “el 76% de los bytes es texto para desechar”.

Las tareas, verbatim

Calificación

Determinista. 59 controles en las ocho tareas, cada uno es o bien una llamada a la herramienta con argumentos exactos, como stripe_create_refund(charge="ch_3QRk9X…", amount=14900, reason="duplicate"), o un dato que aparece solo dentro de un documento de habilidad: el nivel de SLA del 25%, la regla del día 10, el equipo PRIV, el plazo de 30 días.

No interviene ningún juez LLM en ningún momento. Una ejecución que nunca abre las habilidades falla el segundo tipo de control mecánicamente, que es el punto: hace que sea medible si “el agente realmente tenía la política” en lugar de ser una cuestión de opinión.

Cada tarea también declara sus rutas críticas de payload, los campos de los que depende su respuesta. Estas nunca se usan para dirigir el filtro. Existen para que un filtro demasiado agresivo sea visible en el registro incluso en ejecuciones que pasen de todos modos.

Las variantes

8 tareas × 4 variantes × 6 repeticiones = 192 ejecuciones, repeticiones que difieren solo en la seed.

Calibración

Ambos umbrales se analizaron offline antes de gastar tokens de agente.

0.55 para el enrutamiento es el valor más alto que mantiene el recobro total en las tareas contra las que se calibró. A 0.60, slack-style-guide puntúa 0.58 en la tarea de reembolso y el turno ahorrado se evapora. Dos centésimas separan una reducción de turnos del 15% de nada.

0.35 para el filtrado solo es viable gracias al estado rico descrito anteriormente. La pasada de calibración cuesta unos $0.004 porque ejecuta el router y el calificador sin ejecutar el agente en absoluto.

Una lección generalizable: cada formulación de una pregunta tiene su propia calibración. Un umbral no se transfiere entre dos redacciones de la misma pregunta. Se midieron distribuciones en soportes completamente diferentes para una formulación específica de la tarea y otra independiente de la tarea. Recalibra siempre que redactes de nuevo.

Totales de la campaña

General, por variante

Ninguna técnica degradó la calidad. El 99% de los controles pasan en las cuatro variantes. De las 96 llamadas filtradas en la variante D, exactamente una ruta declarada crítica fue eliminada y esa ejecución pasó igualmente. Las diferencias de “perfección” por ejecución entre el 92% y el 96% están dentro del ruido con n = 48. Los efectos robustos son los turnos y los tokens.

Tokens medios por ejecución, divididos según se facturan realmente:

La variante D recorta los tokens de entrada frescos, la clase cara, en un 49%.

Ahorro de tokens de entrada por técnica, de peor a mejor

La única celda negativa en toda la matriz es A en la tarea de SLA, donde el router carga una habilidad de más sin eliminar un turno. La habilidad extra entra en el prompt del sistema y se vuelve a enviar en cada turno. Las dos técnicas tampoco siempre se suman: en las tareas de SLA y postmortem, D ahorra menos tokens que B solo, precisamente por esa razón.

Cómo puntuó realmente el router

Probabilidad media por habilidad, por tarea. Cargada significa 0.55 o más.

Recobro: 132 de 144 habilidades necesarias cargadas, 92%. Un fallo sistemático y un falso positivo sistemático, ambos dignos de mencionarse claramente.

El fallo es slack-style-guide en la tarea de postmortem, puntuando 0. la tarea dice “comunica a la empresa en qué punto estamos” y el router no lee eso como una pregunta de formato. El agente la buscó él mismo cuando la necesitó.

El falso positivo es refund-policy en la tarea de SLA con 0.84 y en la de postmortem con 0.89. Un crédito de SLA parece un reembolso. Es exactamente la confusión que refund-policy existe para prohibir, ya que el documento dice que la indisponibilidad del servicio no es un reembolso. El router se equivoca en la forma y acierta en la sustancia, y el agente no se vio perjudicado.

La tarea de búsqueda no carga nada, correctamente. Ninguna habilidad afecta a ella y la puntuación más alta es 0.07.

Cómo se comportó realmente el filtro

Variante D, por herramienta, en 96 llamadas filtradas:

Las herramientas de lectura son donde está el dinero, y la dispersión entre ellas es enorme: desde −89% en una lista de documentos hasta −25% en un incidente donde casi todo es esencial.

Los acuses de recibo de escritura van en la dirección opuesta. billing_apply_credit devuelve 147 caracteres, y el marcador _trimmed adjunto a él cuesta más que los campos eliminados. Filtrar un payload pequeño es una pérdida neta, y cualquier implementación de producción debería omitir cualquier cosa por debajo de unos pocos cientos de caracteres. Se dejó así para que el efecto fuera visible en el registro.

Cada tarea, cada variante

Los precios son el coste completo de una ejecución, agente más Jev, utilizando la división medida de fresco y caché. Las columnas de Sonnet 5 y Opus 5 replican el tráfico medido a los precios de esos modelos. El coste de Jev es idéntico en las tres columnas.

T1-refund, payload medio · mixto

T2-sla, payload largo · mixto

T3-dunning, payload corto · mixto

T4-gdpr, payload medio · mixto

T5-incident, payload corto · denso

T6-stale-docs, payload corto · muy disperso

T7-postmortem, payload muy largo · mixto

T8-lookup, payload una llamada · disperso

Cómo se calcularon los precios

Medir una vez y luego recalcular el precio. Los recuentos de tokens son la base, y la factura de cada modelo son esos mismos recuentos a las tarifas de ese modelo.

La fórmula de facturación se dedujo de los datos en lugar de asumirse. En las 192 ejecuciones, el coste del agente observado coincide con

entrada_fresca × $0.25/M  +  entrada_caché × $0.02/M  +  salida × $1.20/M

con un error relativo medio del 0.04%. Dos consecuencias. El almacenamiento en caché de prompts estuvo activo todo el tiempo, automáticamente, sin marcadores cache_control, y el 80% de los tokens de entrada fueron lecturas de caché. Y cada token de entrada fresco se factura a la tarifa de escritura de caché, que es 1.25× el precio nominal de entrada, por lo que la tarifa nominal de $0.20/M es esencialmente lo que nunca pagas en un bucle de múltiples turnos.

Un modelo teórico anterior de caché, donde las lecturas en el turno t equivalen al prefijo en el turno t−1, subestimó las lecturas reales de caché en un 19%. Fue descartado en favor de la división por turno medida.

Las mismas ejecuciones sin ningún tipo de caché, como referencia:

Una suposición es conservadora en lugar de neutral. OpenAI cachea automáticamente y factura cada token de entrada fresco a la tarifa de escritura, que es lo que se midió. El almacenamiento en caché de Anthropic es opcional: solo el contenido dentro de un punto de ruptura cache_control se factura a la tarifa de escritura y el resto a la tarifa de entrada normal. Facturar todos los tokens frescos a la tarifa de escritura sobreestima ligeramente las columnas de Anthropic. Recalcular con tokens frescos a la tarifa de entrada normal mueve la media de Opus 5 de $0.04191 → $0.02995 (−29%) a $0.03823 → $0.02808 (−27%), y ninguna cifra por tarea se mueve más de 3 puntos.

Lo que esto no muestra

• Un solo modelo de agente. Todo se midió con openai/gpt-5.6-luna con razonamiento por defecto. Los recuentos de tokens son el entregable y las columnas de precios son aritmética sobre ellos. Un modelo diferente produciría recuentos de tokens diferentes, no solo precios diferentes.
• n = 6 por celda. Suficiente para recuentos de turnos y tokens, que son casi deterministas. No suficiente para separar una calidad del 92% del 96%.
• Datos fijos (fixtures), no APIs reales. Las formas de los payloads son fieles. Los endpoints reales tienen paginación, fallos parciales y límites de tasa que este entorno no ejercita.
• Las tareas fueron escritas por la misma persona que escribió las habilidades. La calificación es determinista, pero el mundo no es adversarial.
• La propia calibración de Jev no fue auditada. Lo que se midió es lo que sus puntuaciones hacen a un agente, no si están bien calibradas en el sentido estadístico.
• Una sola estructura de agente. Un bucle while con llamadas a funciones. Los subagentes, las llamadas a herramientas paralelas y las sesiones de larga duración cambian la aritmética.

Fuentes

• TypeSafe: introducing System One models and Jev
• TypeSafe: System One concepts
• Jev 1.13 on OpenRouter
• Mi artículo anterior: small models should decide what big models see
• Model Context Protocol: tools specification