Flex processing
A lower-priced service tier for ordinary API requests that may respond more slowly and can be temporarily unavailable when capacity is short.
Why it matters. A middle ground between real-time and batch for work that can tolerate slow or retried requests.
How it works
Flex processing is a service tier where you send normal API requests but accept slower responses and the chance of being turned away when capacity is short, in exchange for a lower price. Unlike a batch API, you still call the regular endpoint and get the answer back in the same request.
OpenAI uses the name Flex processing; other providers offer similar lower-priority options under other names, or none. The discount, supported models and how unavailability is signalled vary, and you typically opt in per request with a service-tier parameter.
It suits background jobs, evaluations and data enrichment that need a synchronous interface but not speed. Use longer timeouts, retry with backoff, and fall back to the standard tier for urgent work.
Worked example
Illustrative: if standard output costs $10 per 1M tokens and flex costs half, a nightly job generating 20M output tokens costs $200 on standard or $100 on flex, provided it can absorb slower responses and some retries.
Common mistakes
- Keeping default client timeouts, so slow flex requests are cut off and retried repeatedly.
- Using flex for user-facing requests, where occasional unavailability shows up as errors.
- Having no fallback to the standard tier when flex capacity is unavailable for a long stretch.
See it on a real card: Pricing & cost on Claude Opus 5.5.