Cloudflare has merged Workers AI and AI Gateway into a single control plane. Teams managing agents in production now have observability, billing, and dynamic routing across managed GPUs and external providers from a single interface, with unified bindings and model-first routing.

Why this matters to you. If you’re shipping agents to production, the real problem is managing who calls what, how much each call costs, and what happens when a provider goes down: not which model to pick. Until now, Cloudflare users had to treat managed inference (Workers AI) and routing gateway (AI Gateway) as separate systems, two logging systems, two counters, two configurations.

Now routing decides at runtime based on the requested model and provider health. If an endpoint is slow or has rate limiting active, the request routes elsewhere without the agent noticing. For teams running agents around the clock, that means fewer custom pipelines and less time chasing scattered logs.

This move fits the pattern we’ve tracked this week: on August 5, Cloudflare published the zero trust model for shipping agents to production, and on August 7 it closed the infrastructure stack with stateless browsers, stateless MCP, and payments. The unified control plane is the piece that ties governance and routing together: the final layer of the same architecture.

If you want to try it. Documentation for the unified control plane is on the Cloudflare blog. Before configuring unified bindings on your agents, it’s worth checking the actual availability of the models you use on Cloudflare’s managed GPUs, because the catalog doesn’t match external providers.

In detail

What it was before.

Workers AI and AI Gateway were two products with two purposes. Workers AI ran open-weight models on Cloudflare’s edge GPUs: managed inference, pay-per-token, nothing to orchestrate. AI Gateway was a proxy sitting in front of external providers (OpenAI, Anthropic, Google) to add caching, rate limiting, logging, and fallback. Anyone wanting both had to manage them manually: two dashboards, two routing logics, two billing systems.

What changes.

Unification brings everything under a single control plane. Key concepts for non-developers:

• Unified bindings. In Cloudflare Workers, a binding is how code connects to a service. Now a single binding gives access to both models managed on Cloudflare’s GPUs and external providers. No more two separate configurations.
• Model-first routing. Instead of specifying an endpoint and provider, you request a model by name. The system figures out where to serve it: on its own infrastructure, on an external provider, or across both with fallback.
• Observability and billing in one place. Logs, metrics, and billing converge in a single view. For teams with agents in production, this solves the practical problem of understanding what each call actually costs and where things break.

How it fits the bigger picture.

Cloudflare is building a complete stack for agents in production: runtime, stateless browser, stateless MCP, autonomous payments, zero trust. The unified control plane is the governance layer that ties the others together. If the runtime decides where the agent runs and the protocol decides how it talks to tools, the control plane decides which model responds and what it costs.

Limitations and open questions.

The Workers AI catalog (models managed on Cloudflare’s GPUs) remains smaller than external providers. If an agent needs a specific frontier model, model-first routing sends it to an external provider, but the single-pane-of-glass advantage narrows to governance without cutting inference costs. The post doesn’t detail how dynamic routing evaluates latency and availability in real time, or how transparent provider fallback is for the agent or if it requires state management.

As with all this week’s announcements, field testing will show whether unification is real in billing and logs or just a cosmetic layer over two still-separate systems.