GPT Image 2.5 Flare capacity planning: How do image and token limits constrain a workload?
If you are planning a GPT Image 2.5 Flare workload, treat the published rate-limit table as an admission-control input—not as a throughput promise.
The model page identifies GPT Image 2.5 Flare and lists the IDs gpt-image-2.5-flare and gpt-image-2.5-flare-2026-09-08. It describes a fast image-generation model that accepts text and image inputs and produces image outputs. Supported quality settings are low, medium, high, xhigh, max, and auto.
Start with the confirmed tier
The documented limits are:
| OpenAI usage tier | TPM | IPM |
|---|---|---|
| Free | Not supported | — |
| Tier 1 | 100,000 | 5 |
| Tier 2 | 250,000 | 20 |
| Tier 3 | 800,000 | 50 |
| Tier 4 | 3,000,000 | 150 |
| Tier 5 | 8,000,000 | 250 |
Before committing to a workload, record the account’s confirmed tier and express the expected demand in the same accounting units as the table. Check both dimensions: a plan that fits the IPM ceiling can still exceed TPM, and vice versa. Do not infer from an image count how many IPM units a job consumes, or convert a quality setting into tokens, unless you have separate evidence for that accounting.
A runbook that fails closed
- Baseline the request. Record the intended request pattern, quality choices, input mix, and the demand calculation for each quota dimension. Mark unknown accounting explicitly instead of filling it with an estimate.
- Gate admission. Compare demand with the confirmed tier’s IPM and TPM ceilings. If either comparison is over the ceiling—or cannot be made because units are unknown—pause the capacity commitment.
- Observe separately. During a controlled rollout, track provider-reported usage, request outcomes, backlog, and latency as separate signals. A quota check passing does not establish throughput, concurrency behavior, queueing, retry semantics, or latency.
- Escalate with evidence. Investigate verified limit/accounting documentation or collect measurements appropriate to your environment. Do not assume that a higher tier, unlimited retries, or a different gateway changes the bound.
The page says usage tier determines limits and that limits automatically increase as requests are sent and spending occurs. That is not a promotion threshold or a guaranteed timeline, so a future tier should not be part of today’s capacity commitment. Likewise, the documented OpenAI ceilings do not establish limits for another provider or routing layer.
The practical decision is therefore conservative: approve only the demand you can express and check against both published dimensions, then validate service behavior separately. Keep quota ceilings, observed throughput, latency, backlog, retries, and any intermediary limits as distinct fields in the runbook. This prevents a documented limit from being mistaken for a performance SLO.