Cloudflare reduz em 68% o custo da revisão de código por IA: de $2,43 para $0,77

O custo médio de uma revisão no revisor de código por IA da Cloudflare subiu de $1,22 para $2,32 entre março e agosto e chegou a $2,43 nas duas semanas mais caras. A arquitetura, porém, não mudou: o coordenador distribuía as tarefas para os mesmos especialistas, e a profundidade da verificação continuava definida pelos mesmos níveis de risco. Em meados de setembro, a equipe pediu aos próprios agentes que descobrissem para onde iam os tokens e cortassem os gastos. O resultado: $0,77 por revisão com o nível alto de esforço ativado na verificação de qualidade de código, uma queda de 68%. Como efeito colateral, o tempo mediano de revisão caiu de 4min09s para 1min32s.

De onde veio o aumento

A estrutura da carga explica só uma pequena parte do encarecimento: a fatia de revisões no nível mais caro (revisão completa) subiu de 59% em março para 65% em agosto, porque os engenheiros passaram a enviar mudanças maiores. A maior contribuição veio das trocas de modelo. No início de agosto, todos os revisores migraram para modelos da Anthropic, que se saíram melhor nessa tarefa nos testes internos. O custo da tarefa subiu de $1,38 para $2,03. O revisor dos padrões internos Codex acabou no Claude Opus 4.7, e o preço dele por revisão saltou de $0,25 para $0,88, mais do que o do próprio coordenador.

Estrutura de gastos antes da otimização: 23% em tokens de saída, 43% em gravação no cache e 34% em leitura do cache. A maior parte do dinheiro ia para contexto que o modelo já tinha visto. O revisor de code quality fazia em média 16,6 chamadas de LLM por revisão, gravava 72 mil tokens no cache e lia 1,08 milhão, porque cada chamada reenvia a conversa inteira.

A taxa de acerto do cache subiu de 85,7% para 97%, mas o número de tokens por revisão passou de 0,91 para 2,99 milhões, e a alta taxa de acerto não compensou isso. Na Anthropic, gravar no cache custa 1,25 vez o preço de entrada e ler custa 0,1; o cache gravado expira após cinco minutos sem acessos.

Prefixo compartilhado e menos chamadas

Desde 14 de setembro, a equipe passou a registrar os tokens da primeira chamada de cada sessão e o hash do primeiro bloco de sistema. Descobriu-se que a primeira requisição encontrava um cache pronto em apenas 14–26% dos casos, embora de 11 a 21 mil tokens de definições de ferramentas e de prompt do agente sejam idênticos em todos os repositórios. A causa estava no OpenCode v1: ele montava um único bloco com o prompt do agente e a seção de ambiente (diretório de trabalho, data) e colocava um único ponto de cache no final. A parte comum não era salva separadamente.

Em 16 de setembro, a equipe adicionou um marcador ao final do prompt, e um plugin passou a dividir o bloco em dois, com o ponto de cache depois da parte comum. Tudo o que é específico de cada repositório foi movido para o fim, e a lista de skills foi desativada. No mesmo dia, o índice de padrões do Codex foi embutido diretamente no prompt: antes, os três primeiros turnos da sessão eram gastos lendo esses arquivos; agora são 9,6 chamadas em vez de 15,9, e o custo de inicialização caiu de $1,12 para $0,72. Juntas, as duas mudanças baixaram o preço da revisão de $2,47 para $2,02.

As correções seguintes, de 21 e 23 de setembro, tiraram cerca de $0,20 de cada revisão:

