Cloudflare recorta 68% su factura de IA con caché

Cómo Cloudflare bajó el costo de su revisor de IA de US$2,43 a US$0,77 por revisión

Cloudflare logró reducir un 68% el costo de su revisor de código con IA: pasó de US$2,43 a US$0,77 por revisión promedio, y de paso bajó el tiempo medio de 4m 09s a 1m 32s. El dato importa porque el problema no era de arquitectura: la empresa no había cambiado el diseño del sistema, y aun así la factura se había duplicado en pocos meses.

Entre abril y finales de agosto, el costo por revisión escaló de US$1,19 a unos US$2,46. En el desglose mensual que publicó la compañía, la curva es clara: US$1,22 en marzo, US$1,44 en junio, US$1,74 en julio y US$2,32 en agosto. Nadie había tocado el motor; simplemente el motor se había vuelto más caro de alimentar.

Si tu startup usa agentes de IA en producción, esta es la historia que te conviene leer antes de que te llegue la factura.

Por qué el costo se duplicó sin cambiar una línea de arquitectura

La explicación de Cloudflare tiene dos capas. La primera es de comportamiento: los modelos mejoraron, los ingenieros empezaron a producir cambios más grandes y complejos, y más revisiones cayeron en la categoría más cara. La proporción de revisiones en el tier más costoso pasó del 59% en marzo al 65% en agosto.

La segunda capa es la que realmente movió la aguja: el cambio de modelos. A comienzos de agosto, Cloudflare migró a todos sus revisores a modelos de Anthropic, lo que elevó el costo por trabajo de US$1,38 a US$2,03. Su revisor de estándares internos, Codex, terminó sobre Claude Opus 4.7 y pasó de costar unos US$0,25 por revisión a US$0,88, más caro que el propio agente coordinador.

El detalle contraintuitivo: la tasa de acierto de caché mejoró, de 85,7% en abril a 97% en septiembre. Pero el número de tokens por revisión se multiplicó por más de tres, de 0,91 millones a 2,99 millones. Un buen hit rate sobre tres veces más tokens sigue costando mucho más.

Dónde se iban realmente los tokens

Antes de empezar a optimizar, el gasto del revisor se repartía así: 23% en tokens de salida, 43% en escrituras de caché y 34% en lecturas de caché. Es decir, la mayor parte del dinero se iba en contexto que el modelo ya había visto o estaba por volver a ver.

La mecánica detrás de eso es la clave de todo el artículo. El revisor de calidad hacía 16,6 llamadas al LLM por revisión, escribía 72.000 tokens a la caché y leía de vuelta 1,08 millones, porque cada llamada reenvía toda la conversación como contexto. El costo de una sesión crece con el número de llamadas y con el tamaño del contexto, y Cloudflare había aumentado ambos sin darse cuenta.

Vale la pena entender cómo funciona la caché de prompts de Anthropic: solo cachea prefijos, es decir, los mensajes al inicio de la conversación. Escribir a la caché cuesta 1,25 veces el precio normal de entrada y leer cuesta 0,1 veces, pero la entrada expira a los cinco minutos si nadie la lee. Eso deja dos palancas: que la primera petición de cada sesión lea de la caché en vez de escribirla, y que cada sesión use menos llamadas.

La palanca 1: compartir el prefijo entre repositorios

Desde el 14 de septiembre, Cloudflare empezó a registrar el uso de tokens de la primera llamada de cada sesión. El dato fue demoledor: esa primera petición encontraba un prefijo cacheado solo entre el 14% y el 26% de las veces, cuando cada sesión arranca con las mismas definiciones de herramientas y el mismo prompt de agente, entre 11.000 y 21.000 tokens idénticos en todos los repositorios.

El problema estaba en cómo OpenCode v1 construía el prompt de sistema: armaba un bloque con el prompt del agente seguido de una sección de entorno con el directorio de trabajo y la fecha, y ponía el único punto de corte de caché al final. La parte compartida nunca se guardaba sola, así que una revisión en un repositorio jamás podía reutilizar lo que había escrito otra.

El 16 de septiembre agregaron un marcador al final de cada prompt y un hook que partía el bloque en dos. El mismo día movieron el índice de referencia del revisor de estándares dentro de su prompt: sus llamadas por ejecución cayeron de 15,9 a 9,6 y su costo por ejecución de US$1,12 a US$0,72. Juntas, ambas medidas llevaron el costo por revisión de US$2,47 a US$2,02.

La palanca 2: menos llamadas, menos dólares

El 21 y 23 de septiembre salió un paquete de cambios que, por separado, parecen menores, pero que juntos recortaron unos US$0,20 por revisión:

• Eliminar herramientas inutilizables. Los sub-revisores veían la herramienta que publica el comentario final. En 57% a 76% de las sesiones intentaban llamarla, el servidor las rechazaba y gastaban otra llamada en recuperarse.
• Leer archivos en paralelo. En el 64% de los turnos del revisor de calidad, el modelo hacía exactamente una llamada de herramienta, casi siempre para leer un solo archivo.
• Saltar revisores en re-revisiones. Cerca de dos tercios de los trabajos son una segunda revisión del mismo merge request, y a menudo tres revisores no tienen nada nuevo que mirar.
• Detenerse tras publicar. OpenCode devolvía el resultado al modelo para un turno extra que releía toda la conversación para escribir un resumen que nadie veía: unos US$0,07 por trabajo.
• Cancelar trabajos cancelados. En una muestra de 446 trabajos cancelados, 358 siguieron corriendo hasta terminar la revisión.

