`VALID_REASONING_EFFORTS` rejects `max` and `ultra` locally, so the flagship model's top two reasoning tiers are unreachable from the plugin

Summary

normalizeReasoningEffort() rejects max and ultra before the CLI is ever invoked, so the top two reasoning tiers of the current flagship model are unreachable from the plugin.

scripts/codex-companion.mjs:71 (v1.0.6):

const VALID_REASONING_EFFORTS = new Set(["none", "minimal", "low", "medium", "high", "xhigh"]);

#485 notes the --effort hint omits these values and files it as cosmetic. The hint is the smaller half: this Set is a hard gate, and it fails the request locally with no API call, so raising it is a functional fix rather than a docs one.

Current levels

From codex debug models → supported_reasoning_levels, listed models only:

ultra is described in the catalog as "Maximum reasoning with automatic task delegation" — a distinct capability, and the flagship's headline mode, not just one more notch.

Repro

$ node scripts/codex-companion.mjs task --model gpt-6-astra --effort ultra "Reply with the single word: ok"
Unsupported reasoning effort "ultra". Use one of: none, minimal, low, medium, high, xhigh.
exit 1

Verified after widening the Set

Adding max and ultra to VALID_REASONING_EFFORTS (no other change), values read from the session rollout JSONL rather than exit codes:

The gate still discriminates after widening: --effort bogus is rejected locally, exit 1, no API call.

Two things worth a maintainer's eye

1. Per-model effort validity is not enforced on this path. Row 3 is ultra on gpt-5.6-luna, whose catalog entry stops at max. It was accepted and recorded rather than rejected. If per-model validity is meant to hold, nothing on this path enforces it. (The rollout shows the request carried ultra; it does not show whether the server clamped it.)

2. none and minimal are accepted by the plugin but appear in no listed model's supported_reasoning_levels. Same drift, opposite direction — possibly legacy values worth pruning in the same pass.

Suggested fix

Immediate: add max and ultra to VALID_REASONING_EFFORTS, and update the three places that spell the list out — the usage string (scripts/codex-companion.mjs:82), the error text (:124), commands/rescue.md:3, and skills/codex-cli-runtime/SKILL.md:35.

Better: derive the set from codex debug models, cached with a static fallback. This Set and MODEL_ALIASES (see #687) are both hardcoded copies of vocabularies the CLI already resolves at runtime, and both have now drifted behind it. A plugin release currently pins a model vocabulary that the API can invalidate at any time, and the user sees either a 400 or a local rejection naming values that are no longer the real set.

Environment

• Plugin codex v1.0.6 (db52e28f4d9ded852ab3942cea316258ae4ef346)
• codex-cli 0.153.4
• macOS 25.6.0 (arm64), Node v24.15.0, ChatGPT sign-in

Related: #485 (hint omission, filed as cosmetic), #687 (the MODEL_ALIASES half of the same drift), #476 / #651 (--effort task-vs-review asymmetry).