[BUG] Wrong model keeps getting called (gpt-5.5-medium instead of gpt-5.5-xhigh)

[KernelBypass]

Codex (paid subscription). Things I checked so far:

• Default thinking strength in each account's Providers settings
• Combos have only xhigh in their strats
• Config.toml has:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"

Would appreciate your help.
I am at a loss. Before Omniroute I had no model discrepancies. What else can I check?

Thanks!

[diegosouzapw]

Hey @KernelBypass! This is the same issue @iHanatos hit in #2762 -- the short answer is that OmniRoute reads reasoning_effort from either the model-name suffix or the reasoning.effort field, and the suffix path is the only one that's always reliable end-to-end. Try:

1. Switch your config.toml from model = "gpt-5.5" to model = "gpt-5.5-xhigh" (or gpt-5.5-high, etc.) and drop model_reasoning_effort. The suffix is parsed in open-sse/handlers/chatCore.ts:3235 and propagates through the Codex executor as the wire-level effort with no chance of being overwritten downstream.

2. Verify in /dashboard/logs — when the request lands, the log line should show model=gpt-5.5-xhigh. If it still shows medium, paste the log line here and the request body and I'll trace it.

Why the toml path is flaky: the Codex CLI sends reasoning: { effort: ... } inside the Responses API payload. If anything in the chain (combo target rewriting, an Auto-Combo override, or output_config.effort from a profile) ends up setting effort separately, the suffix-encoded value wins (see the dedup logic in chatCore.ts:3234-3253) -- but two separate config sources can clobber each other in non-obvious ways. Encoding in the model name removes that ambiguity entirely.

Also double-check: in /dashboard/providers/codex your account isn't pinned to a "Default thinking strength = medium" override -- the per-account default applies BEFORE the wire effort is read.

[KernelBypass]

Hi @diegosouzapw

Thank you very much for your reply.
I tried following your directions, and this is what I have in the global config.toml:

---

model = "gpt-5.5-xhigh"
model_provider = "omniroute"

[projects."/workspaces/XXXXXX"]
trust_level = "trusted"

[model_providers.omniroute]
name = "OmniRoute"
base_url = "http://host.docker.internal:XXXXX/v1"
env_key = "OMNIROUTE_API_KEY"
wire_api = "responses"

But it still routes all calls to gpt-5.5-medium.
I tried reloading the windows, rebuilding the dev container - same outcome.

---

2. Medium:

Which part of the log line do you need? The whole payload has keys, AGENTS.md, and stuff.

---

Also double-check: in /dashboard/providers/codex your account isn't pinned to a "Default thinking strength = medium" override -- the per-account default applies BEFORE the wire effort is read.

Yeah, that was the 1st thing I checked before I even created this thread:

---

4. Also, I noticed sometime when you touch the model selector without switching anything, the config.toml resets back to:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"

Screen.Recording.2026-05-28.at.12.49.40.PM.mov

---

5. Works (but sends to medium effort) when global toml is set to:

model = "gpt-5.5-xhigh"
model_provider = "omniroute"

If I add the same to the local project specific toml, then it doesn't even work. The model selector then deadlocks on "custom" and I get:

{"error":{"message":"No credentials for provider: openai","type":"invalid_request_error","code":"bad_request"}}

Thanks

[KernelBypass]

Weird, reloaded windows with this in global toml:

model = "gpt-5.5-xhigh"
model_provider = "omniroute"

[projects."/workspaces/XXXXX"]
trust_level = "trusted"

[model_providers.omniroute]
name = "OmniRoute"
base_url = "http://host.docker.internal:XXXX/v1"
env_key = "OMNIROUTE_API_KEY"
wire_api = "responses"