El cambio más elaborado fue compartir un prefijo entre tres revisores. Los de calidad, seguridad y rendimiento envían ahora una primera petición idéntica, y uno escribe la caché mientras los otros dos leen de ella. Cuesta unos nueve centavos por revisor y obliga a esperar hasta 20 segundos al primero.

La palanca 3: modelos y esfuerzo

Aquí está el hallazgo que más debería interesar a un founder. Al separar el período por cada release y cada cambio de configuración, los cambios de código explican US$0,65 de los US$1,67 ahorrados, y los cambios de modelo y esfuerzo, US$1,06. La palanca más grande no fue ingeniería: fue dejar de tener una preferencia preconcebida por ciertos modelos.

El 3 de octubre partieron a la mitad a todos los revisores Sonnet entre Sonnet 5 y Sonnet 5.5. Tras dos días y medio, Sonnet 5.5 resultó 62% más barato por ejecución en calidad de código, 58% en rendimiento y 47% en seguridad, con el mismo precio por token. Todo el ahorro vino de usar menos tokens. El 5 de octubre migraron a todos.

Con Sonnet 5.5 en esfuerzo medio, el revisor de calidad hace 1,7 llamadas por ejecución en vez de 6,2, y más de la mitad de sus ejecuciones terminan en una sola llamada. En esfuerzo alto hace 3,4. Cloudflare midió el trade-off: el esfuerzo alto cuesta 61% más por ejecución pero publica 58% más hallazgos críticos y de advertencia, unos dos centavos por revisión. Concluyeron que vale la pena.

¿Bajar el costo significa peor calidad?

No automáticamente, y Cloudflare lo midió de dos formas. Primero, si los autores actúan sobre lo que el revisor señala: antes lo hacían en el 34% de los hallazgos serios, ahora en el 59%. El revisor marca menos cosas, pero las que marca llevan mucho más a un cambio real. Los hallazgos serios que derivaron en una modificación pasaron de 229 a 321 por cada 1.000 revisiones.

Segundo, hicieron que dos modelos de distintos proveedores juzgaran a ciegas 657 hallazgos. Los hallazgos importantes por revisión se mantuvieron estables (0,28 antes, 0,30 ahora). Lo que se derrumbó fue la severidad inflada: los jueces calificaban 0,46 hallazgos por revisión como más graves de lo que merecían; ahora son 0,14, una caída del 70%. Buena parte de la reducción de hallazgos críticos era ruido.

La confiabilidad también mejoró: las revisiones que terminan sin veredicto pasaron de 0,79% a 0,27%.

Qué significa esto para tu startup

El contexto del sector confirma que este no es un problema exclusivo de Cloudflare. Según Forbes, citando a Deloitte, los costos de inferencia cayeron 280 veces en los últimos años y aun así siguen subiendo con fuerza porque el uso crece más rápido. HPCwire reporta que el gasto en tokens de las empresas creció 13 veces entre enero de 2025 y comienzos de 2026, según datos internos de Ramp, y que Gartner estima que los modelos agénticos consumen entre 5 y 30 veces más tokens que un chatbot estándar.

Dos acciones concretas que puedes implementar esta semana:

• Audita la primera petición de cada sesión. Es el hallazgo más rentable del caso. Si tu sistema prompt supera los 2.000 tokens y lo envías en cada llamada, revisa si esa primera petición está leyendo de la caché o escribiéndola. Cloudflare encontró que solo acertaba en el 14%-26% de los casos por un detalle de ordenamiento de bloques.
• Mide el costo por tarea, no por token. Como explica TechTarget, el modelo más barato por token puede ser el más caro por resultado si falla más y obliga a reintentar. Antes de migrar a un modelo más económico, compara el costo por tarea completada con éxito.

Y una advertencia que el propio caso deja clara: el ahorro por modelo y esfuerzo fue mayor que el ahorro por código, pero el esfuerzo bajo sí perdió hallazgos reales en rendimiento. Optimizar sin medir calidad es cambiar una factura alta por un problema silencioso.

Conclusión

Cloudflare no encontró una bala de plata: encontró que su primera petición casi nunca leía de la caché, que sus revisores hacían llamadas de más y que estaba pagando por modelos y niveles de esfuerzo que no le devolvían valor proporcional. El resultado fue un 68% menos de costo y revisiones más rápidas, sin perder capacidad de detección.

Para una startup con presupuesto ajustado, el mensaje es directo: antes de negociar precios o cambiar de proveedor, instrumenta tu gasto a nivel de token y de tarea. La mayoría de las facturas de IA no son un problema de precio, son un problema de visibilidad.

Fuentes

• Cutting our inference bill by 68% by being obsessive about optimization (fuente original)
• Tokenmaxxing And The Future Of AI Inference: The New Cost Curve
• The Enterprise AI Cost Reckoning: Why Falling Per-Token Prices Aren't Saving You
• Cost per task: A new method for AI spend management
• Why Token Costs Are Breaking the CFO Budgets in 2026