Cloudflare reduce un 68% el coste de la revisión de código con IA: de $2,43 a $0,77

El coste medio de una revisión en el revisor de código con IA de Cloudflare subió de $1,22 a $2,32 entre marzo y agosto, y en las dos semanas más caras llegó a $2,43. La arquitectura, sin embargo, no cambió: el coordinador repartía las tareas entre los mismos especialistas y la profundidad de la revisión seguía determinándose con los mismos niveles de riesgo. A mediados de septiembre, el equipo encargó a sus propios agentes que averiguaran adónde se iban los tokens y recortaran el gasto.

El resultado: $0,77 por revisión con el nivel de esfuerzo alto activado para la revisión de calidad del código, un 68% menos. Como efecto secundario, el tiempo mediano de revisión bajó de 4 min 09 s a 1 min 32 s.

De dónde salió el aumento

La estructura de la carga explica solo una pequeña parte del encarecimiento: la proporción de revisiones en el nivel más caro (revisión completa) subió del 59% en marzo al 65% en agosto, porque los ingenieros empezaron a enviar cambios más grandes. La mayor contribución vino de los cambios de modelo. A principios de agosto, todos los revisores pasaron a modelos de Anthropic, porque rendían mejor en esta tarea en las pruebas internas. El coste de la tarea subió de $1,38 a $2,03. El revisor de estándares internos Codex acabó en Claude Opus 4.7, y su precio por revisión saltó de $0,25 a $0,88, más que el del propio coordinador.

Estructura del gasto antes de la optimización: 23% en tokens de salida, 43% en escritura en caché y 34% en lectura de caché. La mayor parte del dinero se iba en contexto que el modelo ya había visto. El revisor de calidad del código hacía una media de 16,6 llamadas al LLM por revisión, escribía 72 000 tokens en la caché y leía 1,08 millones, porque cada llamada transmite toda la conversación.

La tasa de aciertos de caché subió del 85,7% al 97%, pero el número de tokens por revisión pasó de 0,91 a 2,99 millones, y el alto hit rate no lo compensó. La escritura en caché de Anthropic cuesta 1,25 veces el precio de entrada y la lectura, 0,1; lo escrito dura cinco minutos sin accesos.

Prefijo común y menos llamadas

Desde el 14 de septiembre, el equipo empezó a registrar los tokens de la primera llamada de cada sesión y el hash del primer bloque de sistema. Se descubrió que la primera solicitud encontraba una caché ya preparada solo en el 14–26% de los casos, aunque entre 11 000 y 21 000 tokens de definiciones de herramientas y del prompt del agente son idénticos en todos los repositorios. La causa estaba en OpenCode v1: componía un único bloque con el prompt del agente y la sección de entorno (directorio de trabajo, fecha) y colocaba un único punto de caché al final. La parte común no se guardaba por separado.

El 16 de septiembre se añadió un marcador al final del prompt, y un plugin dividió el bloque en dos y situó el punto de caché después de la parte común. Todo lo específico de cada repositorio se retiró del inicio del prompt, y se desactivó la lista de skills. Ese mismo día, el índice de estándares de Codex se incorporó directamente al prompt: antes, los tres primeros turnos de la sesión se iban en leer esos archivos; ahora son 9,6 llamadas en lugar de 15,9, y el coste del arranque bajó de $1,12 a $0,72. En conjunto, esto redujo el precio de la revisión de $2,47 a $2,02.

Los cambios siguientes, del 21 y el 23 de septiembre, quitaron unos $0,20 por revisión:

