Codex CLI incorrectly omits service_tier="flex" for gpt-5.6 models

Open 💬 2 comments Opened Aug 10, 2026 by rndm-sklz

What version of Codex CLI is running?

0.147.0

What subscription do you have?

API key

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 24.5.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

warp

Codex doctor report

What issue are you seeing?

Codex CLI reports that the flex service tier is unsupported for gpt-5.6-sol and omits it from API requests. However, the same model and service tier work correctly when sent directly to the Responses API.

What steps can reproduce the bug?

Run:

```bash
codex exec -m gpt-5.6-sol \
-c 'service_tier="flex"' \
-c 'model_reasoning_effort="low"' \
'Reply with exactly: OK'


  ### Actual behavior

  Codex prints:

  Configured service tier `flex` is not advertised as supported
  for model `gpt-5.6-sol` and will be omitted from requests.

  The request succeeds, but without Flex processing.

  ### Expected behavior

  Codex should pass service_tier: "flex" to the API without displaying a warning.

  ### Direct API verification

  The equivalent request sent directly to /v1/responses succeeds:

{
"model": "gpt-5.6-sol",
"input": "Reply with exactly: OK",
"reasoning": {
"effort": "low"
},
"service_tier": "flex"
}


  The API response confirms that Flex was used:

{
"status": "completed",
"model": "gpt-5.6-sol",
"service_tier": "flex",
"output_text": "OK",
"error": null
}

  This suggests that the Codex CLI model capability metadata or validation logic is outdated or inconsistent with the Responses API.

### What is the expected behavior?

_No response_

### Additional information

_No response_

View original on GitHub ↗

2 Comments

jdcodes1 · 9 days ago

Confirmed the mechanism on main @ 1f41cc5d92: the gate is the model catalog, not the API. The bundled models-manager/models.json lists only priority ("Fast") in service_tiers for every gpt-5.6 model — flex isn't advertised — and a configured tier is validated against exactly that list: unsupported_service_tier_warning fires when !model_info.supports_service_tier(tier) and the tier is then omitted from requests (core/src/session/mod.rs#L930-L944). Your direct-API test shows the Responses endpoint itself accepts flex for the same model, so the catalog is simply narrower than reality.

Two fix options:

Catalog: add flex to service_tiers for the models/auth modes where it's valid (it's an API-key billing tier; the catalog currently seems modeled around ChatGPT-auth "Fast" only).
Semantics: treat the catalog list as UI advertisement rather than a hard allowlist — pass an explicitly configured tier through with the warning instead of silently stripping it. The current behavior turns a catalog omission into a functional block, and (as with other catalog-driven gates) the served catalog can drift from what the API accepts at any time.

(2) is more robust: an explicit -c service_tier="flex" is user intent, and the API is the actual authority on validity — let it reject if truly unsupported.

jdcodes1 · 9 days ago

Traced the omission: your configured tier passes through ModelInfo::service_tier_for_request, which silently drops any tier not present in the model catalog's service_tiers list (https://github.com/openai/codex/blob/1f41cc5d92/codex-rs/protocol/src/openai_models.rs#L831-L842). So this isn't a request-builder bug — it's catalog data: whatever models feed (or bundled fallback) codex resolved for gpt-5.6-sol doesn't list flex, even though the live Responses API accepts it. Worse, the fallback ModelInfo used for any slug the catalog doesn't recognize has service_tiers: Vec::new() (models-manager/src/model_info.rs#L152) — meaning every tier is silently stripped for unknown/custom models.

Two fixes, one per layer: (1) catalog — add flex to the 5.6 family's tiers (server-side models feed or bundled data); (2) client behavior — an explicitly configured service_tier that fails the catalog check should produce a visible warning ("flex not in catalog for gpt-5.6-sol; omitting") or, better, be sent anyway and let the API reject it authoritatively. Silently rewriting the user's explicit config to something else is the real defect here; the catalog being stale is just today's trigger.