OpenAI folds rate limits and paid credits into one real-time access decision for Codex and Sora

From a gate to a waterfall

The core change OpenAI describes is conceptual before it is technical. Instead of the system asking 'is this request allowed?' it now asks 'how much is allowed, and from where?' Rate limits, free tiers, credits, promotions, and enterprise entitlements become ordered layers in one decision stack that the engine walks through per request.

For anyone building the surface users touch, that reframing is the whole point. A binary gate produces a hard stop — the 'come back later' experience the post explicitly calls out as frustrating for engaged users. A waterfall produces continuity: when a user exhausts their rate-limit window, the same request keeps going by spending down a credit balance, without the user perceiving a handoff.

From a user's perspective, they don't 'switch systems'—they just keep using Codex and Sora. That's why credits feel invisible: they're just another element in the waterfall.Montana Labs

Why 'invisible' required building it in-house

OpenAI says it evaluated third-party usage billing and metering platforms and rejected them on two requirements. First, real-time correctness: when a user hits a limit and has credits, the system has to know immediately, because delayed counting surfaces as 'surprise blocks, inconsistent balances, and incorrect charges.' Second, reconcilability: the ability to explain why a request was allowed or blocked, how much it consumed, and which limits or balances applied.

The stated reason those platforms fell short is that they only saw one piece of what was happening. Billing and metering tools are built for invoicing and reporting — asynchronous, after-the-fact views. Codex and Sora are interactive products where the billing decision is part of the request path itself. That coupling of billing logic to the live request is why the team pulled it in-house rather than bolting on a metering service.

Correctness traded against instant balance updates

The system is built around three datasets that trigger one another: product usage events (what the user did), monetization events (what they're charged for), and balance updates (how much the credit balance moved and why). Separating them lets OpenAI audit, replay, and reconcile each layer independently. Debits carry a stable idempotency key so retries and worker restarts can't double-charge, and each balance update decrements the balance and writes an attributed record in a single atomic, per-account-serialized transaction.

The notable trade-off is deliberate: balance updates are asynchronous and 'slightly delayed' rather than synchronous. When that delay causes the system to overshoot a user's balance, it automatically refunds the difference. OpenAI states plainly that it chose provable correctness and user trust over strict enforcement — it would rather occasionally let a request through and refund than risk misbilling.

What continuous access changes for the interface layer

The specific implication here is that the guarantee lives in the backend so the frontend can stop hedging. Because usage, billing, and balances are provably correct and settled per request, the interface no longer needs to warn users that a request might not go through, or that a balance might be wrong. The post frames every architectural decision as protecting 'user momentum' — real-time balances prevent interruptions, atomic consumption prevents double-charging.

For teams shipping interactive AI products, this is a concrete example of treating correctness as a product feature rather than a billing back-office concern. The credit prompt only feels seamless in the UI because a distributed, auditable ledger sits underneath resolving each request in one definitive outcome. OpenAI notes the same foundation is meant to extend beyond Codex and Sora, positioning access control as shared infrastructure rather than per-product logic.