De 2,46 a 0,77 dólares por revisión: La auditoría milimétrica de Cloudflare para recortar un 68% en agentes de IA

El espejismo del 97% de acierto: Por qué una factura de tokens se triplica sin cambiar la arquitectura

Cuando un equipo de ingeniería despliega agentes autónomos en producción, el primer indicador que vigila suele ser la tasa de acierto de la caché de contexto. Si la cifra supera el 90%, la suposición habitual es que la infraestructura financiera está blindada. Cloudflare demostró en su propia operativa interna que esa presunción es un error matemático peligroso. Entre abril y finales de agosto, el coste medio de su revisor automático de código pasó de 1,19 dólares a 2,46 dólares por cada pull request analizada, a pesar de que la tasa de acierto de la caché escaló del 85,7% a un aparente 97%.

El problema de fondo no radicaba en un cambio en las reglas de asignación ni en un fallo del orquestador. La lógica de trabajo seguía dividiendo las revisiones entre evaluadores especializados según el nivel de riesgo del código. Sin embargo, el volumen total de tokens por sesión se disparó de 0,91 millones a 2,99 millones. En la práctica, tener un 97% de lecturas de caché sobre una base que se ha multiplicado por tres termina costando mucho más dinero que operar con una tasa de acierto menor sobre un volumen de datos controlado. Es el equivalente a conseguir un 90% de descuento en la tarifa por kilómetro de un taxi, pero obligar al vehículo a recorrer una distancia diez veces más larga en cada trayecto.

A mediados de septiembre, el equipo técnico intervino el sistema para rastrear el destino exacto de cada token. El resultado de esa intervención fue un descenso del gasto medio por revisión hasta los 0,77 dólares, lo que supone un recorte neto del 68% respecto a las dos semanas más caras del verano. De forma paralela, la optimización recortó el tiempo de espera de los desarrolladores: la mediana de ejecución cayó de 4 minutos y 9 segundos a solo 1 minuto y 32 segundos. Cerca del 40% de este ahorro provino de modificaciones directas en el código del arnés y la gestión de memoria, mientras que el 60% restante se logró ajustando la asignación de modelos y la profundidad de análisis asignada a cada tarea.

La anatomía del gasto en tokens: Desglose financiero antes y después del rediseño

Para comprender cómo se descontroló el presupuesto sin tocar la arquitectura base, es necesario examinar la evolución mensual del coste medio por revisión. La métrica no subió de golpe, sino que acumuló pequeños incrementos constantes a medida que los desarrolladores producían cambios de código más amplios y el sistema adoptaba modelos más avanzados para evaluarlos.

El seguimiento de costes fijó la proporción de tipos de revisión para evitar distorsiones estadísticas provocadas por días con una acumulación anormal de tareas complejas. En marzo, la revisión media se situaba en 1,22 dólares. Para junio, el coste subió a 1,44 dólares, tocó los 1,74 dólares en julio y alcanzó un techo de 2,32 dólares a finales de agosto, con jornadas puntuales que superaron los 2,46 dólares.

Métrica analizada	Marzo	Agosto (Pico)	Octubre (Optimizado)	Variación neta
Coste medio por revisión	$1,22	$2,46	$0,77	-68,7%
Tiempo de respuesta (mediana)	~4 min	4 min 09 s	1 min 32 s	-63,1%
Volumen de tokens por sesión	0,91M	2,99M	~1,10M (est.)	-63,2%
Acierto global de caché	85,7%	97,0%	>98,0%	+12,3%
Acierto de caché en llamada inicial	Desconocido	14% – 26%	~100%	+74,0%
Proporción de revisiones complejas	59%	65%	65% (controlado)	Neutral
Coste del agente evaluador Codex	~$0,25	$0,88	<$0,30 (est.)	-65,9%

La distribución interna de la factura arrojó una pista definitiva sobre el origen de la fuga de capital. Justo antes de arrancar la fase de optimización, el 23% del gasto correspondía a los tokens de salida generados por el modelo, el 43% correspondía a la escritura en caché y el 34% a la lectura de dicha caché. En conjunto, el 77% de todo el dinero invertido en inferencia se destinaba a procesar contexto que el modelo ya había leído con anterioridad o que estaba a punto de volver a procesar en la siguiente interacción de la misma sesión.

