Several AI providers sell the same model at different speed and reliability levels. A slower tier can be cheaper but may be unavailable at busy times. A faster or reserved tier costs more and aims for steadier response. Choose by how long a user can wait and what a failure costs you.
The tiers that exist
The details change often, so treat this as a map and read current pages before committing.
| Tier type | Tradeoff | Documented example |
|---|---|---|
| Asynchronous batch | Lower rate, results within a window | Both providers checked document a 24 hour window |
| Flexible slower processing | Lower rate, slower, may be unavailable | OpenAI describes requests failing with a resource unavailable 429 that is not charged |
| Standard | Normal rate and limits | Default |
| Premium speed | Faster output at a higher rate | Anthropic documents a fast mode for some models at premium pricing |
| Reserved capacity | Committed throughput | Anthropic lists headers that apply to a priority tier |
What the slow tier asks of you
OpenAI's documentation says its flexible tier suits non-production, lower priority or asynchronous work such as evaluations, data enrichment and background tasks. Slower processing makes timeouts more likely, so you may need to raise the SDK's default timeout. And you must handle the case where a request cannot be served at all.
That last point matters. A tier that can say "not now" needs a retry plan with backoff, and a fallback to the standard tier if the work becomes urgent. See retries and backoff.
What the premium tier asks of you
Faster output is priced above standard, and Anthropic notes that premium speed mode has dedicated rate limits separate from standard ones and that it stacks with other pricing modifiers. Do not put it on work where speed has no value. Put it where a person is waiting and the wait is the product, such as live assistance.
A decision guide
- Is a person waiting? If yes, use standard or a faster tier. If no, continue.
- Can the work wait hours? If yes, use batch. If it only needs to be slower than live, use a flexible tier if your provider offers one.
- Is a missed deadline costly? If yes, avoid tiers that can be unavailable, or build a fallback.
- Does the work share a long prefix? Add prompt caching in any tier, as in how prompt caching works.
- Do you need a guaranteed share of throughput? Ask about reserved capacity rather than assuming it.
Mixing tiers in one product
A common pattern is to route by job type. Interactive chat uses standard. A nightly summary job uses batch. Evaluation runs after each prompt change use the slow tier. Routing by model size and by tier together is covered in choose a model tier by cost and capability.
Keep the routing rule in code and in your documentation, with an owner. When a provider changes a tier, you need to know which jobs are affected.
What to verify before you commit
- The current discount or premium, on the provider's pricing page, not in a blog post.
- Whether discounts combine. The Anthropic page says some multipliers stack, so confirm before building a forecast.
- Whether the tier shares your normal rate limit pool or has its own.
- Data handling terms for the tier, especially if you have retention requirements.
Worked example: routing one product's jobs
The jobs and choices below are illustrative. A product team runs four AI jobs.
| Job | Who waits | Deadline | Chosen tier | Reason |
|---|---|---|---|---|
| In-app assistant | A user | Seconds | Standard | Delay is the product |
| Nightly digest | Nobody | Morning | Batch | Results within a day are fine |
| Prompt regression tests | An engineer, loosely | Minutes to an hour | Flexible slower tier if offered, otherwise batch | Not user facing |
| Live demo for sales | A prospect | Seconds | Premium speed if available | A slow demo costs a deal |
Notice that one provider account serves four different needs. If everything ran on standard, the nightly digest and regression tests would pay for speed they do not use. If everything ran on a slower tier, the assistant would fail the first time capacity was tight.
Building the fallback
For any job on a tier that may refuse work, write the fallback before shipping.
- On a refusal, retry with backoff for a bounded time.
- If the job has become urgent, resubmit to the standard tier.
- If the retry budget runs out, queue it for the next run and alert the owner.
- Record which tier served each request, so you can review the mix monthly.
Reviewing the mix
Once a month, list requests by job, tier and cost. Look for jobs on standard that no one waits for, and jobs on slow tiers that fail often enough to cause pain. Move them. Because providers change tiers and discounts, link the source page in your notes and re-check it.
Contract and data terms
A different tier can come with different terms, so read them. Ask whether retention, data location or support differ for the slower or faster option, and whether your security review covered that tier. If a tier was approved for production in your risk register, record exactly which one. Moving a workload to a new tier is a change like any other and deserves a short review and a record of who approved it.
Questions to put to a provider's sales or support team
Public pages cover the basics, but a few details are worth confirming in writing. Does the slower tier have its own limits, and what happens when capacity is short? Are requests that fail for lack of capacity billed? How long do batch results stay available? Is there a premium speed option for the models you use, and is it generally available or a preview? Do discounts and multipliers combine, and in what order?
Keep the answers with your cost model, with the date and the person who answered. Providers revise these terms, and a written answer from last quarter is easier to challenge than a current public page, so treat it as a lead and recheck the page before you rely on it.
What this means for you
If you run AI work that nobody is waiting on, ask whether a cheaper, slower path exists. Many teams run everything at standard speed out of habit. A nightly job or an evaluation run can often wait, and the documentation of at least two providers describes options built for that. The tradeoff is that you must handle delays and, on some tiers, refusals.
Common mistakes
A common mistake is to move a user-facing feature to a slower tier to save money and then watch complaints rise. Another is to adopt a tier that can say no without writing a fallback. Others forget to raise timeouts for slower processing, assume discounts stack without reading the pricing page, or never review which tier serves each job after the first setup. The cure is a small routing table, a tested fallback and a monthly check of what runs where.
Try it yourself
Click through it at your own pace, or open it full screen. It shows urgent items rising above routine ones. That sorting by urgency is the same decision you make when you choose a tier: the urgent job gets the fast path, and the routine one can wait.
Quick check
Is a slower tier the same as batch?
No. Batch is asynchronous with results later. A flexible tier, where offered, still answers requests inline but more slowly and may refuse when capacity is tight.
Do I pay for a request that was refused?
OpenAI documents that flexible tier requests that fail with the resource unavailable error are not charged. Check your provider's current terms.
Who should use a premium speed tier?
Workloads where a person is waiting and the delay costs more than the premium.
Sources
- Flex processing, OpenAI API documentation
- Batch processing, Claude API documentation
- Pricing, Claude API documentation
- Rate limits, Claude API documentation
Last reviewed: 19 October 2026.
