Olha só o que mudou, dev!
Se você já mexeu com IA na Cloudflare, provavelmente ficou naquele dilema: uso AI Gateway ou Workers AI? Os dois produtos existiam separados, mas resolviam o mesmo problema — te conectar a um modelo com uma camada de controle em cima.
- AI Gateway era o proxy: você apontava pra OpenAI, Anthropic ou qualquer provider e ganhava observabilidade, logging, controle de acesso e cache.
- Workers AI era o hosting: a Cloudflare roda as GPUs, você só bate no endpoint.
Agora a Cloudflare tá unificando tudo num único control plane. Bora ver o que realmente mudou e o que vem por aí.
O que já está disponível
1. Um binding, um endpoint REST
O binding env.AI agora roteia pelo AI Gateway por padrão. Se você nunca configurou um gateway, um gateway default é criado automaticamente na primeira requisição autenticada.
// Antes: chamada direta no Workers AI, sem observabilidade
export default {
async fetch(request, env) {
const response = await env.AI.run('@cf/zai-org/glm-5.2', {
messages: [{ role: 'user', content: 'Qual é a capital da França?' }],
});
return new Response(JSON.stringify(response));
},
};
// Depois: mesma chamada, agora com observabilidade completa
export default {
async fetch(request, env) {
const response = await env.AI.run(
'@cf/zai-org/glm-5.2',
{ messages: [{ role: 'user', content: 'Qual é a capital da França?' }] },
{ gateway: { id: 'default' } } // cria automaticamente no primeiro uso
);
return new Response(JSON.stringify(response), {
headers: { 'Content-Type': 'application/json' },
});
},
};
Mesma ideia via REST:
curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/@cf/zai-org/glm-5.2" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
-H "cf-aig-gateway-id: default" \
-d '{"messages":[{"role":"user","content":"Qual é a capital da França?"}]}'
2. Observabilidade vem de fábrica agora
Toda requisição pelo gateway default loga payload completo de request/response, contagem de tokens por modelo e atribuição de custo — sem precisar configurar dashboard nenhum. Se o default ficar pequeno, troca id: 'default' por um gateway nomeado e pronto. Uma linha.
3. Billing unificado (isso aqui é ouro 🔥)
Antes, os créditos do AI Gateway só funcionavam com providers externos (OpenAI, Anthropic). Agora sua carteira do AI Gateway financia o Workers AI também. Carrega crédito uma vez, gasta em qualquer provider suportado. Bônus: os rate limits do Workers AI sobem se você usar o billing unificado.
4. Roteamento model-first (chegando)
Essa é a mudança arquitetural de verdade. Em vez de provider-first ("qual provider eu chamo?"), você passa pra model-first ("qual modelo eu preciso?").
| Aspecto | Provider-first (hoje) | Model-first (em breve) |
|---|---|---|
| Você especifica | Provider + modelo | Só o modelo |
| Failover | Retry manual no app | Gateway resolve |
| Load balancing | Você faz | Transparente |
| Compliance ZDR | Config por provider | Gateway aplica |
Exemplo de request:
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/v1/chat/completions" \
-H "Authorization: Bearer {api_token}" \
-H "cf-aig-gateway-id: my-gateway" \
-H "Content-Type: application/json" \
-d '{"model":"kimi-k2.7-code","messages":[{"role":"user","content":"Revisa essa função"}]}'
Você pede kimi-k2.7-code. O gateway decide se vem do Workers AI, da Moonshot ou de outro host validado — e faz failover transparente se um estiver rate-limited.
5. Smart routing (mais pra frente)
Um classificador no Workers AI lê seu prompt, identifica a tarefa (código / pesquisa / sumarização / QA), pontua a complexidade e escolhe o melhor modelo de um pool curado. Zero config se você não quiser mexer; pin explícito de modelo se quiser.
Cuidados e Limitações (importante!)
Antes de sair migrando tudo, alguns pontos honestos:
- Model-first routing ainda não é GA. A Cloudflare fala em "pilot nos próximos meses". Não desenha sua arquitetura dependendo disso como hard dependency — trata como camada de otimização.
- Gateway default = logging default. Payload completo de request/response vai pro log. Se você lida com PII ou dados regulados, precisa configurar retention, redaction ou um gateway nomeado com política mais restrita. Isso é compliance de verdade, não detalhe.
- Billing unificado é prático, mas ainda é pré-pago. Você carrega carteira. Se o workload explodir e a carteira zerar, as requisições falham — igual qualquer modelo pré-pago. Configura alerta de budget.
- "Providers validados" é caixa preta. A Cloudflare diz que trabalha com providers validados pro model-first routing, mas os critérios não são públicos. Se você tem exigência de vendor (SOC2, residência de dados), verifica antes de confiar no failover automático.
- Rate limit elevado é cenoura, não garantia. Os limites maiores pra quem usa billing unificado são reais, mas promocionais. Não assume que vão durar pra sempre.
Próximos passos
Se você já usa Workers AI: ativa o gateway default. É uma linha de mudança e você ganha logging, token tracking e atribuição de custo na hora. Zero downside.
Se você usa AI Gateway com providers externos: adiciona um modelo do Workers AI no seu roteamento. Billing unificado significa consolidar gasto. Começa com um modelo de embedding barato ou um sumarizador pra testar.
Se você tá construindo resiliência multi-provider: prototipa model-first routing agora, mas mantém fallback. O padrão (especificar modelo, não provider) é o mental model certo, mas a implementação ainda não tá estável.
O quadro geral
A Cloudflare tá construindo silenciosamente a camada de control plane pra toda a stack de IA — não só inferência, mas roteamento, billing, observabilidade e failover. É uma aposta muito maior do que "a gente hospeda GPU". É o mesmo movimento que a AWS fez com API Gateway, mas pra chamadas de modelo.
Pro dev, o takeaway prático é simples: para de escrever retry logic e camada de abstração de provider na mão. Isso agora é infraestrutura. Seu trabalho é escolher o modelo certo pra tarefa e deixar o control plane fazer o resto.