Cloudflare Unificou Workers AI e AI Gateway O Que Muda no Seu Código Hoje

Olha só o que mudou

Se você já mexeu com a stack de IA da Cloudflare, sabe do atrito: Workers AI te dá inferência como serviço em GPUs gerenciadas, AI Gateway te dá observabilidade, cache e controle de acesso entre provedores. Dois produtos, dois entrypoints, dois modelos mentais — mas o mesmo objetivo final: mandar o request pro modelo e ver o que aconteceu.

Pois é, essa divisão tá acabando. A Cloudflare anunciou que Workers AI e AI Gateway convergem num caminho único: você conecta em qualquer provedor (incluindo o próprio Workers AI) e gerencia observabilidade, billing, segurança e logs de um só lugar. Pra quem roda inferência em produção, isso não é feature nova — é mudança estrutural na arquitetura das chamadas.

O raciocínio é simples: do ponto de vista do usuário, os dois produtos já faziam a mesma coisa. A arquitetura era diferente, a intenção não. A convergência só faz a abstração bater com a realidade. O anúncio completo tá no post original de engenharia da Cloudflare.

Vamos lá, dá uma olhada no que isso significa na prática 👇

O que mudou de verdade por baixo do capô

Um binding, um endpoint REST

O binding env.AI não distingue mais entre "Workers AI" e "AI Gateway" — é um caminho só. Mesma coisa na API REST: o endpoint /ai/run/ agora aceita o header cf-aig-gateway-id pra rotear por um gateway.

Olha como fica a chamada via binding, roteando um modelo do Workers AI pelo gateway default:

// worker.js — roteia Workers AI pelo AI Gateway default
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', // 'default' cria o gateway automaticamente no primeiro uso
        },
      }
    );
    return new Response(JSON.stringify(response), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

E o equivalente 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?"}]
  }'

Gateway default = observabilidade sem setup

A vitória mais imediata: você não precisa mais criar um gateway antes. Passa id: 'default' e o AI Gateway provisiona um no primeiro request autenticado. Cada chamada fica logada com payload completo de request/response, contagem de tokens por modelo e atribuição de custo — sem configurar dashboard nenhum.

A diferença é literalmente um argumento:

// Antes — chamada direta no Workers AI, sem visibilidade do gateway
const response = await env.AI.run('@cf/zai-org/glm-5.2', {
  messages: [{ role: 'user', content: 'Olá!' }],
});

// Depois — mesma chamada, observabilidade total via AI Gateway
const response = await env.AI.run(
  '@cf/zai-org/glm-5.2',
  { messages: [{ role: 'user', content: 'Olá!' }] },
  { gateway: { id: 'default' } } // cria o gateway automaticamente no primeiro uso
);

Se o default ficar pequeno — regras de cache customizadas, split de tráfego por aplicação — você cria um gateway nomeado e troca um parâmetro. Sem refatorar código.

Roadmap: model-first e smart routing

Billing unificado entre todos os provedores

Uso do Workers AI agora pode ser pago com créditos da carteira do AI Gateway. Antes, os créditos do AI Gateway só valiam pra provedores externos (OpenAI, Anthropic e cia.). Agora a mesma carteira cobre Workers AI, e a Cloudflare tá oferecendo rate limits elevados pra quem usa billing unificado — um empurrãozinho pra consolidar o gasto no gateway.

Roteamento model-first (em breve)

Essa é a parte arquiteturalmente interessante. Hoje, chamar um modelo significa saber qual provedor o hospeda. Se o provedor cair ou der rate-limit, sua app quebra e você escreve lógica de fallback na mão.

O model-first inverte a dependência:

Você pede kimi-k2.7-code; o gateway decide se aquilo vem do Workers AI, da API da Moonshot ou de outro host verificado servindo os mesmos pesos. Se o Workers AI tem capacidade, você usa infra gerenciada. Se não, o tráfego balanceia de forma transparente. Você ainda pode fixar um provedor se quiser — mas não é mais obrigado.

# Request model-first — sem provedor especificado, o gateway roteia
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"}]
  }'

Smart routing (mais pra frente)

Além do failover, a Cloudflare tá construindo um classificador no Workers AI que lê seu prompt, prevê o tipo de tarefa (coding, research, summarization, Q&A geral), a complexidade e o quanto o contexto importa, e então mapeia heuristicamente pro melhor modelo de um pool curado. Zero-config pra quem não quer manter lógica de roteamento; seleção explícita continua disponível pra quem quer. Hoje tá em piloto interno.

Pontos de atenção que valem a pena

• Lock-in cresce. Quando billing, roteamento e observabilidade vivem num único plano de controle, migrar pra fora vira projeto grande, não troca de SDK.
• Model-first routing não tá no ar. Foi anunciado, tá em piloto interno e é "próximos meses". Projeta pensando nisso, mas não depende ainda.
• Gateway default é conveniente, não é grátis. Logar payload completo significa que o prompt fica na camada de observabilidade da Cloudflare — valida isso contra sua política de retenção e compliance antes de ligar em produção.
• Rate limit elevado é incentivo de billing. É real, mas também é um empurrão pro prepaid. Faz a conta contra seu mix atual de provedores.

Próximos passos

Se você já tá no Workers AI: roteia um endpoint não-crítico via gateway: { id: 'default' } e observa o dashboard por uma semana. Você ganha dados de token e custo que não tinha, com uma linha de mudança.

Se você tá no AI Gateway: tenta adicionar uma chamada de modelo Workers AI no mix e confirma se o billing unificado se comporta como documentado.

Pra quem escala carga de inferência, o problema vizinho — distribuir compute num cluster — vale ser combinado com isso. Dá uma olhada no nosso tutorial prático de Ray + AWS pra escalar Python num cluster na nuvem pro lado de orquestração. E se você tá acompanhando pra onde a inferência tá indo na borda, nosso breakdown de NVIDIA TensorRT Edge-LLM pra veículos autônomos e robótica cobre a fronteira do hardware.

Resumindo

A unificação de Workers AI + AI Gateway da Cloudflare é simplificação arquitetural de verdade, não rebranding de marketing. As vitórias imediatas — gateway default, billing unificado, um binding só — dá pra usar hoje e custam um parâmetro. As vitórias estratégicas — model-first routing, smart routing — são o motivo de se importar com a direção, mas ainda não tão na sua mão.

Trata o gateway default como seu novo baseline de observabilidade. Trata o model-first routing como premissa de design pro próximo trimestre, não como dependência deste. E fica de olho na conta do lock-in conforme o plano de controle absorve mais da sua stack. 🚀