• A ferramenta de publicação do comentário final foi ocultada dos sub-revisores: em 57–76% das sessões eles tentavam chamá-la, recebiam uma recusa do servidor e gastavam uma chamada extra. A economia é de cerca de 2,9 mil tokens de definições por requisição.
• Leitura paralela de arquivos: em 64% dos turnos, o revisor de qualidade fazia exatamente uma chamada de ferramenta. Agora o contexto comum e todos os patches são lidos na primeira resposta, até 150 KB.
• Revisores pulados em revisões repetidas: cerca de dois terços das tarefas são repetições. Nas revisões completas repetidas, as verificações de AGENTS.md são puladas em 56% dos casos, as de desempenho em 23% e as de documentação em 13%.
• Parada após a publicação da revisão: o OpenCode executava mais um turno só para gerar um resumo invisível, cerca de $0,07 por tarefa.
• O timeout de um revisor lento deixou de ser tratado como falha do provedor; os timeouts do revisor de segurança caíram de 1,8% das execuções para quase zero.
• Cancelamento de tarefas canceladas: das 446 tarefas canceladas no GitLab, 358 continuavam rodando. Agora a tarefa verifica o status a cada 15 segundos.

A correção mais complexa foi o prefixo compartilhado entre os três revisores (code quality, segurança e desempenho): mesmas ferramentas, mesmo arquivo de regras, mesmo merge request com todos os patches. Um revisor grava o cache e os outros dois o leem. Como a gravação só fica disponível depois que o streaming da resposta começa, os demais esperam até 20 segundos. Isso os atrasa um pouco, mas economiza cerca de nove centavos por revisor.

Modelos, esforço e qualidade

Da redução de $1,67, $0,65 vieram das mudanças no código e $1,06 da troca de modelos e de effort. A comparação usou horários comerciais antes e depois das mudanças, portanto não é um experimento rigoroso. Para o coordenador, ficou uma única combinação: em medium, as tarefas de nível completo terminavam 20% mais rápido. O Opus 5.5 em medium não mostrou diferença mensurável nos resultados nem nas descobertas críticas em relação ao Opus 5, e o high custou mais sem ganho significativo de descobertas. O preço por token explica só cerca de $0,20 da queda; o resto veio de volumes menores: a leitura de cache por revisão caiu 82%, a gravação 54% e a saída 67%.

Em 3 de outubro, os revisores em Sonnet foram divididos 50/50 entre o Sonnet 5 e o 5.5. Dois dias e meio depois, o Sonnet 5.5 estava 62% mais barato em code quality, 58% em performance e 47% em security. O preço do token é o mesmo; toda a economia vem do menor número de tokens. O code quality no 5.5 medium faz 1,7 chamada em vez de 6,2, e mais da metade das execuções termina com uma única chamada. No high, são 3,4 chamadas, com +61% no custo da execução (cerca de dois centavos por revisão) e +58% de descobertas críticas e de alerta, por isso o code quality foi migrado para o high.

A fatia de revisões com mais de cinco minutos caiu de 37,9% para 0,7%, e o percentil 99 agora é mais rápido do que três quartos das revisões de abril. Mediana do nível completo: de 5min16s para 1min54s; lite, de 2min58s para 1min14s; trivial, de 77 para 30 segundos. Em paralelo, o revisor migrou para o OpenCode v2: em modo sombra, as decisões de aprovação coincidiram em 98% dos merge requests, e as revisões completas no v2 terminam cerca de 13% mais rápido. A equipe também testa rodar todo o fluxo em Durable Objects com pi-durable.

A pergunta principal: a revisão ficou mais superficial? As descobertas críticas e de alerta do code quality são 40% menores do que no fim de agosto, as de security, 56% menores, e as de performance, 71% menores. Mas os autores passaram a agir sobre os comentários graves do code quality em 59% dos casos, contra 34% antes, com um nível de base de correções aleatórias de cerca de 15%. O revisor faz menos ruído, e a fatia de descobertas que levam a uma correção cresceu.

A conclusão prática para quem constrói agentes: primeiro meça do que a conta é composta (na Cloudflare, 77% iam para o cache); depois verifique se a primeira requisição da sessão cai no prefixo compartilhado; retire as ferramentas que o agente não pode chamar; e só então compare modelos e effort com dados reais. Uma nova geração de modelos pode reduzir o número de chamadas em várias vezes sem perder descobertas úteis.