Cloudflare réduit de 68 % le coût de ses revues de code par IA : de $2,43 à $0,77

Le coût moyen d'une revue dans le relecteur IA de Cloudflare est passé de $1,22 à $2,32 entre mars et août, et a atteint $2,43 lors des deux semaines les plus chères. L'architecture n'a pourtant pas changé : le coordinateur distribuait les tâches aux mêmes spécialistes, et la profondeur de la vérification restait déterminée par les mêmes niveaux de risque. À la mi-septembre, l'équipe a chargé ses propres agents de trouver où partaient les tokens et de réduire les dépenses. Résultat : $0,77 par revue avec un niveau d'effort élevé pour la vérification de la qualité du code, soit 68% de moins. Effet secondaire : le temps médian d'une revue est tombé de 4m09s à 1m32s.

D'où vient la hausse

La structure de la charge n'explique qu'une petite partie du renchérissement : la part des revues au niveau le plus coûteux (revue complète) est passée de 59% en mars à 65% en août, les ingénieurs envoyant des modifications plus volumineuses. La contribution principale vient des changements de modèles. Début août, tous les relecteurs ont été basculés sur des modèles Anthropic, qui se montraient meilleurs sur cette tâche lors des tests internes. Le coût de la tâche est passé de $1,38 à $2,03. Le relecteur des standards internes Codex s'est retrouvé sur Claude Opus 4.7, et son prix par revue a bondi de $0,25 à $0,88, soit plus que le coordinateur lui-même.

Répartition des dépenses avant optimisation : 23% pour les tokens de sortie, 43% pour l'écriture dans le cache, 34% pour la lecture du cache. L'essentiel de l'argent partait dans un contexte que le modèle avait déjà vu. Le relecteur de qualité de code effectuait en moyenne 16,6 appels LLM par revue, écrivait 72 mille tokens dans le cache et en lisait 1,08 million, car chaque appel retransmet toute la conversation.

Le taux de succès du cache (hit rate) est passé de 85,7% à 97%, mais le nombre de tokens par revue est passé de 0,91 à 2,99 million, et ce hit rate élevé ne l'a pas compensé. Chez Anthropic, l'écriture dans le cache coûte 1,25 fois le prix d'entrée et la lecture 0,1 fois ; une écriture reste valide cinq minutes sans accès.

Préfixe commun et moins d'appels

À partir du 14 septembre, l'équipe a commencé à journaliser les tokens du premier appel de chaque session et le hash du premier bloc système. Il est apparu que la première requête ne trouvait un cache déjà prêt que dans 14 à 26% des cas, alors que 11 à 21 mille tokens de définitions d'outils et de prompt d'agent sont identiques dans tous les dépôts. La cause tenait à OpenCode v1 : il assemblait en un seul bloc le prompt de l'agent et la section d'environnement (répertoire de travail, date), et plaçait l'unique point de cache à la fin. La partie commune n'était donc pas mise en cache séparément.

Le 16 septembre, un marqueur a été ajouté à la fin du prompt, et un plugin a scindé le bloc en deux, en plaçant le point de cache après la partie commune. Tout ce qui est spécifique au dépôt a été déplacé vers l'avant, et la liste des skills a été désactivée. Le même jour, l'index des standards Codex a été intégré directement au prompt : auparavant, les trois premiers tours de la session servaient à lire ces fichiers ; désormais, on compte 9,6 appels au lieu de 15,9, et le coût de lancement est passé de $1,12 à $0,72. Ensemble, ces changements ont fait baisser le prix de la revue de $2,47 à $2,02.

Les correctifs suivants, les 21 et 23 septembre, ont retiré environ $0,20 par revue :