• Se ocultó a los subrevisores la herramienta de publicación del comentario final: en el 57–76% de las sesiones intentaban invocarla, el servidor la rechazaba y gastaban una llamada de más. El ahorro es de unos 2900 tokens de definiciones por solicitud.
• Lectura paralela de archivos: en el 64% de los turnos, el revisor de calidad hacía exactamente una llamada a herramienta. Ahora el contexto común y todos los parches se leen en la primera respuesta, hasta 150 KB.
• Omisión de revisores en las revisiones repetidas: aproximadamente dos tercios de las tareas son repeticiones. En las revisiones completas repetidas se omiten las comprobaciones de AGENTS.md en el 56% de los casos, las de rendimiento en el 23% y las de documentación en el 13%.
• Parada tras publicar la revisión: OpenCode ejecutaba un turno más para generar un resumen invisible, unos $0,07 por tarea.
• El timeout de un revisor lento dejó de contarse como fallo del proveedor; los timeouts del revisor de seguridad bajaron del 1,8% de las ejecuciones a casi cero.
• Cancelación de tareas ya canceladas: de 446 tareas canceladas en GitLab, 358 seguían ejecutándose. Ahora la tarea comprueba su estado cada 15 segundos.

El cambio más complejo fue el prefijo común para los tres revisores (calidad del código, seguridad y rendimiento): mismas herramientas, mismo archivo de reglas y el merge request con todos los parches. Un revisor escribe la caché y los otros dos la leen. Como la escritura solo está disponible una vez que empieza el streaming de la respuesta, los demás esperan hasta 20 segundos. Eso los ralentiza ligeramente, pero ahorra unos nueve centavos por revisor.

Modelos, esfuerzo y calidad

De la reducción de $1,67, $0,65 vinieron de los cambios en el código y $1,06 del cambio de modelos y de effort. La comparación se hizo en horario laboral de días de semana, antes y después de los cambios, por lo que no es un experimento riguroso. Al coordinador se le dejó una sola combinación: en medium, las tareas de nivel completo terminaban un 20% más rápido.

Opus 5.5 en medium no mostró una diferencia medible frente a Opus 5 en los resultados ni en los hallazgos críticos, y high costaba más sin un aumento significativo de hallazgos. El precio por token explica solo unos $0,20 de la caída; el resto procede de los menores volúmenes: la lectura de caché por revisión bajó un 82%, la escritura un 54% y la salida un 67%.

El 3 de octubre, los revisores sobre Sonnet se repartieron al 50/50 entre Sonnet 5 y 5.5. Dos días y medio después, Sonnet 5.5 era un 62% más barato en code quality, un 58% en performance y un 47% en security. El precio del token es el mismo; todo el ahorro viene de usar menos tokens. Code quality en 5.5 medium hace 1,7 llamadas en lugar de 6,2, y más de la mitad de las ejecuciones terminan con una sola llamada. En high son 3,4 llamadas, un 61% más de coste por ejecución (unos dos centavos por revisión) y un 58% más de hallazgos críticos y de advertencia, por lo que code quality pasó a high.

La proporción de revisiones de más de cinco minutos bajó del 37,9% al 0,7%, y el percentil 99 es más rápido que tres cuartas partes de las revisiones de abril. Mediana del nivel completo: de 5 min 16 s a 1 min 54 s; lite, de 2 min 58 s a 1 min 14 s; trivial, de 77 a 30 segundos. En paralelo, el revisor pasó a OpenCode v2: en modo sombra, las decisiones de aprobación coincidieron en el 98% de los merge requests, y las revisiones completas en v2 terminan aproximadamente un 13% más rápido. El equipo también está probando ejecutar todo sobre Durable Objects con pi-durable.

La pregunta principal es si la revisión se ha vuelto más superficial. Los hallazgos críticos y de advertencia de code quality son un 40% menos que a finales de agosto; en security, un 56% menos; en performance, un 71% menos. Pero los autores empezaron a actuar sobre los comentarios serios de code quality en el 59% de los casos, frente al 34% anterior, con un nivel de fondo de correcciones aleatorias de alrededor del 15%. El revisor hace menos ruido y ha aumentado la proporción de hallazgos que acaban en una corrección.

Conclusión práctica para quienes construyen agentes: primero, mida de qué se compone la factura (en Cloudflare, el 77% se iba en caché); después, compruebe si la primera solicitud de la sesión llega a un prefijo común; elimine las herramientas que el agente no puede invocar; y solo entonces compare modelos y effort con datos reales. Una nueva generación de modelos puede reducir el número de llamadas varias veces sin perder hallazgos útiles.