[Bug]: _CODEX_AUX_MODEL = "gpt-5.2-codex" is the only 5.x model rejected by ChatGPT-account Codex backend, breaking all auxiliary fallback

[pokibao]

Summary

agent/auxiliary_client.py:269 hardcodes _CODEX_AUX_MODEL = "gpt-5.2-codex" as the Codex fallback for ChatGPT-account users. As of 2026-04-29 this is the only model in the gpt-5.x family that the ChatGPT-account Codex backend rejects, meaning every auxiliary fallback (compression, vision, title generation, etc.) on a ChatGPT-account install silently fails with HTTP 400 "model is not supported".

Reproduction

• hermes-agent commit: a1921c43 (current main)
• Account type: ChatGPT subscription Codex auth (`~/.hermes/auth.json`)
• Verified on two independent installs (MBA + Mac mini), same ChatGPT account

I tested every gpt-5.x model directly against `https://chatgpt.com/backend-api/codex/responses\` with the same OAuth token + `originator: codex_cli_rs` headers Hermes uses:

Model	Result
`gpt-5.5`	400 "Instructions are required" → accepted, just missing my body field
`gpt-5.4`	400 "Instructions are required" → accepted
`gpt-5.4-mini`	400 "Instructions are required" → accepted
`gpt-5.3-codex`	400 "Instructions are required" → accepted
`gpt-5.2-codex`	400 "The 'gpt-5.2-codex' model is not supported when using Codex with a ChatGPT account."
`gpt-5`	400 "model is not supported" (rejected, but unused as fallback anyway)

So `_CODEX_AUX_MODEL = "gpt-5.2-codex"` is the worst possible choice — it is the only rejected option among supported alternatives.

Observed user impact

When a ChatGPT-account user's main model (e.g. `gpt-5.5`) hits a transient network error, the auxiliary fallback in `_try_payment_fallback` reaches the Codex branch, instantiates `CodexAuxiliaryClient(real_client, _CODEX_AUX_MODEL)`, and the call fails with the rejection above. Real-world log:

```
2026-04-29 21:18:22 INFO Auxiliary compression: connection error on auto — falling back to openai-codex (gpt-5.2-codex)
2026-04-29 21:18:23 WARNING root: Failed to generate context summary: Error code: 400 - {'detail': "The 'gpt-5.2-codex' model is not supported when using Codex with a ChatGPT account."}. Further summary attempts paused for 60 seconds.
```

The 60s pause repeats each compression cycle, degrading long sessions on Telegram / web UI.

Inline comment in source is also out of date

`auxiliary_client.py:264-268` says:

ChatGPT-backed Codex accounts currently reject gpt-5.3-codex for these auxiliary flows, while gpt-5.2-codex remains broadly available

Per the test table above the situation has reversed: 5.3-codex is accepted today, 5.2-codex is rejected.

Proposed fix

Short-term: change the hardcoded constant to a model that is currently accepted, e.g.

```python
_CODEX_AUX_MODEL = "gpt-5.4" # or "gpt-5.3-codex"
```

Long-term: probe-and-cache the accepted model list once per install via the Codex auth, similar in spirit to #16173 for main models. A static constant for an externally-controlled model list will keep going stale.

Workaround

Local patch `_CODEX_AUX_MODEL = "gpt-5.4"`. Verified working in compression and auxiliary flows.

Why some installs don't hit this

Mac mini install with default `_CODEX_AUX_MODEL = "gpt-5.2-codex"` shows zero "model not supported" errors despite the same Codex backend rejection. Reason: that install runs short cron tasks only — it never triggers compression and never reaches `_try_payment_fallback`. The bug is real on every ChatGPT-account install but only surfaces under long-session usage that triggers auxiliary fallback. Worth flagging in case other users see "works for me" without realizing they just don't trigger the path.

Environment

• macOS 25.4.0 (Darwin)
• Python 3.11.15
• hermes-agent commit `a1921c43`
• Codex auth: ChatGPT subscription

[pokibao]

Update: stronger fix recommendation — use main model

After more user feedback, recommending the auxiliary fallback follow the main model (e.g. gpt-5.5) rather than a "fast model" like 5.4 / 5.3-codex. Reasons:

1. Consistency — users configuring model.default: gpt-5.5 expect side tasks (compression, vision) to use the same quality model. Silent downgrade to a different model violates least-surprise.
2. Maintenance — pinning a separate constant for "auxiliary" creates the exact drift problem this issue documents. Tying it to the user-configured main model means upstream model availability changes only break one path.
3. Test results unchanged — gpt-5.5 is accepted by the ChatGPT-account Codex Responses API just like 5.4 / 5.3-codex. Verified.

So the cleanest fix is:

# instead of a hardcoded constant:
_CODEX_AUX_MODEL = _read_main_model() or "gpt-5.4"  # fall back to a known-good if main is unset

Or threaded through more cleanly: pass the main model into the Codex auxiliary client constructor so it's not a module-level constant at all.

Verified locally: _CODEX_AUX_MODEL = "gpt-5.5" patch works in production for compression and auxiliary flows.

[pokibao]

Second hardcoded model location found

While auditing for stale model constants, found a second hardcoded ChatGPT-Codex model:

`plugins/image_gen/openai-codex/init.py:75`:

_CODEX_CHAT_MODEL = "gpt-5.4"

This is the host chat model that wraps the `image_generation` tool call when image_gen plugin is active. Different from `_CODEX_AUX_MODEL`, but same anti-pattern: hardcoded to a non-main-model value, will go stale the moment ChatGPT backend rotates accepted models.

Same fix recommended: thread the user's main model through (or at least keep both constants in lockstep with each other and with the user's configured main model).

A grep for all such constants in the repo:

$ grep -rEn '_(AUX|CHAT|HOST|FALLBACK|DEFAULT)_MODEL\s*=\s*"gpt-' --include="*.py"
agent/auxiliary_client.py:269: _CODEX_AUX_MODEL = "gpt-5.2-codex"
plugins/image_gen/openai-codex/__init__.py:75: _CODEX_CHAT_MODEL = "gpt-5.4"
optional-skills/productivity/telephony/scripts/telephony.py:53: VAPI_DEFAULT_MODEL = "gpt-4o"  # not a ChatGPT-Codex path, OK

Local patch applied to both #1 and #2 constants → `gpt-5.5`. `post-merge` git hook in place to auto-reapply on `git pull`.

[pokibao]

Better workaround (no source patch needed)

Just discovered `auxiliary..{provider,model}` in `config.yaml` can override the hardcoded `_CODEX_AUX_MODEL` per-task without touching source. From the docstring at the top of `auxiliary_client.py`:

Per-task overrides are configured in config.yaml under the ``auxiliary:`` section (e.g. ``auxiliary.vision.provider``, ``auxiliary.compression.model``).

The key trick: setting `provider` to a non-`auto` value (e.g. `openai-codex`) makes `is_auto = False` in `_try_payment_fallback` (line ~3430), so the broken Codex fallback chain that uses `_CODEX_AUX_MODEL` is never reached.

Concrete config.yaml patch I'm running:

```yaml
auxiliary:
vision: {provider: openai-codex, model: gpt-5.5, ...}
web_extract: {provider: openai-codex, model: gpt-5.5, ...}
compression: {provider: openai-codex, model: gpt-5.5, ...}
session_search: {provider: openai-codex, model: gpt-5.5, ...}
skills_hub: {provider: openai-codex, model: gpt-5.5, ...}
approval: {provider: openai-codex, model: gpt-5.5, ...}
mcp: {provider: openai-codex, model: gpt-5.5, ...}
title_generation: {provider: openai-codex, model: gpt-5.5, ...}
flush_memories: {provider: openai-codex, model: gpt-5.5, ...}
```

This survives `hermes update` / git pull / pip reinstall — config.yaml is user-owned and isn't touched by upgrades. Source patch (and the post-merge hook protecting it) becomes a redundant safety net rather than load-bearing.

For `_CODEX_CHAT_MODEL` in `plugins/image_gen/openai-codex/init.py:75` there is no equivalent config.yaml override — `image_gen.openai-codex.model` only accepts image-generation models (`gpt-image-2-*`), not chat host models. That one still needs source patch + post-merge hook to be durable.

Suggestion to upstream: maybe expose the chat-host model via `image_gen.openai-codex.host_model` or similar?

[teknium1]

Fixed in PR #17765 (merge ce0c3ae).

Your test matrix (which models the ChatGPT-account Codex backend accepts vs rejects) was load-bearing for this fix — thanks for the careful work @pokibao. Rather than bump the constant to gpt-5.4, we removed _CODEX_AUX_MODEL and dropped Codex from the auxiliary fallback chain entirely. Reasoning:

1. That constant has already rotated twice in ~6 weeks (gpt-5.3-codex -> gpt-5.2-codex -> broken again). OpenAI publishes no changelog for the allow-list, so any pinned default rots.
2. When your main provider has a transient connection error, falling back to Codex with a guessed model ID is a second API call that's statistically likely to fail too. If main fails, aux tasks should just fail cleanly.
3. Codex is still used normally when it IS your main provider (Step 1 of _resolve_auto uses your configured Codex model, whatever you picked). Your auxiliary.<task>.provider: openai-codex + auxiliary.<task>.model: gpt-5.5 config.yaml override also still works — that's now the supported pattern for explicit Codex aux routing.

The 60s pause you were seeing goes away because the rejection loop is gone; the aux call fails once and moves on.

Re-open if you see regressions.

#17765