OpenAI service tier support

I'd like to see this implemented, service_tier = priority would be nice for people who want lower latency responses, even if it costs more.

I support this. I tried codex cli for two days of work, not for production to learn and made great progress until it abruptly and rudely presented me with '🖐  You've hit your usage limit. Upgrade to Pro (https://openai.com/chatgpt/pricing) or try again in 4 days 1 hour 57 minutes." I am sure ya'll know what I mean. I am on the Plus plan, but a hobby developer. I wish we could instead 'auto switch' to a 'pay as you go' during the 'time-out' period, (happy to accept slower response) and then auto-switch back after 'time limit' resets. I know there is an option to use setx and your key, but that is a pain. make it easier to switch modes please.

+1 supporting this. Question, what's the current default service_tier set for ChatGPT Plus/Pro users?

Hi

Do we have any news about service_tier in Codex?

Ability to use GPT 5.1 high with priority service_tier would be awesome for our team
By default, it's very slow

@it-sha, thanks for your interest. We generally prioritize features based on community feedback. This has received some upvotes, but there are many features that are ahead of it in the priority list.

I was going to create an issue for this if did not exist. But turns out it does, +1 for this feature.

FYI open code already supports it. I created https://github.com/anomalyco/opencode/issues/11597 to handle price

This would also be great for background task completion. We create many tasks for our coding agent to complete and running in flex mode during non-peak hours would help us save on cost significantly.

upvote

guys you can fix it locally. I fixed it by patching the client-side service-tier rehydration path, the one that rewrites default-service-tier. it happens mainly on launch/reload. and post-auth. this solved it for me.

I'm confused if this is currently supported or not.

There is a flag for it in https://developers.openai.com/codex/config-reference but when I run it locally, the models seems faster than otherwise

Yeah it's supported (at least for API all 3, for sub normal and fast), the issue should be closed I think.

Hmm, I'm on api key, just was a bit surprised with the speed of the flex tier, thanks

An overnight batch mode would be quite useful. Sometimes we issue many jobs that are picked up and reviewed the next day (and sometimes we also know roughly how many tokens they will consume because we've run them many times before). Providing OpenAI with this information ahead of time could allow you guys to schedule it to optimize data center usage and perhaps pass on some of those savings on to your users ,-)

Great idea. /slow for overnight grinding. /fast for real time collaboration.

I also have a doubt whether the config.toml setting actually works. I have another app that definitely uses the flex tier through Node.js bindings, and in the Usage > Spend categories area of platform.openai.com, flex-tier requests are clearly distinguished from from normal tier ("flex |" prefix). Illustrative example below.

<img width="426" height="530" alt="Image" src="https://github.com/user-attachments/assets/6d1c7ede-6025-4dee-99bb-5399dd121b1c" />

When I look at the Spend categories for the API key I'm using with Codex CLI, none of the categories are "flex |". Of course it's possible the first-party codex CLI app uses the API in some special way that makes the usage viewer lose the distinction. But doubt is sown....

Codex self-diagnosed the problem to flex not being listed as an available service tier here:

https://github.com/openai/codex/blob/81f340436c6ecd7cf7ed2fdc5199c5e3597f5cf9/codex-rs/models-manager/models.json#L85-L91

(for GPT-5.5, but flex is not mentioned anywhere in that file)

The config.toml service_tier setting is silently omitted from the API request if the value is not found in that list for the chosen model.

The following workaround seems effective any way I've looked at it:

Splice flex into the models.json service_tiers...

Save it as a model catalog file:

jq '
  {
    models: [
      .models[]
      | select(.slug == "gpt-5.4")
      | .service_tiers = (
          (.service_tiers // [])
          + [
              {
                "id": "flex",
                "name": "Flex",
                "description": "Flexible processing"
              }
            ]
          | unique_by(.id)
        )
    ]
  }
' ~/.codex/models_cache.json > ~/.codex/gpt-5.4-flex-catalog.json

...and set ~/.codex/config.toml to use it:

model_catalog_json = "/home/YOUR_USERNAME/.codex/gpt-5.4-flex-catalog.json"
service_tier = "flex"
model = "gpt-5.4"
model_reasoning_effort = "medium"

----

Naturally, I tried this first with GPT-5.5 and it works, but the frequency of turn-ending ⚠ Selected model is at capacity. Please try a different model. errors was much too high to be worth the frustration. GPT-5.4 has been pleasantly usable (still happens occasionally of course), while cheaper anyway and very capable.

If technically feasible, it would be really nice to support flex and adapt the harness around it, even with multi-agents v2.