De 2,43 a 0,77 dólares por revisión: Cloudflare ha recortado un 68 % lo que le cuesta cada pasada de su revisor de código con IA, y de paso la mediana ha bajado de 4 min 9 s a 1 min 32 s. Lo interesante no es la cifra, sino de dónde salía el dinero: casi todo se iba en contexto que el modelo ya había visto.
Cómo una revisión dobló su coste sin tocar la arquitectura
En abril, una revisión media costaba 1,19 dólares; a finales de agosto, unos 2,46. El diseño era el mismo: un coordinador que reparte el trabajo entre revisores especializados (calidad de código, seguridad, rendimiento, documentación, estándares internos) según el nivel de riesgo del cambio. Lo que cambió fue todo lo demás:
- Modelos: en agosto pasaron todos los revisores a modelos de Anthropic porque rendían mejor en sus evaluaciones, y el coste por trabajo subió de 1,38 a 2,03 dólares. El revisor de estándares internos acabó en Claude Opus 4.7 y pasó de 0,25 a 0,88 dólares por revisión, más que el propio coordinador.
- Contexto: los tokens por revisión se triplicaron, de 0,91 a 2,99 millones. La tasa de acierto de caché subió del 85,7 % al 97 %, pero un 97 % de tres veces más tokens sigue saliendo mucho más caro.
- Cambios más grandes: el 65 % de las revisiones caía ya en el nivel más caro, frente al 59 % de marzo.
Antes de optimizar, el gasto se repartía así: un 43 % en escrituras de caché, un 34 % en lecturas de caché y solo un 23 % en tokens de salida. Tres cuartas partes de la factura era volver a enviar la conversación. El revisor de calidad hacía 16,6 llamadas al modelo por revisión, y cada una reenviaba todo el historial: 72.000 tokens escritos en caché y 1,08 millones leídos.
El fallo: la primera petición nunca acertaba en caché
La caché de prompts de Anthropic guarda prefijos: el principio de la conversación hasta un breakpoint. Escribir cuesta 1,25 veces el precio de entrada, leer 0,1 veces, y una entrada caduca a los cinco minutos si nadie la lee.
Cada sesión empezaba con las mismas herramientas y el mismo prompt de agente, entre 11.000 y 21.000 tokens idénticos en todos los repositorios. Aun así, la primera petición encontraba un prefijo en caché solo entre el 14 % y el 26 % de las veces. El motivo estaba en OpenCode v1: construía un único bloque de sistema con el prompt y, detrás, una sección de entorno con el directorio de trabajo y la fecha, y ponía el único breakpoint al final. La parte común nunca se guardaba por separado, así que una revisión en un repositorio no podía reutilizar lo que había escrito otra.
La solución, desplegada el 16 de septiembre de 2026, fue un marcador al final de cada prompt y un hook que parte el bloque en dos: la mitad común termina en bytes que comparten todos los trabajos y tiene su propio breakpoint. Para que siga así quitaron todo lo específico del repositorio que iba delante: la lista de skills disponibles y cualquier descripción de herramienta que pudiera cambiar entre trabajos.
Ese mismo día metieron en el prompt el índice de referencias del revisor de estándares, que antes gastaba sus tres primeros turnos leyendo ficheros: de 15,9 a 9,6 llamadas por ejecución y de 1,12 a 0,72 dólares. Entre las dos cosas, la revisión bajó de 2,47 a 2,02 dólares.
Menos llamadas, sin perder hallazgos
Después vinieron cambios pequeños que juntos quitaron unos 0,20 dólares por revisión:
- Los subrevisores veían la herramienta que publica el comentario final; entre el 57 % y el 76 % de las sesiones intentaban usarla, el servidor la rechazaba y gastaban otra llamada en recuperarse. Quitarla ahorró además 2.900 tokens por petición.
- Leer todos los ficheros en paralelo en la primera respuesta, en vez de uno por turno (el 64 % de los turnos hacía una sola llamada a herramienta).
- No relanzar revisores sin nada nuevo en las re-revisiones, que son dos tercios de los trabajos.
- Cortar el turno extra que resumía la revisión para nadie: unos 0,07 dólares por trabajo.
- Cancelar de verdad: el ejecutor de Kubernetes de GitLab no avisa al script cuando se cancela un trabajo, y 358 de 446 trabajos cancelados seguían hasta terminar la revisión.
El cambio más fino fue que los revisores de calidad, seguridad y rendimiento envíen una primera petición idéntica (herramientas, reglas compartidas y el merge request completo) y añadan sus instrucciones después. Como una entrada de caché no se puede leer hasta que empieza a llegar la respuesta que la escribió, dos de ellos esperan hasta 20 segundos al primero. Cuesta algo de latencia y ahorra unos nueve céntimos por revisor.
Aun así, el código explica 0,65 de los 1,67 dólares ahorrados; los otros 1,06 vienen de modelos y esfuerzo. Opus 5.5 con esfuerzo medio no mostró diferencias medibles frente a Opus 5, y su menor precio por token solo explica unos 0,20 dólares: el resto es enviar y generar menos. Sonnet 5.5 cuesta lo mismo por token que Sonnet 5, pero en un reparto 50/50 salió entre un 47 % y un 62 % más barato por ejecución porque usa muchos menos tokens.
Lo que se puede aprender
La lección principal es medir lo que de verdad llega al proveedor. Cloudflare no encontró el problema mirando la factura, sino registrando los tokens y un hash del primer bloque de sistema de cada sesión. Si tu agente mete la fecha, la rama o la lista de herramientas delante del prompt común, estás pagando la escritura de caché en cada arranque. Ordenar el contexto de lo más estable a lo más variable es gratis y es lo que más rinde.
La segunda es que abaratar no es lo mismo que empeorar, pero hay que demostrarlo. Con Sonnet 5.5 en esfuerzo alto, el revisor de calidad publica un 40 % menos de hallazgos críticos y de aviso, pero los autores actúan sobre el 59 % (antes el 34 %) y los hallazgos importantes por revisión pasan de 0,28 a 0,30. Lo que desapareció fue ruido: los hallazgos con severidad inflada cayeron un 70 %. En cambio, el revisor de rendimiento con esfuerzo medio sí perdió hallazgos reales, en torno a un 64 % menos de problemas importantes. El esfuerzo alto cuesta un 61 % más por ejecución y da un 58 % más de hallazgos serios, y para calidad de código compensa.
Lo que no es trasladable
El revisor es una herramienta interna montada sobre OpenCode, y el hook que parte el prompt depende de su sistema de plugins. Varias comparaciones son antes y después de cada despliegue, sin grupo de control, y la ventana del "ahora" en el análisis de calidad es de un solo día, con entre 35 y 66 hallazgos por grupo. Las proporciones sirven como orientación; las cifras exactas, solo para su carga.
Fuentes
- Cutting our inference bill by 68% by being obsessive about optimization, Cloudflare Blog, 19 de octubre de 2026.