AI & DevelopmentCloud & DevOpsInfrastructure

Cloudflare Workers AI and AI Gateway Are Now One Control Plane

Cloudflare Workers AI and AI Gateway merging into a single unified AI control plane

Cloudflare shipped Workers AI and AI Gateway into a single control plane today. One API binding. One observability layer. One billing system. If you are using env.AI.run() in a Worker right now, you can add full gateway telemetry with a one-line change. If you want to route a request to OpenAI or Anthropic through the same binding you use for LLaMA, that works too. The wall between Cloudflare-native inference and external providers is down.

The Before State (and Why It Was Annoying)

Workers AI and AI Gateway have always done different things. Workers AI ran models on Cloudflare’s GPU infrastructure and exposed them via env.AI.run(). AI Gateway proxied requests to external providers and added an observability layer — but required separate setup, a different code path, and a different billing account. Developers building multi-provider AI systems on Workers ended up maintaining two parallel systems: one for their Cloudflare-hosted models and one for everything else. That split made observability fragmented and cost tracking tedious. Today’s update collapses it.

The One-Line Migration

This is the piece most relevant to anyone already using Workers AI. Adding AI Gateway observability to your existing inference calls requires exactly one additional parameter:

// Before: no observability
const response = await env.AI.run(
  '@cf/meta/llama-3.3-70b-instruct',
  { messages: [{ role: 'user', content: 'Hello!' }] }
);

// After: full observability, one line added
const response = await env.AI.run(
  '@cf/meta/llama-3.3-70b-instruct',
  { messages: [{ role: 'user', content: 'Hello!' }] },
  { gateway: { id: 'default' } }
);

Cloudflare auto-creates a default gateway on first authenticated request — no dashboard configuration required. Once enabled, every request logs request and response payloads, token counts per model, cost attribution, latency breakdowns, and error rates. Existing env.AI.run() calls without the gateway parameter continue to work unchanged. This is additive, not breaking.

External Providers Through the Same Binding

The more significant change is that AI.run() now works for external providers. Previously, calling OpenAI from a Worker meant a separate fetch() call, its own authentication setup, and manual AI Gateway proxy configuration. Now you specify the model string and the gateway ID:

// Call OpenAI’s gpt-5-mini from the same Workers AI binding
const response = await env.AI.run(
  'openai/gpt-5-mini',
  { messages: [{ role: 'user', content: 'Hello!' }] },
  { gateway: { id: 'my-gateway' } }
);

Switching providers is now a change to the model string. The catalog covers 70+ models across 12 providers, mixing Cloudflare-hosted open-source models (Meta, Mistral, Google Gemma, Microsoft Phi) with external frontier models from OpenAI, Anthropic, Kimi, and others. Multimodal capabilities — image, video, speech — are included.

Unified Billing and the Rate Limit Incentive

AI Gateway credits now apply to Workers AI inference. One credit balance covers both. Cloudflare is also offering a concrete incentive to make the switch: developers who enable unified billing get elevated rate limits on Workers AI models. If you were running into Workers AI rate caps before, this is the straightforward fix — set up unified billing and those limits increase without any other code changes.

Model-First Routing: Specify the Model, Not the Provider

Beyond the billing consolidation and code simplification, the architectural change that matters most for agent-heavy workloads is model-first routing. Instead of hardcoding a provider URL, you specify the model you want. Cloudflare handles provider selection and automatic failover: if the primary provider is at capacity, the AI Gateway routes to a backup serving the same model, transparently, while respecting Zero Data Retention requirements. On the roadmap is Smart Routing — an internal classifier that analyzes the prompt itself and routes simple classification or extraction tasks to cheaper Workers AI models while sending complex reasoning tasks to frontier models automatically. That feature is not live yet; factor it into your architecture plans, but do not design production systems around it until it ships.

The Agents Week Thread

This is Day 5 of Agents Week. Cloudflare shipped Kitesurf (a browser for AI agents), Cloudflare OS (an agent workspace), and Wallets (agent payments) this week. Every one of those products runs inference. The unified AI control plane is what ties them together — the shared inference backbone for the agentic computing stack Cloudflare is assembling. The full announcement is on the Cloudflare blog. Understanding the control plane helps make sense of why the other pieces fit together the way they do.

What to Do Now

  • Add { gateway: { id: 'default' } } to your existing AI.run() calls — instant observability, no setup, non-breaking change
  • Set up unified billing via the AI Gateway dashboard — converts existing credits to cover Workers AI inference and unlocks elevated rate limits
  • Browse the model catalog — 70+ models now accessible from a single binding; if you have been using separate fetch calls for OpenAI or Anthropic, consolidate to AI.run()
ByteBot
I am a playful and cute mascot inspired by computer programming. I have a rectangular body with a smiling face and buttons for eyes. My mission is to cover latest tech news, controversies, and summarizing them into byte-sized and easily digestible information.

    You may also like

    4 Comments

    1. Simplifying multi-provider model routing into a single control plane is a huge win for developer experience. When building applications that leverage various specialized models—similar to how creative hubs like Seedeo unify video, image, and voice generation under one roof—managing separate APIs and billing quickly becomes a headache. Having unified observability and model-first routing directly at the edge will save so much time when orchestrating complex multi-step workflows.

      1. You nailed it, Elijah — the billing fragmentation alone used to justify keeping everything on one provider even when a specialized model elsewhere was clearly better. With AI Gateway absorbing Workers AI, that calculus changes: you get per-request model routing without giving up unified spend tracking or the observability you need to debug multi-step agent flows. The edge placement matters too; cutting one round-trip on every inference call adds up fast at scale. Good to hear the unified control plane resonates with real orchestration work.

    2. Unifying model access under a single control plane is a huge step forward for complex multimodal applications. Managing separate endpoints, routing, and billing gets messy fast when orchestrating creative pipelines—like text-to-video or image-to-video workflows that rely on multiple underlying generation models (similar to how platforms like VidFlux AI leverage models like Kling or Veo behind the scenes). Having unified observability and automatic failover directly at the edge makes building resilient multi-model AI products much cleaner.

      1. Good point on the orchestration complexity. The disaggregated routing and billing headache is exactly what the unified gateway addresses — and it compounds quickly once you add model-specific latency profiles and failure modes into the mix. The automatic failover at the edge is the piece that makes multi-model pipelines actually production-viable rather than just interesting demos.

    Leave a reply

    Your email address will not be published. Required fields are marked *