Cloudflare AI Gateway unified billing and limits

Cloudflare AI Gateway unified billing and limits

Workers AI can be reached through the env.AI.run() binding and through shared /ai/ REST endpoints with Cloudflare authentication. AI Gateway then sits in front of those requests and adds logging, caching, security controls, and billing handling for routed inference.

The billing split is the part that catches people out. Workers AI does not use prepaid AI Gateway credits by default. The gateway needs to be set to Unified billing before Workers AI requests routed through it start deducting from the credit balance. Once that is in place, the gateway becomes the charging point for those requests rather than a separate side path.

That setup also affects model access and account limits. Cloudflare exposes frontier models such as @cf/moonshotai/kimi-k2.6, @cf/moonshotai/kimi-k2.7-code, and @cf/zai-org/glm-5.2 through the same binding and API surface, but the billing mode changes the request ceiling attached to them.

Unified billing turns AI Gateway into the billing path for Workers AI

The practical shift is simple: route inference through the gateway, then let the gateway account for the cost. That makes request logging and cost tracking part of the same path as model access, which is useful when a workload needs more than raw inference and a blob of invoices with it.

A separate gateway ID can be used to split applications and workloads. A default gateway ID can also auto-create a gateway on the first authenticated request, which is handy until everything lands in one bucket and the logs stop being useful. If the point is to keep different services apart, give them different gateway IDs from the start.

AI Gateway also acts as the place to set controls that sit around inference rather than inside it. Caching, rate limiting, and request retries can all be configured there, so the same gateway can shape traffic and record what happened to it. That matters when request volume and token usage start to move together.

Credit drawdown and request caps change once you route through the gateway

With Unified billing turned on, Workers AI requests routed through the gateway deduct from the prepaid balance in real time. There is no batch-style delay hiding the spend until later. If the workload is noisy, the balance moves with it.

The rate-limit change is blunt. Frontier Workers AI models get 50 requests per minute per account, per model when billed with AI Gateway credits. Under standard Workers AI billing, that limit is 20 requests per minute. For anything bursty, that difference is not cosmetic.

Longer-running frontier requests can also take more time to complete, so the higher limit does not mean faster inference. It gives more headroom for concurrent calls, not a shorter wait. If the application assumes quick completions and tries to pile on retries, request logging and retry settings in AI Gateway matter more than they first look.

For workloads with real cost pressure, the useful controls are the boring ones: route through a dedicated gateway, turn on logging, keep an eye on token usage, and set rate limiting where the traffic pattern is known. That gives a cleaner boundary between model demand and credit spend, which is usually where the mess starts.

Tags:

Related posts

Immich | v3.2.2

Immich v3 2 2: small patch fixes cross user face reassign bug, skips faces owned by other accounts, recommended update for users relying on face reassign

Nextcloud | v35.0.0

Nextcloud v35: polished UI, Files and sharing upgrades, better client parity, security hardening, performance and admin gains, developer notes and upgrade tips

Talos Linux | v1.14.1

Talos Linux v1 14 1: Linux 6 18 51, containerd 2 3 5, Go 1 26 8, robustness and edge fixes for BGP, VRF, WireGuard, kubelet, LVM, USB, images published