Cloudflare Just Merged Workers AI and AI Gateway What the Unified Control Plane Means for Your Stack

The Problem: Two Products, One Job

If you've been building on Cloudflare's AI stack, you've felt the friction. Workers AI gave you inference-as-a-service on managed GPUs. AI Gateway gave you observability, caching, and access control across providers. Two products, two entrypoints, two mental models — but the same underlying goal: get your request to a model and see what happened.

That split is now collapsing. Cloudflare has announced that Workers AI and AI Gateway converge into one unified path, so you connect to any model provider (including Workers AI itself) and manage observability, billing, security, and logging from a single control plane. For teams running production inference, this is less a feature drop and more a structural change to how you architect AI calls.

The rationale is straightforward: from the user's perspective, both products already did the same thing. The architecture differed; the intent didn't. Convergence just makes the abstraction match reality. You can read the full announcement in the original Cloudflare engineering post.

What Actually Changed Under the Hood

One binding, one REST endpoint

The env.AI binding no longer distinguishes between "Workers AI" and "AI Gateway" — it's a single path. The same applies to the REST API: the /ai/run/ endpoint now accepts a cf-aig-gateway-id header to route through a gateway.

Here's the binding call, routing a Workers AI model through the default gateway:

// worker.js — route Workers AI through the default AI Gateway
export default {
  async fetch(request, env) {
    const response = await env.AI.run(
      '@cf/zai-org/glm-5.2',
      {
        messages: [
          { role: 'user', content: 'What is the capital of France?' },
        ],
      },
      {
        gateway: {
          id: 'default', // 'default' auto-creates the gateway on first use
        },
      }
    );
    return new Response(JSON.stringify(response), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

And the equivalent REST call:

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": "What is the capital of France?"}]
  }'

Default gateway = zero-setup observability

The most immediate win: you no longer need to pre-create a gateway. Pass id: 'default' and AI Gateway provisions one on your first authenticated request. Every call is then logged with full request/response payloads, token counts per model, and cost attribution — no dashboard configuration required.

The delta is literally one argument:

// Before — direct Workers AI call, no gateway visibility
const response = await env.AI.run('@cf/zai-org/glm-5.2', {
  messages: [{ role: 'user', content: 'Hello!' }],
});

// After — same call, full observability via AI Gateway
const response = await env.AI.run(
  '@cf/zai-org/glm-5.2',
  { messages: [{ role: 'user', content: 'Hello!' }] },
  { gateway: { id: 'default' } } // auto-creates the gateway on first use
);

If you outgrow the default — custom caching rules, per-application traffic splitting — you create a named gateway and change one parameter. No code restructuring.

The Roadmap: Model-First and Smart Routing

Unified billing across every provider

Workers AI usage can now be paid from your AI Gateway credits wallet. Previously, AI Gateway credits only applied to external providers (OpenAI, Anthropic, and so on). Now the same wallet covers Workers AI, and Cloudflare is offering elevated rate limits for users on unified billing — a nudge to consolidate spend through the gateway.

Model-first routing (coming soon)

This is the architecturally interesting piece. Today, calling a model means knowing which provider hosts it. If that provider is down or rate-limiting you, your app breaks and you write application-level fallback logic.

Model-first routing inverts the dependency:

You ask for kimi-k2.7-code; the gateway decides whether that comes from Workers AI, Moonshot's own API, or another vetted host serving the same weights. If Workers AI has capacity, you get managed infrastructure. If not, traffic load-balances transparently. You can still pin a provider if you want — but you no longer have to.

# Model-first request — no provider specified, gateway handles routing
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": "Review this function"}]
  }'

Smart routing (further out)

Beyond failover, Cloudflare is building a classifier on Workers AI that reads your prompt, predicts task type (coding, research, summarization, general Q&A), complexity, and context sensitivity, then heuristically maps to the best model in a curated pool. Zero-config for teams that don't want to maintain routing logic; explicit model selection still available for teams that do. Currently in internal pilot.

Caveats Worth Flagging

• Vendor lock-in surface area grows. Once billing, routing, and observability all live in one control plane, migrating off is a bigger project than swapping an SDK.
• Model-first routing is not shipped. It's announced, piloted internally, and framed as "coming months." Design for it, don't depend on it yet.
• Default gateway is convenient, not free. Logging full request/response payloads means prompt data lives in Cloudflare's observability layer — verify this against your data retention and compliance posture before flipping it on in production.
• Elevated rate limits are a billing incentive. They're real, but they're also a nudge toward prepaid spend. Run the math against your current provider mix.

Where to Go Next

If you're already on Workers AI: route a single non-critical endpoint through gateway: { id: 'default' } and watch the dashboard for a week. You'll get token and cost data you didn't have before, with a one-line change.

If you're on AI Gateway: try adding a Workers AI model call to the mix and confirm unified billing behaves as documented.

For teams scaling inference workloads, the adjacent problem — distributing compute across a cluster — is worth pairing with this. See our practical Ray + AWS tutorial for scaling Python to a cloud cluster for the orchestration side. And if you're tracking where inference is heading at the edge, our breakdown of NVIDIA TensorRT Edge-LLM for autonomous vehicles and robotics covers the hardware-adjacent frontier.

Bottom Line

Cloudflare's Workers AI + AI Gateway unification is a real architectural simplification, not a marketing rebrand. The immediate wins — default gateway, unified billing, one binding — are shippable today and cost you one parameter. The strategic wins — model-first routing, smart routing — are the reason to care about the direction, but they're not yet in your hands.

Treat the default gateway as your new baseline for observability. Treat model-first routing as a design assumption for the next quarter, not a dependency for this one. And keep an eye on the lock-in math as the control plane absorbs more of your stack.