Flex, Fast and Priority tiers: picking a service tier for each agent call

For most of the last two years, a model had one price. You picked the model, you paid its list rate per million tokens, and the only real discount was the Batch API, which cut the price in half if you could wait up to a day. That is no longer the whole menu. The same model can now be bought at a cheap, slow, sheddable tier, at the normal tier, or at a premium tier that jumps the queue, and on some providers the price also changes with the time of day. For agent builders this matters more than it does for a chatbot, because an agent makes many calls per task and not all of them need the same treatment. A user waiting on a support reply needs speed. A nightly job that enriches 2,000 CRM records does not.

This piece walks through what each provider actually sells as of November 2026, works through the cost of one agent run on each tier, and covers the part that bites in production: what happens when the cheap tier is full or the premium tier quietly downgrades you.

OpenAI: Flex, Standard, Fast and Ultrafast

OpenAI exposes all of this through one request field, service_tier. Setting it to flex gets you Flex processing, which OpenAI describes as lower cost "in exchange for slower response times and occasional resource unavailability." The key line is that flex tokens "are priced at Batch API rates, with additional discounts from prompt caching." In other words, you get the batch discount without the batch interface. The request is still a normal synchronous Responses or Chat Completions call, which is the whole point for agents: a loop that needs the output of turn three before it can build turn four cannot use a 24-hour batch file, but it can use flex.

The pricing page makes the relationship concrete. GPT-6.1 Sol lists at $2 input and $10 output per million tokens on Standard for prompts up to 272K tokens, and $1 and $5 on Flex. GPT-6.1 Terra goes from $1 and $5 to $0.50 and $2.50. GPT-6 Luna goes from $0.10 and $0.50 to $0.05 and $0.25. Cached input and cache writes are halved too, so Sol's cached input drops from $0.10 to $0.05. Flex is still labeled beta with limited model availability, so check the pricing table for the model you use before you build on it.

The other direction used to be called Priority processing. OpenAI's Fast mode page says Priority "was renamed Fast mode on July 30, 2026," and either service_tier: "priority" or service_tier: "fast" still works. Fast mode promises "up to 2.5× faster speeds and more consistent latency," and on the current flagship models it costs exactly double Standard: Sol is $4 and $20, Terra $2 and $10, Luna $0.20 and $1. There is also an Ultrafast tier for GPT-6 Astra and GPT-6.1 Sol only, at six times Standard. Sol on Ultrafast is $12 input and $60 output.

So for Sol alone, the output price ranges from $5 to $60 per million tokens depending on one string in the request. That is a 12x spread on the same weights.

Google: Flex and Priority on the Gemini API

Google's tiers line up closely. The Gemini Flex inference page describes a 50% discount "in exchange for variable latency and best-effort availability," with a latency target of one to fifteen minutes. Like OpenAI's version, it is synchronous, and Google explicitly pitches it for "sequential API chains where the next request depends on the output of the previous one, making it more flexible than Batch for agentic workflows." It uses off-peak, "sheddable" capacity, so a spike in standard traffic can evict your flex requests.

Priority inference sits on the other side at "75-100% more than the standard API." Both tiers are marked preview. Priority also comes with its own limit: the default is 0.3x your standard rate limit for that model and tier, so you cannot move all of your traffic onto it and expect the same throughput.

Applied to the Gemini 3.8 Flash list price on our model table, currently a promotional $0.75 input and $3.75 output through December 31, Flex works out to about $0.375 and $1.875, and Priority lands somewhere around $1.31 to $1.50 input and $6.56 to $7.50 output. Those are our arithmetic on Google's stated percentages, not separate published numbers, and they move when the promo ends on January 1.

Anthropic and DeepSeek: fewer knobs

Anthropic is going the other way. Its service tiers page now opens with "Service tiers are legacy," and says Priority Tier capacity commitments "are no longer available for purchase." Existing commitments run until their contract ends, and the page lists Claude Opus 5.5, Sonnet 5.5, Haiku 5.5 and Fable 5.1 among the models Priority Tier does not support. For new Claude work the practical options are Standard and Batch. If you want a cheaper Claude call inside a live loop, your levers are prompt caching and model routing, not a tier flag.