• L'outil de publication du commentaire final a été masqué aux sous-relecteurs : dans 57 à 76% des sessions, ils tentaient de l'appeler, essuyaient un refus du serveur et gaspillaient un appel. Économie : environ 2,9 mille tokens de définitions par requête.
• Lecture parallèle des fichiers : dans 64% des tours, le relecteur de qualité de code faisait exactement un appel d'outil. Désormais, le contexte commun et tous les patchs sont lus dans la première réponse, jusqu'à 150 Ko.
• Relecteurs ignorés lors des revues répétées : environ les deux tiers des tâches sont des revues répétées. Sur les revues complètes répétées, les contrôles AGENTS.md sont ignorés dans 56% des cas, ceux de performance dans 23%, ceux de documentation dans 13%.
• Arrêt après la publication de la revue : OpenCode lançait encore un tour pour produire un résumé invisible, environ $0,07 par tâche.
• Le timeout d'un relecteur lent n'est plus compté comme une défaillance du fournisseur ; les timeouts du relecteur de sécurité sont passés de 1,8% des exécutions à presque zéro.
• Annulation des tâches annulées : sur 446 tâches annulées dans GitLab, 358 continuaient à tourner. Désormais, la tâche vérifie son statut toutes les 15 secondes.

Le correctif le plus complexe est le préfixe commun aux trois relecteurs (qualité de code, sécurité, performance) : mêmes outils, même fichier de règles, même merge request avec tous les patchs. Un relecteur écrit le cache, les deux autres le lisent. L'écriture devenant disponible après le début du streaming de la réponse, les autres attendent jusqu'à 20 secondes. Cela les ralentit légèrement, mais économise environ neuf cents par relecteur.

Modèles, effort et qualité

Sur la baisse de $1,67, $0,65 viennent des correctifs de code et $1,06 du changement de modèles et d'effort. La comparaison porte sur les heures ouvrées avant et après les modifications ; ce n'est donc pas une expérience rigoureuse. Pour le coordinateur, une seule combinaison a été retenue : en medium, les tâches de niveau complet se terminaient 20% plus vite.

Opus 5.5 en medium n'a pas montré de différence mesurable sur les résultats et les constats critiques par rapport à Opus 5, et le niveau high coûtait plus cher sans gain notable de constats. Le prix par token n'explique qu'environ $0,20 de la baisse ; le reste provient de volumes plus faibles : la lecture du cache par revue a chuté de 82%, l'écriture de 54%, la sortie de 67%.

Le 3 octobre, les relecteurs sous Sonnet ont été répartis 50/50 entre Sonnet 5 et 5.5. Au bout de deux jours et demi, Sonnet 5.5 était moins cher de 62% pour code quality, de 58% pour performance et de 47% pour security. Le prix du token est identique ; toute l'économie vient d'un moindre nombre de tokens. Code quality en 5.5 medium fait 1,7 appel au lieu de 6,2, et plus de la moitié des exécutions se terminent en un seul appel. En high, on compte 3,4 appels, +61% sur le coût d'exécution (environ deux cents par revue) et +58% de constats critiques et d'avertissement ; code quality est donc passé en high.

La part des revues de plus de cinq minutes est tombée de 37,9% à 0,7%, et le 99e centile est plus rapide que les trois quarts des revues d'avril. Médiane au niveau complet : de 5m16s à 1m54s ; en lite, de 2m58s à 1m14s ; en trivial, de 77 à 30 secondes. En parallèle, le relecteur est passé à OpenCode v2 : en mode shadow, les décisions d'approbation ont coïncidé dans 98% des merge requests, et les revues complètes sous v2 se terminent environ 13% plus vite. L'équipe teste aussi une exécution entièrement sur Durable Objects avec pi-durable.

La question centrale : les revues sont-elles devenues plus superficielles ? Code quality produit 40% de constats critiques et d'avertissement en moins qu'à la fin août, security 56% de moins, performance 71% de moins. Mais les auteurs agissent désormais sur les remarques sérieuses de code quality dans 59% des cas contre 34% auparavant, avec un niveau de fond de modifications aléatoires d'environ 15%. Le relecteur fait moins de bruit, et la part des constats qui débouchent sur une correction a augmenté.

Conclusion pratique pour ceux qui construisent des agents : mesurez d'abord ce qui compose la facture (chez Cloudflare, 77% partaient dans le cache), vérifiez ensuite si la première requête de la session tombe dans le préfixe commun, retirez les outils que l'agent n'a pas le droit d'appeler, et ne comparez les modèles et l'effort sur des données réelles qu'en dernier. Une nouvelle génération de modèles peut réduire le nombre d'appels de plusieurs fois sans perdre de constats utiles.