fix(codex): clamp reasoning.effort max/ultra to xhigh (HTTP 400) - #68365
fix(codex): clamp reasoning.effort max/ultra to xhigh (HTTP 400)#68365joelbrilliant wants to merge 2 commits into
Conversation
|
Thanks for the focused transport-boundary fix. The premise remains valid on current main: The diff clamps both values to Automated hermes-sweeper review. |
229b1a0 to
251fb18
Compare
|
Thanks for checking this against current main. I’ve rebased the branch and retained both the transport-level clamp and the The focused transport and Responses integration suites are 99 passed, with ruff clean. Current head is |
|
The shared Vercel fixture fix has now landed on I rebased this PR onto the corrected |
Codex/OpenAI Responses rejects reasoning.effort=max with HTTP 400 invalid_value (allowed: none|minimal|low|medium|high|xhigh). Hermes config and generic effort ladder still use max/ultra; previously gpt-5.6 even mapped ultra to max on the wire. Clamp max and ultra to xhigh for the Codex Responses path (xAI still caps stronger levels at high). Covers fallback swaps onto openai-codex with a global agent.reasoning_effort of max. Evidence: desktop session 20260721_060132_be3b5e agent.log 11:31:52. Signed-off-by: joelbrilliant <joelbrilliant1@gmail.com>
CI failed on test_build_api_kwargs_codex_preserves_supported_efforts, which still treated max as a pass-through wire value. Align with the transport clamp (max/ultra -> xhigh) that fixes the live HTTP 400. Signed-off-by: joelbrilliant <joelbrilliant1@gmail.com>
251fb18 to
b4b50f2
Compare
…longer 400s on 'max' (#68365 confirmed live) Live probes against api.openai.com/v1/responses (Aug 2026): - gpt-5.6: accepts none/low/medium/high/xhigh/max; rejects minimal, ultra - gpt-5.5: accepts none/low/medium/high/xhigh; rejects max ('Unsupported value'), minimal, ultra So #68365's premise was half right: 'max' does 400 — but only on pre-5.6 models; blanket-clamping max->xhigh on gpt-5.6 (its fix) would have capped the one model that supports max. The declared-vocabulary design absorbs this as data: codex_supported_efforts(model) picks CODEX_GPT56_EFFORTS or CODEX_LEGACY_EFFORTS, and the shared clamp does the rest. Both the main Codex transport and the auxiliary client's Responses path use it. Wire outcomes: ultra -> max on gpt-5.6, ultra/max -> xhigh on gpt-5.5/o5, minimal -> low everywhere.
|
Thanks for this report — your July observation that the Responses API rejects |
…-runtime * upstream/main: (695 commits) fix(api-server): 'max' and 'ultra' reasoning efforts are no longer silently ignored on API/browser requests fix: K3 plan-variant slugs (k3-256k) now get K3's effort vocabulary fmt(js): `npm run fix` on merge (NousResearch#90552) feat(desktop): show unread count on the sessions sidebar toggle feat(desktop): count unread sessions from the shared status map fix(checkpoints): bare /rollback falls back to a labeled all-directories view (NousResearch#10505, reapply NousResearch#10633) fix(compression): /compress refusal no longer reports a successful rewrite fix(desktop): authenticate gated file downloads like REST fix(desktop): name the gated file-download auth decision fix: Codex Responses effort vocabulary is now per-model — gpt-5.5 no longer 400s on 'max' (NousResearch#68365 confirmed live) fix(desktop): give mermaid diagrams a pixel size in the overlay and on copy fix(desktop): mermaid zoom overlay body collapsed to zero height feat(relay): live-card ops — native draft streaming + task cards over the relay (gateway half) (NousResearch#85796) fmt(js): `npm run fix` on merge (NousResearch#90536) feat(desktop): unfocused session panes recede fix(desktop): scrollbars stop carrying the theme accent feat(desktop): one theme list in the palette, with a mode toggle inside it fix(a2a): expose schemas through tool describe fmt(js): `npm run fix` on merge (NousResearch#90523) refactor(desktop): replace every window.confirm with the shared dialog ... # Conflicts: # gateway/run.py
…longer 400s on 'max' (NousResearch#68365 confirmed live) Live probes against api.openai.com/v1/responses (Aug 2026): - gpt-5.6: accepts none/low/medium/high/xhigh/max; rejects minimal, ultra - gpt-5.5: accepts none/low/medium/high/xhigh; rejects max ('Unsupported value'), minimal, ultra So NousResearch#68365's premise was half right: 'max' does 400 — but only on pre-5.6 models; blanket-clamping max->xhigh on gpt-5.6 (its fix) would have capped the one model that supports max. The declared-vocabulary design absorbs this as data: codex_supported_efforts(model) picks CODEX_GPT56_EFFORTS or CODEX_LEGACY_EFFORTS, and the shared clamp does the rest. Both the main Codex transport and the auxiliary client's Responses path use it. Wire outcomes: ultra -> max on gpt-5.6, ultra/max -> xhigh on gpt-5.5/o5, minimal -> low everywhere.
Problem
Desktop dogfood (2026-07-21): fallback/switch onto
openai-codex/gpt-5.5withagent.reasoning_effort: maxhard-failed:Hermes accepts
max/ultrain config (generic ladder). Codex Responses wire vocabulary does not includemax(observed). Older code even mapped gpt-5.6ultra→ wiremax.Fix
In
agent/transports/codex.py, clampmax/ultra→xhighon the Codex Responses path. xAI Responses still caps stronger levels athigh.Tests
Evidence
agent.logsession20260721_060132_be3b5e~11:31 AEST.Risk
Low. Wire values only. Config can still say
max; transport sanitizes.