DeepSeek prices by the clock instead. Its pricing page says "Off-peak rates are half of the peak rates," with peak hours of 01:00 to 04:00 and 06:00 to 10:00 UTC, Monday through Friday, excluding Chinese public holidays. Everything else, including weekends, is off-peak. DeepSeek V4.1 Flash (deepseek-flash) is $0.30 input and $1.20 output at peak and $0.15 and $0.60 off-peak. In US Pacific standard time, the peak windows work out to roughly 5 PM to 8 PM and 10 PM to 2 AM, Sunday evening through Thursday night, which is exactly when a lot of people schedule their overnight jobs. Moving a nightly DeepSeek run to start at 3 AM Pacific halves the bill without touching code.

Worked example: one enrichment agent, three tiers

Take a background agent that researches a company and updates a CRM record. Each run is ten model turns on GPT-6.1 Sol. On average each turn sends 30,000 input tokens, of which 25,000 are a cached prefix and 5,000 are new, and gets back 1,500 output tokens. Per run that is 50,000 fresh input tokens, 250,000 cached input tokens and 15,000 output tokens.

On Standard, fresh input costs 50,000 × $2 per million, or $0.10. Cached input is 250,000 × $0.10 per million, or $0.025. Output is 15,000 × $10 per million, or $0.15. The run costs $0.275. Cache-write charges come on top, but on OpenAI's table they scale with the tier exactly like everything else, so they do not change the comparison.

On Flex, every one of those rates halves, so the run costs about $0.1375. On Fast, every rate doubles, so it costs $0.55. At 2,000 runs a night that is $275 on Flex, $550 on Standard and $1,100 on Fast. Nobody is reading these CRM updates in real time, so the Fast premium buys nothing here, and the Flex discount is $275 a night for changing one parameter.

The cost you pay instead is time. Gemini's flex target is up to fifteen minutes per request, and OpenAI warns that flex "request timeouts are more likely." If every turn of a ten-turn loop sat near the worst case, one run could take well over two hours. For a nightly batch of independent records that is fine, since you run many in parallel. For anything a person is watching, it is not.

The fallback logic is where the money leaks

The cheap tiers fail differently, and your retry code needs to know which way. OpenAI flex can return 429 Resource Unavailable when capacity is short, and the docs say "You will not be charged when this occurs." OpenAI suggests either retrying with exponential backoff or retrying once on service_tier: "auto" to get Standard. That second option is a business decision, not a technical one. A loop that always falls back to Standard on the first 429 can end up paying full price for most of its traffic on a busy day. If the job can wait, back off and stay on flex. If it has a deadline, set a cap on how many fallbacks a run is allowed, the same way you would set a budget cap.

Google takes the opposite default. Gemini flex has "no server-side fallback," returns 503 or 429 when capacity is full, and leaves retries entirely to you. Also raise your client timeouts. OpenAI's SDKs default to ten minutes and its own flex example raises that to fifteen, while Google recommends ten minutes or more. A short timeout on a flex call does not save money. It throws away a request that was sitting in the queue and makes you start over, and the usual retry rules about idempotency still apply if that turn was about to call a tool with side effects. For very long single calls, background mode is usually a better fit than a socket held open for fifteen minutes.

The premium tiers downgrade instead of failing. OpenAI says that if Fast traffic ramps too quickly, "the system may downgrade some Fast mode requests to standard speeds and charge standard rates," and the response shows service_tier: "default". Gemini Priority does the same when you exceed its limits, billing the overflow at standard rates, and tells you through the x-gemini-service-tier response header. Anthropic returns the assigned tier in usage.service_tier. In every case, the tier you asked for is not proof of the tier you got. Log the returned value next to token counts on every call, or your cost dashboard will price Fast requests that actually ran on Standard, and you will not notice that your premium users are getting standard latency.

A simple way to assign tiers

The cleanest setup we have seen is to tag each agent call with who is waiting on it. If a person is watching a stream, use Standard, and pay for Fast or Priority only on the turns where latency actually loses you users, such as the first token of a reply. If a machine is waiting and the next step depends on the answer, use Flex with long timeouts and a capped fallback. If nothing is waiting until tomorrow and the requests are independent, use Batch, which on Gemini also gets extended rate limits that Flex does not. On DeepSeek, schedule that last group outside the UTC peak windows.

Production LLM systems end up making this kind of latency versus cost trade on almost every component, from caching to routing to tiering. AI Engineering by Chip Huyen is a good wider read on those decisions. For the current numbers, the provider pages linked above are the source of truth. Tier names and rules have already changed this year, and they will probably change again.