El cuello de botella en producción: Tres fallos silenciosos que devoran el presupuesto

El análisis forense de las sesiones reveló tres fallos de diseño que operaban de forma simultánea. Cuando varios agentes interactúan para revisar software, el volumen de llamadas individuales y la longitud de las cadenas de mensajes interactúan de forma multiplicativa, no lineal.

La acumulación ciega de turnos de conversación

El agente encargado de supervisar la calidad del código realizaba una media de 16,6 llamadas al modelo en cada revisión. El diseño original del flujo enviaba la conversación completa como contexto acumulado en cada una de esas 16 llamadas. A lo largo de una sola tarea de revisión, el agente llegaba a escribir 72.000 tokens en la caché y realizaba lecturas repetidas por un total de 1,08 millones de tokens.

A medida que los repositorios crecían y los ingenieros introducían cambios más sustanciales, cada llamada sucesiva resultaba más pesada que la anterior. Aunque el coste de lectura de la caché sea solo una décima parte (0,1x) del coste de entrada estándar, iterar diez veces sobre un historial saturado termina costando exactamente lo mismo que enviar el texto completo sin optimización alguna.

El fallo de diseño en la caché de prefijo de OpenCode v1

El proveedor de inferencia utilizado por el equipo, Anthropic, gestiona la memoria intermedia mediante prefijos de mensajes que comienzan desde el encabezado inicial y avanzan hasta un marcador específico denominado punto de ruptura de caché (cache breakpoint). Para reutilizar un prefijo en una petición futura, la secuencia de texto debe coincidir de forma idéntica, carácter por carácter, hasta ese marcador. Escribir un bloque en caché cuesta 1,25 veces el precio de entrada base, mientras que leerlo cuesta 0,1 veces, caducando a los cinco minutos si nadie accede a él.

El 14 de septiembre, el equipo comenzó a medir cuántas veces la primera llamada de una sesión aprovechaba la memoria de ejecuciones previas. El resultado fue demoledor: solo entre el 14% y el 26% de las primeras llamadas registraban un acierto de caché. Cada revisión comenzaba con una definición de herramientas y un prompt de sistema compartidos que sumaban entre 11.000 y 21.000 tokens idénticos para cualquier repositorio de la empresa. En teoría, el acierto inicial debió rozar el 100%.

El fallo radicaba en cómo la primera versión del sistema, OpenCode v1, ensamblaba las instrucciones:

• Agrupaba en un único bloque de texto el prompt del agente junto con una sección de entorno que incluía la ruta de trabajo local y la fecha exacta del sistema.
• Colocaba el único punto de ruptura al final de ese bloque mixto.
• Al cambiar la fecha o el nombre de la carpeta de trabajo entre un repositorio y otro, el prefijo completo se invalidaba. Una revisión ejecutada en un proyecto no podía reutilizar jamás la memoria generada segundos antes por otro proyecto distinto.

La migración de modelos sin segmentación de esfuerzo

A principios de agosto, el equipo migró la totalidad de los agentes revisores a modelos de la familia Claude. Esa decisión elevó el coste por tarea de 1,38 a 2,03 dólares de forma inmediata. Las pruebas internas confirmaron que estos modelos ofrecían una precisión muy superior a las alternativas del mercado en análisis de código complejo, lo que justificaba su adopción desde el punto de vista de la calidad del software.

El error consistió en aplicar la misma potencia bruta a tareas con exigencias dispares. El agente Codex, responsable de verificar estándares internos de estilo y convenciones básicas, pasó a ejecutarse sobre Claude Opus. Su coste individual saltó de 0,25 dólares a 0,88 dólares por revisión en agosto, superando el gasto del propio agente coordinador. Se estaba utilizando un motor diseñado para razonamiento abstracto avanzado en tareas repetitivas de verificación de sintaxis y formatos predecibles.

La solución técnica: Puntos de ruptura independientes y la arquitectura OpenCode v2

Para frenar el gasto sin degradar la capacidad de detección de fallos del revisor, el equipo implementó dos cambios de ingeniería de software a gran escala: la corrección quirúrgica de los bloques de memoria y la reescritura total del arnés bajo la versión OpenCode v2.

