reasoning_effort='ultra' causes opaque 400 on every turn (no validation, burns all retry attempts)

[andrei-hasna]

Summary

model_reasoning_effort = "ultra" in ~/.codewith/config.toml (with model gpt-5.6-sol via the hasna gateway) is rejected by the API with a 400 on every turn:

[ReasoningEffortParam] [reasoning.effort] [invalid_enum_value] Invalid value: 'ultra'. Supported values are: 'none','minimal','low','medium','high','xhigh','max'.

Impact

Discovered via @hasnaxyz/factory: a batch of ~10 headless codewith runs each 400'd on turn 1, retried 3x with the identical 400, and parked with zero output — indistinguishable at the surface from 'agent couldn't solve it'. There is no config-load validation and no fast-fail, so an invalid enum silently wastes the entire retry budget on every run.

Expected

Validate model_reasoning_effort against the supported set at config load (or request build) and either (a) map an unsupported value to the nearest valid one with a warning, or (b) fail fast with a clear actionable message naming the supported values — so a bad enum never turns into opaque mid-run 400s that consume retries.

Note

'ultra' is expected to become supported soon; regardless, unknown/unsupported effort values should be handled gracefully rather than producing silent 400 loops. Workaround today: use 'xhigh'.

[andrei-hasna]

Already fixed on main by #405 (ultra->max normalization, merged 2026-07-24) — 'ultra' is accepted and mapped to 'max', so no 400. The remaining problem is that INSTALLED builds predating #405 (e.g. 0.1.77, what the fleet runs today) still 400 on 'ultra'. Resolution: ship #405 in a published release and update installed binaries; meanwhile the workaround is --effort xhigh (or any supported value). Duplicate fix PR #429 closed as superseded.