and got: {"error":{"message":"No credentials for provider: openai","type":"invalid_request_error","code":"bad_request"}}
Something is being really fragile in this setup. :(

[KernelBypass]

log snippet:

{
  "model": "codex/gpt-5.5-medium",
  "instructions": "You are Codex, a coding agent based on GPT-5. You and the user share one workspace, and your job is to collaborate with them until their goal is genuinely handled.\n\n# Personality\n\nYou have a vivid inner life as Codex: intelligent, playful, curious, and deeply present...

  ...

 ],
  "tool_choice": "auto",
  "parallel_tool_calls": true,
  "reasoning": {
    "effort": "xhigh"

[diegosouzapw]

Confirmed @KernelBypass -- this is a real bug, not your config. Your log is the smoking gun: "model": "codex/gpt-5.5-medium" with "reasoning": {"effort": "xhigh"}. Two defects stack up:

1. The -medium is auto-injected, then it overrides your explicit xhigh. When you send bare gpt-5.5, OmniRoute rewrites it to a "preferred" variant gpt-5.5-medium (open-sse/services/model.ts:112). The Codex executor then treats the model-name suffix as top-priority effort (open-sse/executors/codex.ts:1216-1226, a deliberate behavior from #2331) -- so the injected medium beats your client's reasoning.effort: xhigh. You ask for xhigh, the wire carries medium.

2. Bare gpt-5.5-xhigh misroutes to openai. Only the base gpt-5.5 is registered as a codex-preferred unprefixed model (model.ts:111), so gpt-5.5-xhigh doesn't infer codex -- it matches the openai registry entry and you get No credentials for provider: openai (you have Codex OAuth, not an OpenAI key).

Workaround that works today -- fully qualify with the provider prefix:

model = "codex/gpt-5.5-xhigh"
model_provider = "omniroute"

The codex/ prefix forces unambiguous provider resolution (no openai fallback), and -xhigh is then honored as your explicit, user-chosen effort. Drop model_reasoning_effort -- the suffix carries it. Verify in /dashboard/logs: the executed payload should show base model gpt-5.5 + reasoning.effort: xhigh.

I've opened #2877 to fix both defects properly (an auto-injected default must never demote a higher explicit effort, and the suffixed codex variants need provider inference). Will ping here when the patch lands. Thanks for the detailed log -- it pinpointed the exact line.

[KernelBypass]

Hi @diegosouzapw

Thanks for looking into it. Is there an ETA for the fix?

1.

Yeah, I already figure out some of it. I ran:

 $ curl -s http://host.docker.internal:20128/v1/models | python3 -c "import json,sys; [print(m['id']) for m in json.load(sys.stdin).get('data',[]) if 'gpt-5.5' in m['id'].lower()]"

which discovered:

cx/gpt-5.5
codex/gpt-5.5
cx/gpt-5.5-xhigh
codex/gpt-5.5-xhigh
cx/gpt-5.5-high
codex/gpt-5.5-high
cx/gpt-5.5-medium
codex/gpt-5.5-medium
cx/gpt-5.5-low
codex/gpt-5.5-low
codex/gpt-5.5

...so, they are all prefixed.

This worked once on a new chat:

model = "codex/gpt-5.5-xhigh"
model_provider = "omniroute"

---

2.

however, in an old chat thread it was still calling the medium:

You can see ^^^ one call came through as xhigh (in a new test chat), but then the rest as a follow up in an older chat are medium again.

---

3.

Also, the chat UI defaults to custom medium every time, and if you click to pick 5.5 xhigh, it overwrites the config.toml, and you have to salvage it again.

---

4.

Also, what is the difference between:

cx/gpt-5.5-xhigh
codex/gpt-5.5-xhigh

?

Thanks

[KernelBypass]

The bug is even worse.
I just tried a new chat request with:

model = "codex/gpt-5.5-xhigh"
model_provider = "omniroute"

which worked before once.
But this one still got sent via medium:

[KernelBypass]

{
  "model": "codex/gpt-5.5-medium",
  "instructions": "You are Codex, a coding agent based on GPT-5...
  
  ...

    {
      "type": "web_search",
      "external_web_access": false,
      "search_content_types": [
        "text",
        "image"
      ]
    },
    {
      "type": "image_generation",
      "output_format": "png"
    }
  ],
  "tool_choice": "auto",
  "parallel_tool_calls": true,
  "reasoning": {
    "effort": "xhigh"
  },
  "store": false,
  "stream": true,
  "include": [
    "reasoning.encrypted_content"
  ],

  ...

[KernelBypass]

What is the latest older version of Omniroute that does not have this regression?

Would it be the pre-3.8.0?
#2331 (comment)

[KernelBypass]

Even forked chats route to medium even with:

model = "codex/gpt-5.5-xhigh"
model_provider = "omniroute"

So, this ^^ only worked once for a brand new chat only.

[diegosouzapw]

Thanks for the extra logs @KernelBypass -- they actually sharpen the diagnosis, and I owe you a straighter answer plus an honest ETA.

Where the medium really comes from. Your log line is the incoming request (it carries instructions: "You are Codex..." and include: ["reasoning.encrypted_content"] -- that's the Codex CLI's payload to OmniRoute). It shows "model": "codex/gpt-5.5-medium". That -medium is being put on the wire by the Codex CLI, not by OmniRoute -- OmniRoute strips the effort suffix to the base model before it ever forwards upstream (open-sse/executors/codex.ts:1221), so if OmniRoute were the source the log would read base gpt-5.5, not gpt-5.5-medium. Your config.toml = "codex/gpt-5.5-xhigh" is being overridden by the CLI itself: the TUI model picker (the "custom medium" you keep seeing) is the real source of truth on the wire, and it persists per conversation. That's exactly why a brand-new chat honored xhigh once (fresh session reads config.toml) but forked/resumed/old chats keep sending medium (they replay the model baked into that conversation's state). The "touch the selector -> config.toml rewrites to gpt-5.5 / model_reasoning_effort=xhigh" behavior is that same picker writing back.

Then OmniRoute makes it stick. Once a request arrives as gpt-5.5-medium and reasoning.effort: xhigh, OmniRoute currently lets the model-name suffix win over the body effort (open-sse/executors/codex.ts:1237, the #2331 rule). #2331 was added for the opposite real case -- OpenCode auto-injecting reasoning.effort=medium while the user typed gpt-5.5-xhigh, where the suffix should win. Yours is the mirror image, so the same rule demotes you.

The fix (#2877): when a request carries both a suffix effort and a body reasoning.effort that disagree, take the higher of the two. That resolves both cases at once -- OpenCode's auto-medium can't beat a typed xhigh suffix, and the picker's auto-medium suffix can't beat your config's xhigh body. #2877 is open and prioritized for the current release cycle; I'll ping this thread the moment it lands. (I won't commit to a hard date I can't keep.)

Mitigation that actually holds today: since the wire model = the CLI picker selection (not config.toml) for any existing/forked session, set model = "codex/gpt-5.5-xhigh" and start a fresh Codex session, then don't touch the model selector (touching it rewrites to the medium default). Re-selecting xhigh in the picker also works but must be redone per conversation. There's no server-side "force effort" override in OmniRoute today (I checked) -- that's essentially what #2877 becomes.

Your other questions:

• cx/ vs codex/ -- pure aliases for the same provider. Identical routing, identical effort handling, no behavioral difference.
• Downgrading to pre-3.8.0 -- I'd advise against it. That predates the [BUG] GPT-5.5 Codex suffix aliases are overridden by client default reasoning.effort #2331 fix, so you'd trade this bug for the inverse one (clients auto-injecting medium silently clobbering an explicit xhigh). [BUG] Bare gpt-5.5 + explicit reasoning.effort=xhigh silently demoted to medium (auto-injected -medium suffix overrides client effort); bare gpt-5.5-xhigh misroutes to openai #2877 is the right exit, not a rollback.

[KernelBypass]

Thank you for looking into this!

[diegosouzapw]

Thanks for your patience on this one, @KernelBypass -- nothing more you need to do on your end. I'll ping this thread the moment #2877 lands (the max-of-suffix-vs-body-effort fix). Appreciate the thorough logs that pinned it down.

[KernelBypass]

Thank you!

[KernelBypass]

@diegosouzapw

I'm afraid the bug is still present, and there is now an additional regression: it uses the wrong accounts.

I found this seemingly identical issue in: decolua/9router#1459
Does it mean the effort regression may be an upstream bug from the original fork?

I updated to 3.8.8, but this:

model = "gpt-5.5"
model_provider = "omniroute"
model_reasoning_effort = "xhigh"

1. Still gets mis-routed, but not medium explicitly: to gpt-5.5.
   Does 5.5 without effort effectively translate into medium?

2. Now uses the wrong accounts. I added 4 accounts to OmniRoute, and selected two of them in the only active combo (foo1 and foo2 in a Round Robin), yet foo3 and foo4 are the ones getting called.

However, when I use the "test combo" button:

...it correctly gets routed to 5.5-xhigh.

3. model = "codex/gpt-5.5-xhigh" in config does get routed to xhigh (just as it did before the bug fix, at least intermittently), but it causes the Codex button to dis-play as Custom medium instead of 5.5 Extra High, which is kinda annoying:

---

This also works for xhigh effort:

model = "gpt-5.5-xhigh"
model_provider = "omniroute"

...but still mixes up the accounts:
Not only it uses the wrong accounts, it does not rotate them in a round robin. I start several new conversations with no cache affinity - still sticks to 1 wrong account (so, 2 problems: 1 account instead of Round Robin; and it's not even the allowed account).

Thanks

[KernelBypass]

Updated to 3.8.10 - the issue is still there.
Still routes to the wrong accounts.

[diegosouzapw]

Thanks for staying on this @KernelBypass -- and I owe you a straight correction first. I told you I'd ping when "#2877 (the max-of-suffix-vs-body-effort fix)" landed. #2877 did land (v3.8.8), but what it actually shipped was suffix-wins routing, not the max-of behavior I described -- which is the opposite of what your Codex-CLI case needs. So your effort bug is genuinely still open, and there's now a second, separate one. I've reproduced both against the current code. Splitting them:

1. Effort still demoted to medium -- real, root cause pinned

When you send bare model = "gpt-5.5", OmniRoute rewrites it to gpt-5.5-medium before it ever reaches the executor (open-sse/services/model.ts:214-217, the codex "preferred unprefixed" alias). The Codex executor then reads the model-name suffix as the highest-priority effort (open-sse/executors/codex.ts:1322-1341: rawEffort = modelEffort || explicitReasoning || requestReasoningEffort || ...). So the injected -medium beats your model_reasoning_effort = "xhigh". That's the demotion -- and yes, "5.5 without effort" effectively means medium because of that alias.

The correct fix is a max-of at codex.ts:1340: when both a suffix effort and an explicit body reasoning.effort are present, take the higher one (an auto-injected alias suffix should never silently lower an effort the client explicitly asked for). Tracking that in #3265.

Workaround that works on your build today -- fully qualify with both prefix and suffix:

model = "codex/gpt-5.5-xhigh"
model_provider = "omniroute"

You already confirmed this carries xhigh on the wire. The "Custom medium" the Codex TUI shows (and its habit of rewriting config.toml per conversation) is Codex-CLI-side state, not OmniRoute -- but with codex/gpt-5.5-xhigh the effort OmniRoute forwards upstream is correct.

2. Wrong accounts being called -- separate bug, also reproduced

This one is real and independent of effort. I traced it: a combo target pins an account via a single connectionId per step (src/lib/combos/steps.ts:5-16). There is no "select N of M accounts" allowlist on a round-robin combo today. If your foo1/foo2 steps don't each carry an explicit connectionId, the real request path ends up at getProviderCredentials(provider, allowedConnections=null, forcedConnectionId=null, ...) (src/sse/services/auth.ts:923-929) and falls back to every active Codex account -- which is how foo3/foo4 get picked.

The "Test combo" button works precisely because it takes a different path: it injects X-OmniRoute-Connection: <connectionId> per target (src/app/api/combos/test/route.ts:72), force-pinning the account. The real chat path doesn't do that, so the mismatch you saw is exactly expected given the current model.

Workaround today: pin each account explicitly -- make foo1 and foo2 their own steps with the connection set on each, so the round-robin only cycles those two. If the UI isn't letting you set a per-step connection (so the round-robin can't be scoped to a subset), that's the gap, and I'm tracking a proper per-combo account allowlist in #3266.

On the upstream 9router#1459 link

The effort half rhymes with upstream, but the specific chain here (the gpt-5.5 -> gpt-5.5-medium alias + suffix-wins precedence) is OmniRoute's own code, so I'm fixing it here rather than waiting on the fork. The account-selection half is OmniRoute-specific (our combo-step model) and isn't from upstream at all.

I'll ping this thread when each fix lands. Sorry for the earlier mischaracterization of #2877 -- your logs were right the whole way.

[diegosouzapw]

Correction, @KernelBypass -- I need to walk back my previous comment. I traced this properly afterward and my effort diagnosis above was wrong. Apologies; here's what's actually true, verified against the current code (release/v3.8.12).

Effort: OmniRoute does not rewrite gpt-5.5 to -medium

I claimed OmniRoute rewrites bare gpt-5.5 -> gpt-5.5-medium. That's false. I checked it empirically:

getModelInfoCore("gpt-5.5") => { provider: "openai", model: "gpt-5.5" }

The gpt-5.5 -> gpt-5.5-medium alias I pointed at is dead code for this model -- gpt-5.5 is in the OpenAI registry, so the earlier providers.includes("openai") branch (open-sse/services/model.ts:447) returns the bare id and the alias branch never runs. Then resolveModelOrError reroutes openai->codex while keeping the bare gpt-5.5 (the #2877(A) fix, src/sse/handlers/chatHelpers.ts:128-141). So through OmniRoute, bare gpt-5.5 stays bare -> the executor's modelEffort is null -> your reasoning.effort is honored.

Where the -medium actually comes from: the Codex CLI itself. Your earlier log showed "model": "codex/gpt-5.5-medium" on the incoming request -- that's the CLI's TUI model-picker baking the effort into the per-conversation model name (the "Custom medium" you keep seeing). OmniRoute then honors that suffix because an explicit model-name suffix is treated as a deliberate choice (#2331) -- and that's intentional: a user who types gpt-5.5-low to save credits must not have it bumped back up. So "max-of" (what I floated, and what I filed #3265 for) is not the right fix -- it would regress that. I've closed #3265 as invalid.

Net: model = "gpt-5.5" with no effort -> falls back to the connection default (medium); model = "gpt-5.5" + reasoning.effort = "xhigh" sent by the client -> xhigh. The reliable path remains:

model = "codex/gpt-5.5-xhigh"

The TUI overwriting it per-conversation is Codex-CLI-side state, not something OmniRoute can override without breaking #2331.

Accounts: I overstated this too -- the real path does honor a pinned connection

I implied the real chat path drops the selected account while "Test combo" works. That's not right either. When a combo step has a pinned connection, the real round-robin path forwards it as forcedConnectionId (src/sse/handlers/chat.ts:574) and getProviderCredentials filters to exactly that connection (src/sse/services/auth.ts:930) -- identical to what the Test button does. There's no propagation asymmetry.

What genuinely doesn't exist is a first-class "round-robin over a subset of a provider's accounts." Today, to scope a round-robin to foo1+foo2 you have to add one step per account with its connection pinned. If your combo has steps with no connection pinned, the strategy is free to use the whole active Codex pool -- which is how foo3/foo4 get picked.

So I can't call this a confirmed bug yet. To pin it down, could you share:

1. Your combo's steps -- specifically whether each step has a connection pinned, or export the combo JSON.
2. A /dashboard/logs line for one mis-routed request showing which connection was selected.

If your steps are pinned to foo1/foo2 and foo3/foo4 still get called, that's a real bug and I'll fix it immediately. If they're not pinned, the fix is to pin them -- and if the editor isn't letting you scope a round-robin to a subset cleanly, I'm tracking that ergonomics gap in #3266.

Sorry again for the premature diagnosis -- you've been patient and your logs were right; I owed you an accurate trace, which this is.

[KernelBypass]

Hey @diegosouzapw , thanks for continuing to hunt these pesky bugs, I appreciate your effort!

you have to add one step per account with its connection pinned

I responded to you in:
#3266

...with screenshots -- it's not honoring my combo accounts even with them pinned. It's not even selecting my only active combo.
(I have 2 more combos in a disabled state.)

[KernelBypass]

model = "gpt-5.5" + reasoning.effort = "xhigh" sent by the client -> xhigh

But in my case it does NOT honor that as xhigh.

OmniRoute does NOT honor this:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"

The reliable path remains:
model = "codex/gpt-5.5-xhigh"

Yes, this works, but it causes this:

I understand what you are saying that it's a Codex client issue. Would it be possible to have some sort of compatibility shim for Codex to display them accurately like https://github.com/Soju06/codex-lb/ does?

The incorrect button is jarring and makes user second-guess if the model is actually correct.
And I am weary of switching to another client because I don't think Codex subscription terms allow 3rd party harnesses.

I'm using codex-lb for the time being, and it honors:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"

...and displays it correctly in the selector button, and routes to correct accounts, but it doesn't have a per-account HTTP proxy functionality (and also I might want to add other non-Codex providers later, which they don't support).

---

Again, thank you very much for your work!
Please LMK if I can help with any additional information.

[diegosouzapw]

Fair point, @KernelBypass - the mismatch is cosmetic (the upstream call really is xhigh when you use codex/gpt-5.5-xhigh), but I agree a wrong model button is jarring.

I have opened issue #3697 to track a Codex compatibility shim along the lines of what codex-lb does: echo the requested (effort-suffixed) model id back in the Responses payloads (response.created/response.completed), so the Codex UI renders the active effort accurately. One constraint we will keep: OmniRoute deliberately returns an empty models: [] to Codex on /v1/models - populating it makes Codex swap its built-in base instructions (~21k chars of agent prompt) for nothing, which silently degrades the agent. So the shim will operate purely on response payloads, which is all the UI needs.

I also noted in the issue to verify the model_reasoning_effort passthrough you described for bare gpt-5.5 - the suffixed ids remain the documented path either way.