El 16 de septiembre se introdujo una directiva en el código que dividió el prompt de entrada en dos segmentos aislados mediante un punto de enganche (plugin hook). El primer bloque agrupó exclusivamente las instrucciones del agente y la definición estática de herramientas. El punto de parada de caché se reubicó inmediatamente después de este material compartido. Las variables volátiles, como la fecha del sistema o el directorio de trabajo, se desplazaron a un segundo bloque posterior. Con este simple ajuste, cualquier revisión que arrancase en la infraestructura de Cloudflare encontraba de forma instantánea el prefijo cargado en memoria, reduciendo el coste de entrada de la primera llamada a una fracción mínima.

Paralelamente, el arnés de ejecución se reconstruyó por completo bajo el nombre de OpenCode v2. Antes de reemplazar el sistema anterior en producción, se ejecutaron ambas versiones en paralelo durante semanas mediante un entorno de pruebas en sombra (shadow mode) sobre repositorios de prueba. Ambas arquitecturas coincidieron en la decisión final de aprobación o rechazo en el 98% de las solicitudes de cambio evaluadas.

Al comprobar la paridad técnica, el tráfico se redirigió por completo a la versión v2 a principios de octubre, eliminando el código antiguo. Solo por optimización de rutinas internas y gestión de procesos, las revisiones completas en v2 terminaron un 13% más rápido utilizando exactamente los mismos modelos subyacentes. La compañía comenzó además a probar la ejecución directa de estos agentes sobre Workers y Durable Objects mediante su biblioteca interna pi-durable.

Para equipos que operan flujos similares en la nube pública, supervisar la latencia y la acumulación de contexto requiere una instrumentación milimétrica a través de plataformas como Datadog, evitando que las sesiones zombi sigan consumiendo tokens cuando el agente entra en bucles de validación redundantes.

Marco de ejecución para equipos de ingeniería: Cómo evitar la quiebra operativa por agentes de IA

La experiencia de Cloudflare demuestra que los costes de inferencia en flujos de trabajo autónomos no se resuelven cambiando de proveedor de modelos, sino auditando el ciclo de vida del texto que entra y sale de las llamadas API. A continuación se detallan las medidas técnicas concretas que cualquier departamento de desarrollo debe aplicar para blindar su presupuesto.

Tareas inmediatas: Auditoría de prefijos y fragmentación de prompts

• Aislar de inmediato cualquier dato temporal o volátil: Ningún prompt del sistema debe contener fechas, identificadores de sesión (UUID), rutas locales de archivos o nombres de usuario antes del primer punto de parada de la caché. Esos datos deben trasladarse siempre a mensajes secundarios del rol de usuario o a un bloque posterior al punto de parada.
• Medir la tasa de acierto en la llamada número uno: La métrica de acierto global oculta fallos estructurales graves. Es obligatorio monitorizar de forma independiente la primera interacción de cada sesión. Si el acierto en la primera llamada baja del 90%, significa que los distintos flujos de trabajo no están reutilizando la memoria base y están pagando un 25% extra por reescribir información idéntica una y otra vez.
• Acotar el tamaño del arnés de herramientas: La definición de funciones y llamadas a herramientas (tool calling) no debe cargarse completa si el agente solo requiere un subconjunto de ellas en una fase concreta. Dividir los esquemas de herramientas según la especialidad del agente ahorra decenas de miles de tokens fijos en cada petición.

Tareas estructurales: Enrutamiento dinámico de modelos y pruebas en sombra

• Eliminar el uso de modelos de gama alta en tareas mecánicas: Evaluar la guía de estilo, la indentación, el formato de comentarios o la presencia de firmas de métodos no requiere un modelo de razonamiento profundo. Asignar estas tareas a modelos ligeros reduce el coste por trabajo en más de un 60% sin alterar la calidad del software entregado.
• Implementar pruebas en sombra antes de alterar arneses: Cualquier cambio en la forma en que los agentes leen el historial o ejecutan herramientas debe contrastarse mediante ejecuciones paralelas silenciosas. No se debe retirar una versión operativa hasta alcanzar al menos un 95% de coincidencia en las decisiones de negocio tomadas por ambas versiones sobre casos reales.
• Limitar la acumulación de historial en bucles largos: Cuando un agente requiere más de cinco llamadas consecutivas para resolver un problema, el historial previo debe resumirse o podarse de forma estructurada. Reenviar dieciséis turnos de conversación con respuestas completas de herramientas anula cualquier beneficio económico derivado del uso de la caché.