Cloudflare detectó un aumento notable del coste por ejecución de su revisor automático de código y lanzó una auditoría interna centrada en el uso de tokens y en cómo se construyen y reutilizan los prompts. Tras una serie de cambios en el código del revisor y en la estrategia de selección de modelos, la compañía afirma haber reducido el coste medio por revisión un 68% y haber recortado el tiempo medio de revisión.
Qué causó el aumento del coste
Durante los meses previos, el coste por revisión se fue incrementando sin cambios arquitectónicos importantes del sistema coordinador ni de los niveles de riesgo que determinan la intensidad de la revisión. Cloudflare observó que gran parte del aumento provenía de cambios en los modelos usados: al migrar revisores a modelos de Anthropic, el coste por job subió porque esos modelos resultaron más caros en esta carga de trabajo concreta, aunque durante las pruebas ofrecían mejor rendimiento.
Cómo actuaron: enfoque en tokens y cacheo de prompts
La optimización se centró en dos vectores principales: reducir la cantidad de tokens enviados/recuperados en cada sesión y mejorar la tasa de acierto del cache de prompts (prefix cache) para evitar repetir trabajo ya calculado por los modelos. Antes de las mejoras, el revisor hacía muchas llamadas al LLM por revisión y la mayor parte del gasto provenía de contexto que el modelo ya había visto o volvería a ver.
Cloudflare midió la composición del gasto justo antes de la intervención: los tokens de salida eran cerca del 23% del coste, las escrituras al cache suponían el 43% y las lecturas el 34%. En una sesión típica el revisor realizaba media docena de llamadas grandes al LLM y escribía y leía cientos de miles de tokens, porque cada llamada incluye toda la conversación como contexto.
Correcciones técnicas clave
- Revisión del formato del prompt y puntos de cacheo: en la versión previa del revisor (OpenCode v1) el bloque del sistema combinaba la parte compartida del agente con elementos dependientes del repositorio, y el cache breakpoint quedaba al final del bloque. Eso impedía que repositorios distintos reutilizaran prefijos compartidos. Separando el bloque en dos y colocando el breakpoint tras la porción idéntica a todas las sesiones se incrementó la probabilidad de lectura del prefijo en lugar de escribirlo.
- Marcador y hook para dividir prompts: añadieron un marcador al final del agente y un plugin que parte el bloque: la primera mitad (compartida) obtuvo su propio breakpoint y quedó libre de contenido específico por repositorio.
- Migración de referencias al prompt: el revisor estándar interno (Codex) incorporó su índice de referencia y archivos de apoyo directamente en el prompt, eliminando tres llamadas previas a herramientas que leían esos ficheros. Con ello las llamadas por ejecución de ese revisor bajaron y su coste por ejecución se redujo.
- Optimización de llamadas y rutas de modelos: parte del ahorro vino de ajustar qué modelos usan los distintos sub-revisores y cuánto “esfuerzo” (número/tiempo de llamadas) se asigna a cada caso, es decir, enrutamiento inteligente entre modelos más caros y otros más económicos según la carga.
Resultados y efectos prácticos
Tras las optimizaciones, Cloudflare pasó de un coste medio por revisión de alrededor de $2.43 en las semanas más caras a un coste medio de $0.77; además, el tiempo mediano de revisión se redujo de aproximadamente 4 minutos 9 segundos a 1 minuto 32 segundos. La empresa atribuye cerca del 40% del ahorro a cambios en el código del revisor y el resto a la experimentación con modelos y su enrutamiento.
Qué deben hacer los administradores y desarrolladores
Para equipos que integran LLMs en flujos automáticos de revisión o similares, las lecciones aplicables son:
- Medir con detalle uso de tokens por llamada y por sesión: el coste puede crecer tanto por más llamadas como por contextos más grandes.
- Diseñar prompts pensando en la reutilización: extraer y separar la parte inmutable del prompt facilita el uso de prefix caches y reduce escrituras redundantes.
- Priorizar leer del cache en la primera petición cuando sea posible (evitar escribir si ya existe el prefijo), y limitar elementos específicos del repositorio que impidan la reutilización entre proyectos.
- Evaluar el trade-off coste/precisión entre modelos: elegir modelos más caros sólo cuando aporten una mejora relevante en la tarea, y enrutar trabajos menos críticos a alternativas más económicas.
Cloudflare también señala que siguen probando otras formas de ejecución (por ejemplo, ejecutar el revisor sobre Durable Objects) y que continuarán afinando la arquitectura para reducir costes y latencias.
Lee también:
- Tailscale lanza MagicRoute: selección inteligente de rutas para subnet routers y conectores
- BleachBit 6.0.6 acelera borrado de archivos y añade soporte para Helium y Docker Desktop
Fuente: Cloudflare Blog
