Cloudflare is unifying Workers AI and AI Gateway
A useful Cloudflare read about treating AI calls as traffic that needs routing, logs, billing, retries, and control from the start.
Most AI apps have model calls scattered across the codebase with no logging, no cost tracking, and no fallback plan. That’s the same mistake teams made with database calls fifteen years ago.
Source
Unifying Workers AI and AI Gateway into a single AI control plane
By: Cloudflare
Published: Aug 07 2026
Type: Product announcement
AI Gateway and Workers AI started as separate products, but users kept combining them. This post explains why Cloudflare is merging them into one path — and why model-first routing matters more than provider-first routing.
How one control plane changes AI infrastructure
Workers AI gives you inference-as-a-service: call a model hosted on Cloudflare’s GPUs through a binding or REST endpoint. AI Gateway sits in front of any model provider and adds observability, logging, access control, and security. Different architecture, same goal — connect your code to models with a control layer in between. The unification merges both into a single entry point so there’s no choice to make upfront.
The first concrete change is the unified binding. Instead of separate Workers AI and AI Gateway bindings, one env.AI.run() call handles everything. Pass a third argument with { gateway: { id: 'default' } } and every request flows through AI Gateway automatically. If you’ve never created a gateway, the default ID auto-creates one on the first authenticated request. The REST API gets the same treatment through a single /ai/ endpoint with a cf-aig-gateway-id header.
What that default gateway gives you immediately, with zero dashboard setup, is automatic observability. Every request gets logged with full payloads, token counts are tracked per model, and cost attribution works out of the box. Latency breakdowns, error rates, exact prompts and responses — all visible in the AI Gateway dashboard. For teams debugging model behaviour or auditing AI output, this replaces the common state of flying blind.
Billing also merges. Previously, AI Gateway credits worked only with external providers like OpenAI and Anthropic. Now those same credits cover Workers AI usage too. One wallet, any provider. Load credits and spend them across the entire supported catalogue. Using unified billing through AI Gateway also unlocks elevated rate limits on Workers AI models.
The bigger architectural shift is model-first routing, coming soon. Today, calling a model means knowing which provider hosts it. If that provider is down or rate-limiting you, your application breaks and you need retry logic in your own code. Model-first routing flips this: you specify the model you want — say, Kimi K2.7 Code — and AI Gateway selects the provider. If Workers AI has capacity, you get Cloudflare’s managed infrastructure. If it doesn’t, the gateway transparently fails over to another vetted provider hosting the same weights. You can still pin to a specific provider, but model-first routing makes resilience the default rather than a custom engineering project.
Beyond model-first routing, Cloudflare is building smart routing: a classifier running on Workers AI reads your prompt, predicts the task type and complexity, and a heuristic scorer picks the best model from a curated pool — no configuration needed. For teams that want control, explicit model selection still works. For everyone else, the zero-config path optimises cost and performance automatically.
My take
The pattern here mirrors what happened with CDNs and databases. Raw infrastructure starts as direct calls (fetch to a model endpoint, connect to a database), then someone wraps it in a proxy layer that adds caching, logging, failover, and routing. Eventually the proxy becomes the standard way to use the underlying thing. What’s interesting is Cloudflare framing model calls as a routing problem rather than an integration problem. Once your AI traffic flows through one control plane, the platform can do things your application code can’t — like shift traffic between providers mid-request or optimise model selection based on real usage patterns across all their customers. The risk is vendor lock-in at the routing layer, but the alternative is building the same retry/failover/logging logic yourself in every project.
Where this is useful
- When you have more than one AI feature in your app and need per-model cost attribution — the default gateway gives this with one line.
- When you’re worried about provider outages breaking your product — model-first routing makes failover the platform’s job instead of your code’s.
- When your team has scattered
fetch()calls to different model APIs — the unified binding consolidates them into one path with automatic observability.
Apply this: If you’re making model calls without logging token usage and latency, add a proxy layer now. The longer you wait, the harder cost attribution gets.
What I want to remember
Remember: Treat model calls like any other backend dependency. One entry point, automatic logging, cost tracking per model, and failover that doesn’t require application-level retry logic. The proxy layer is the product.