Cloudflare lança Auto Router: a escolha do modelo sai das mãos do funcionário, com economia de até 30%

A Cloudflare lançou em beta público o Auto Router, recurso do AI Gateway que escolhe sozinho o modelo para cada requisição. No cliente ou no agente, basta indicar cloudflare/auto. A partir daí, o gateway decide se a tarefa exige um modelo de ponta ou se um modelo mais barato resolve. Usando o OpenCode, ferramenta agêntica interna, a empresa obteve economia de até 30% em relação ao uso exclusivo de modelos de ponta. No benchmark próprio de tarefas de escritório, o roteador custou $2,10 contra $5,91 do Claude Opus 5.5, mas ficou atrás dele na taxa de execuções bem-sucedidas.

O gateway escolhe o modelo no lugar do funcionário

A lógica antiga de controle de gastos com IA se baseava em orçamentos, limites e na atribuição dos custos a pessoas específicas. A Cloudflare descreve assim o caminho típico das empresas. Primeiro, todos recebem chaves de API livremente e testam cada ferramenta nova. Depois, sobram algumas soluções principais para programação, tarefas não técnicas e execução de agentes. Mas no OpenCode, no Claude Code e no Codex, quem escolhe o modelo continua sendo o próprio usuário, e muitas vezes ele opta por um modelo mais potente do que o necessário. Não é preciso um Opus para resumir um e-mail ou uma conversa de chat. Ao mesmo tempo, bloqueá-lo também é indesejável para a equipe de segurança.

O AI Gateway já enxerga todas as requisições de usuários, agentes e ferramentas, então pode tomar essa decisão de forma centralizada. A economia fica com a empresa, sem mudar os hábitos dos funcionários.

Esquema em duas etapas: classificador e matriz de pontuação

Primeiro, o gateway monta o pool de modelos permitidos. Ele descarta os que não suportam o formato da requisição ou o modo de execução e leva em conta chaves, configurações de cobrança, políticas de acesso e limites de gastos. Modelos e provedores fora do ar são excluídos temporariamente e voltam após a recuperação.

Em seguida entra em ação um classificador multi-head no Workers AI, implantado em GPUs por toda a rede de borda da Cloudflare. Ele analisa um trecho comprimido da conversa, dando prioridade às mensagens mais recentes, e gera dois conjuntos de sinais. O primeiro traz as probabilidades para 14 categorias de tarefas: programação, planejamento, pesquisa, análise de dados e outras. O segundo traz notas de 1 a 5 em quatro eixos: complexidade, ambiguidade, custo do erro e dependência do contexto anterior.

Esses sinais vão para uma matriz de pontuação separada, onde são combinados com os benchmarks dos modelos. Os pesos foram calibrados em um conjunto de exemplos para os quais o modelo preferido já havia sido definido de antemão. O resultado sai da fórmula utility = qualidade esperada − penalidade adaptativa de custo. Em requisições simples, o preço pesa mais e vence o modelo menor. Conforme a complexidade aumenta, a penalidade diminui e os modelos mais fortes levam vantagem. Na saída, o roteador entrega uma lista ranqueada, e o gateway tenta o primeiro modelo e, se o provedor recusar a requisição, passa para o seguinte.

O ponto forte do esquema é a transparência: é possível ver a categoria e a complexidade previstas para a tarefa e entender por que aquele modelo foi escolhido. Um novo modelo entra sem retreinamento: basta inserir na matriz os pesos de seus benchmarks.

Cache: o custo escondido

Em sessões agênticas longas, como na depuração, o gasto não é definido pela tabela de preços, e sim pela leitura do cache, que fica mais cara à medida que a sessão cresce. Trocar de modelo zera o cache, e o novo modelo precisa gravar todo o contexto de novo. Por isso, dentro de um mesmo turno (o ciclo de processamento de uma única entrada do usuário), o roteador quase sempre permanece no modelo atual. Entre turnos, ele aplica uma penalidade de troca, que cresce junto com o número de tokens no contexto. O modelo com cache ativo é avaliado pela tarifa de leitura, enquanto os demais candidatos entram com o preço integral de regravação do contexto.

Há ainda um segundo custo oculto: a maioria dos modelos não lê os tokens de raciocínio uns dos outros. Depois da troca, o novo modelo pode refazer o que já foi feito, só que cobrando pelas tarifas de tokens de saída. No futuro, a Cloudflare quer que o roteador prefira modelos da mesma família ao trocar.

O que mostrou o benchmark interno

O teste simula um ambiente de trabalho com e-mail, calendário, Slack, arquivos, viagens e finanças. Cada tarefa exige uma resposta verificável ou a execução de uma ação. São 97 tarefas, com três rodadas por modelo, ou seja, 291 tentativas. Os intervalos de confiança de 95% foram calculados por bootstrap com 10 000 amostras.

• cloudflare/auto: 252 de 291 bem-sucedidas, 86,6% (+6,2/−6,9 p.p.), custo total de $2,10, $0,0084 por sucesso • Anthropic Claude Opus 5.5: 281 de 291, 96,6% (+2,7/−3,8 p.p.), $5,91, $0,0210 por sucesso • OpenAI GPT-6 Sol: 245 de 291, 84,2% (+6,5/−6,9 p.p.), $2,64, $0,0108 por sucesso

A Cloudflare diz que o resultado é comparável ao dos melhores modelos de uso diário: o roteador custa 80% do Sol e 35% do Opus. Mas é preciso ler os números com atenção. Em relação ao Sol, o auto tem qualidade semelhante e custa menos.

Já em relação ao Opus, fica cerca de 10 p.p. atrás, e os intervalos não se sobrepõem, de modo que a economia de 2,5 vezes por sucesso foi paga com perda de qualidade.

Para resumos e requisições de rotina, a troca é razoável; para tarefas críticas, não. A empresa também observa que um modelo barato na tabela de preços pode consumir muito mais tokens do que o esperado, e por isso o roteador minimiza o custo previsto de toda a trajetória, e não o preço por milhão de tokens.

Como conectar e o que vem a seguir

É possível começar agora mesmo: durante o beta, o Auto Router é gratuito, e nas configurações do agente ou do cliente basta indicar cloudflare/auto. Faz sentido direcionar primeiro por ele os cenários não técnicos e a programação de rotina, deixando as tarefas com alto custo de erro no modelo de ponta. Para isso, será necessário um benchmark próprio com dados reais, como o da Cloudflare.

Entre os planos estão ampliar o pool de modelos, considerar requisitos de zero data retention na filtragem, levar em conta a capacidade dos provedores, escolher o nível de raciocínio para cada requisição, adicionar suporte completo à Responses API e a WebSockets e testar modelos estruturados de tomada de decisão como classificador primário. Mais adiante, chegará o cloudflare/auto-best, que usará o mesmo pool e o mesmo classificador, mas escolherá o modelo com a maior qualidade esperada, sem considerar o preço.