Cómo Cloudflare redujo los costes de revisión con IA en un 68 % mediante el almacenamiento en caché de prompts

Los ingenieros de Cloudflare lograron reducir el coste medio de sus revisiones de código impulsadas por IA en un 68 %, pasando de $2,46 a solo $0,77 por revisión. Esta campaña de optimización, ejecutada entre mediados de septiembre y principios de octubre de 2026, también redujo drásticamente el tiempo mediano de revisión de más de cuatro minutos a menos de dos minutos sin sacrificar la calidad de la detección.

Qué ocurrió

A principios de año, los costes del revisor de código con IA de Cloudflare se dispararon a pesar de tener una arquitectura estable. En abril, una revisión promedio costaba $1,19, pero para finales de agosto, esa cifra había más que duplicado hasta alcanzar aproximadamente $2,46. El equipo identificó dos factores principales detrás de este aumento: la creciente complejidad de los cambios de código enviados por los ingenieros, lo que desplazaba más trabajo hacia niveles de revisión completa más costosos, y un cambio estratégico a los modelos de Anthropic que ofrecían mejor rendimiento pero a un precio superior. Específicamente, la migración a Claude Opus 4.7 para la verificación de estándares internos elevó el coste de ese componente específico de $0,25 a $0,88 por revisión.

A mediados de septiembre, el equipo lanzó una iniciativa agresiva de optimización. Analizaron los patrones de uso de tokens y descubrieron que, aunque las tasas de aciertos de caché eran altas, el volumen masivo de tokens procesados estaba inflando las facturas. Para principios de octubre, tras implementar una serie de cambios estructurales y a nivel de modelo, el coste promedio cayó a $0,77. Esto representó una reducción del 68 % respecto a las semanas de gasto máximo. Simultáneamente, la duración mediana de la revisión disminuyó de 4 minutos y 9 segundos a 1 minuto y 32 segundos, mejorando significativamente la experiencia del desarrollador junto con la eficiencia financiera.

Cómo funciona

El avance técnico clave implicó replantear cómo el sistema utilizaba el almacenamiento en caché de prompts de Anthropic. El almacenamiento en caché de prompts permite a los grandes modelos de lenguaje almacenar prefijos calculados de una conversación, habilitando una reutilización más económica para solicitudes posteriores. Sin embargo, Cloudflare encontró que su implementación inicial no compartía los datos en caché entre diferentes repositorios. El prompt del sistema incluía detalles específicos del repositorio, como directorios de trabajo y fechas, antes del punto de interrupción de la caché, lo que significaba que cada nueva sesión comenzaba con un fallo de caché (cache miss). Al dividir el prompt del sistema y colocar un marcador de caché después de las instrucciones estáticas del agente, aseguraron que el prefijo compartido de 11k a 21k tokens pudiera reutilizarse en todos los trabajos, convirtiendo escrituras frecuentes en lecturas baratas.

Las ganancias adicionales de eficiencia provienen de reducir el número de llamadas a LLM por sesión. Anteriormente, los sub-revisores intentaban usar herramientas a las que no tenían permiso de acceso, resultando en llamadas desperdiciadas y bucles de recuperación de errores. El equipo eliminó estas herramientas inaccesibles y paralelizó la lectura de archivos, permitiendo a los revisores ingerir contexto en un único turno en lugar de múltiples pasos secuenciales. También implementaron lógica para omitir revisores innecesarios durante las re-revisiones y cancelaron trabajos que continuaban ejecutándose en segundo plano después de ser marcados como completos. Estos cambios redujeron colectivamente el número promedio de llamadas a LLM y el recuento total de tokens por revisión.

Detalles clave

• El coste promedio de revisión cayó de $2,46 a $0,77, una reducción del 68 %.
• El tiempo mediano de revisión mejoró de 4m 09s a 1m 32s.
• Las tasas de aciertos de caché para el prefijo compartido aumentaron significativamente tras reestructurar el prompt del sistema.
• Cambiar de Sonnet 5 a Sonnet 5.5 redujo los costes casi a la mitad para algunos tipos de revisores debido al menor uso de tokens.
• Los cambios en el código representaron $0,65 de los ahorros, mientras que los ajustes de modelo y esfuerzo representaron $1,06.
• El tiempo de revisión del percentil 99 es ahora más rápido que el de la mayoría (75 %) de las revisiones realizadas en abril.

Por qué importa

Para los equipos de ingeniería que construyen con grandes modelos de lenguaje, este caso de estudio destaca que la estabilidad arquitectónica no garantiza la estabilidad de costes. A medida que los modelos se vuelven más capaces, los usuarios tienden a enviar entradas más complejas, lo que puede aumentar inadvertidamente el consumo de tokens. La experiencia de Cloudflare demuestra que unas altas tasas de aciertos de caché no son suficientes si los datos en caché no están estructurados para maximizar la reutilización. Los desarrolladores deben gestionar activamente la estructura del prompt para asegurar que el contenido estático y compartido esté aislado del contenido dinámico y variable para aprovechar eficazmente el almacenamiento en caché.

Además, el cambio en los impulsores de costes desde la infraestructura hacia la selección de modelos y los niveles de esfuerzo sugiere que se requiere un ajuste continuo. Simplemente elegir un modelo potente no es una decisión de "configurar y olvidar". Los equipos necesitan evaluar continuamente si los ajustes de mayor esfuerzo producen un valor proporcional en los hallazgos. Cloudflare encontró que para algunas tareas, un esfuerzo medio era suficiente, mientras que para otras, un esfuerzo alto valía la pena el aumento marginal de costes. Este enfoque granular de la configuración evita la sobreprovisión de recursos informáticos para tareas que no requieren razonamiento profundo.

Qué puedes hacer

• Audita tu estructura de prompts para asegurar que los prefijos estáticos estén separados de las variables dinámicas para una mejor utilización de la caché.
• Monitorea el número de llamadas a LLM por sesión e identifica turnos desperdiciados causados por errores de herramientas o resúmenes innecesarios.
• Prueba versiones más nuevas de modelos contra las líneas base actuales, ya que las mejoras de eficiencia a veces pueden compensar precios por token más altos.
• Implementa procesamiento paralelo para la recuperación de contexto para reducir la latencia secuencial y el número de llamadas.
• Revisa los ajustes de esfuerzo para diferentes niveles de tareas para asegurar que no estás sobrecalculando para comprobaciones simples.
• Asegúrate de que los trabajos cancelados sean realmente terminados a nivel de script para evitar el desperdicio de recursos en segundo plano.