If you’ve been running AI workloads on Cloudflare, you’ve been managing two separate products: Workers AI for inference on Cloudflare’s GPU infrastructure, and AI Gateway for proxying requests to external providers like Anthropic, OpenAI, and Gemini. As of August 7, 2026, those two products are now one.

The unification isn’t just organizational — the API surface, billing model, and observability stack have merged into a single control plane. Here’s what changed and what it means in practice.

What Changed

Before: You had two paths for AI in Cloudflare Workers:

// Path 1: Workers AI (Cloudflare-hosted models)
const response = await env.AI.run('@cf/meta/llama-3.3-70b-instruct', {
  messages: [{ role: 'user', content: prompt }]
});

// Path 2: AI Gateway (external providers, via proxy URL)
const response = await fetch('https://gateway.ai.cloudflare.com/v1/.../openai/chat/completions', {
  method: 'POST',
  headers: { 'Authorization': `Bearer ${OPENAI_KEY}` },
  body: JSON.stringify({ model: 'gpt-4o', messages: [{ role: 'user', content: prompt }] })
});

After: One binding handles both:

// Unified: same env.AI.run() for both Cloudflare-hosted and external models
const cfModel = await env.AI.run('@cf/meta/llama-3.3-70b-instruct', {
  messages: [{ role: 'user', content: prompt }]
});

const externalModel = await env.AI.run('@anthropic/claude-opus-5', {
  messages: [{ role: 'user', content: prompt }]
});

// Same call signature, same observability, same billing

The @cf/ prefix routes to Cloudflare’s managed GPU fleet. Other prefixes route through AI Gateway to the respective provider. From the Worker’s perspective, it’s the same call.

What You Get From the Unification

Single billing. Prepaid AI Gateway credits now pay for Workers AI inference. Previously you were managing two separate cost centers with different billing cadences. For teams building multi-model pipelines that mix Cloudflare-hosted open-source models with commercial APIs, this simplifies financial management considerably.

Unified observability. Logs, latency metrics, error rates, and cost tracking now flow through a single dashboard for all models regardless of where they’re hosted. If you’re debugging a slow response in a pipeline that calls llama-3.3 and then claude-opus-5, you see both in the same trace.

Consistent access controls. Security policies, rate limiting, and access logging apply uniformly. Previously, Workers AI and AI Gateway had separate configuration surfaces for similar concerns.

Dynamic routing across all models. AI Gateway’s routing capabilities — which already supported load balancing, fallback, and A/B testing across providers — now extend to Workers AI models. You can configure routing rules that fall back from an external commercial model to a Cloudflare-hosted model when latency exceeds a threshold or when the external provider returns errors.

What This Means for Infrastructure Decisions

The unification changes the calculus for several common decisions:

Open-source vs. commercial model routing

Before the merge, mixing Cloudflare-hosted open-source models with commercial APIs required managing two different billing and monitoring systems. The friction was real enough that teams often defaulted to one or the other. Now you can build genuinely cost-optimized routing:

// Route by task complexity with unified cost tracking
async function callModel(task: Task, env: Env) {
  if (task.complexity === 'low') {
    // Cloudflare-hosted Llama: fast, cheap, no external API calls
    return env.AI.run('@cf/meta/llama-3.3-70b-instruct', {
      messages: task.messages
    });
  } else {
    // Commercial model for complex tasks
    return env.AI.run('@anthropic/claude-opus-5', {
      messages: task.messages
    });
  }
}

Both calls are now observable from the same dashboard, billable from the same credits pool, and configurable from the same security policies.

Latency-first architectures

Cloudflare Workers run at the edge — the same infrastructure that serves billions of HTTP requests per day. Workers AI models run on GPU hardware co-located with that edge network. For latency-sensitive applications, routing simple inference tasks to Workers AI-hosted models avoids a round-trip to a centralized API endpoint.

The unified gateway makes it easier to measure and act on that latency difference. You can run A/B tests comparing Cloudflare-hosted inference vs. provider-hosted inference directly in the gateway configuration without changing application code.

Cost predictability

The credits-based billing for the unified system gives teams more control over AI spend. Instead of variable monthly bills from multiple providers, teams can pre-purchase credits and track consumption across the full model portfolio in one place. For organizations with finance constraints around AI spend, this predictability is meaningful.

The Tradeoffs

This is not a free lunch.

Model selection is still constrained on the Workers AI side. Cloudflare hosts a curated set of open-source models — llama variants, Mistral, Gemma, and specialized models for embeddings and image tasks. If you need the latest GPT-5.6 Sol or Claude Opus 5 at full capability, that still routes to the external provider.

The unified system is still Cloudflare-specific. If you’re multi-cloud or need to run the same AI pipeline in AWS or GCP, you’re abstracting this at the application layer, not at the infrastructure layer. The unification is a quality-of-life improvement for teams already committed to Cloudflare, not a reason to move to Cloudflare.

Vendor coupling. Using env.AI.run() for both Cloudflare-hosted and external models makes it easy to switch models, but it locks the pattern to Cloudflare’s runtime. This is the same tradeoff as any platform-native API.

Practical Next Steps for Teams Already on Cloudflare

If you’re running Workers AI or AI Gateway separately today:

  1. Audit your current usage. List which models you call through Workers AI vs. AI Gateway, and what observability you currently have for each.

  2. Consolidate to the unified binding. The migration path is straightforward — replace AI Gateway proxy calls with env.AI.run() calls for external models. The Cloudflare changelog has the exact migration steps.

  3. Implement routing rules. Now that both model types are observable from one place, identify workloads where routing to Cloudflare-hosted open-source models would reduce cost without unacceptable quality degradation. Run the A/B test from the gateway layer.

  4. Consolidate credits. If you had separate AI Gateway and Workers AI budgets, migrate to the unified credits pool to simplify tracking.

The Broader Trend

Cloudflare’s unification is part of a pattern across cloud providers: AI infrastructure is consolidating from “AI as a feature on top of existing services” to “AI as a first-class primitive with its own unified control plane.” AWS has Bedrock, Google has Vertex AI, Azure has AI Studio. Cloudflare’s entry into this space is differentiated by the edge deployment model and the integration with the existing Workers runtime.

For teams that are already deep in the Cloudflare Workers ecosystem, the unified AI control plane is a meaningful quality-of-life improvement that lowers the barrier to building multi-model, cost-optimized AI pipelines. For teams evaluating where to run AI workloads, it makes Cloudflare a more complete option for latency-sensitive edge AI use cases.

Thuận Lương is a Technical Lead with 15+ years in .NET, cloud architecture, and AI systems. He writes about real-world lessons from building production systems.

Export for reading

Comments