Picking a Service Tier for a Codex Workload

Four service tiers, and the question "which one should I use" doesn't have a single answer — it has a different answer depending on what a specific workload actually needs, which is exactly why this site treats tier selection as its own decision rather than a footnote on model choice.

Start with the deadline, not the price

Before comparing numbers, ask whether the workload has a real synchronous deadline at all. If a human or another system is waiting on the response within the same request cycle, Batch is off the table regardless of its discount — its completion window is fixed, not negotiable at any price. If nothing is waiting synchronously, Batch becomes the strongest default candidate purely on economics.

Standard is the right default for most interactive work

For anything with a genuine synchronous requirement where latency isn't the binding constraint — most everyday interactive use of Codex falls here — Standard is the tier everything else gets measured against. It's not the cheapest option and it's not the fastest, and for most real work that's exactly the right compromise.

Fast mode earns its premium narrowly

Fast costs a real markup over Standard, and it's worth that markup specifically when latency itself has a cost — a user actively waiting on a response, a step on a critical path where every second of delay compounds downstream. For a background task or anything where a few extra seconds genuinely don't matter, Fast's premium is money spent on a benefit nobody's actually collecting. It's also worth checking whether Fast is even offered for your model before planning around it — several models, including some of the largest, don't publish a Fast tier at all.

Batch versus Flex, once you've ruled out Standard and Fast

Both carry the same per-token price, so nothing about cost tells you which one to reach for — the decision comes down entirely to whether the job needs a fixed completion window or can tolerate less certain timing. A large batch of overnight embeddings, or a bulk data-labeling pass that just needs to finish before morning, is a clean fit for the one that commits to a window. The full case for why identical pricing doesn't mean identical products is worth reading on its own, since it's easy to assume the two are interchangeable until something actually slips past a deadline.

Mixing tiers within one workflow

A single pipeline doesn't have to pick one tier for everything it does. A CI job that runs a fast, interactive check on every commit and a much larger nightly analysis pass is a natural candidate for Fast or Standard on the first and Batch on the second — two genuinely different deadline profiles within the same overall system, priced accordingly rather than forced onto a single tier that's wrong for one of the two.

Re-checking the decision as a workload matures

A tier chosen when a workflow was small and exploratory doesn't automatically stay the right choice as it scales — a prototype run occasionally on Standard because nobody had gotten around to batching it yet is a reasonable candidate for a Batch migration once it's running regularly at real volume, and the batch vs realtime savings calculator makes that comparison concrete rather than a vague sense that "we should probably batch this eventually."

The tier that costs nothing to consider

Checking tier options costs nothing but a few minutes against a calculator — it's one of the few genuine free lunches in cost planning here, since the same tokens simply cost less under Batch or Flex with no change to the actual work being done. Any workload currently running Standard by default, without anyone having deliberately chosen it, is worth that few minutes of review.

A short decision sequence worth memorizing

None of the four tiers is a universal right answer, which is exactly why a short, repeatable sequence of questions is more useful here than a rule of thumb based on price alone. In order: does this need a synchronous response within the request cycle? If no, Batch or Flex, chosen on whether you need the fixed completion guarantee. If yes, does latency itself carry a real cost for this specific call? If yes and the model offers it, Fast. If no, Standard. That four-question sequence covers the large majority of tier decisions this site sees reason to write about, and it's worth having as a mental default rather than re-deriving the tradeoffs from scratch on every new workload.

Tier choice interacts with rate limits, not just price

It's worth remembering that Batch draws from a separate rate-limit pool from your standard per-model RPM/TPM — which means a tier decision isn't purely about price even when it looks that way. A workload that's actually constrained by standard-tier throughput rather than price can sometimes be better served by moving to Batch specifically to get out from under that shared pool, independent of whether the discount itself was the original motivation.

Documenting the choice, not just making it

For a production workload, writing down which tier was chosen and why — a short comment in the code or the pipeline configuration, not a lengthy justification — saves a future maintainer from re-litigating a decision that was already made deliberately, or worse, from quietly changing it without realizing there was a reason behind the original choice. A tier picked without documentation looks, six months later, exactly like a tier that was never actually chosen at all — and it invites exactly the kind of well-meaning "why is this on Batch, let's switch it to Standard for simplicity" change that quietly reintroduces the cost this decision was made to avoid in the first place.