v6.7.0

Added

GPT-5.6 support — gpt-5.6-sol, gpt-5.6-terra, gpt-5.6-luna (#189).

Bare gpt-5.6 aliases the Sol flagship tier. Reasoning-effort support follows the Codex model catalog (codex-rs/models-manager/models.json), not the launch coverage — which claims max/ultra are Sol-exclusive:

Model	Efforts
gpt-5.6-sol	low, medium, high, xhigh, max, ultra
gpt-5.6-terra	low, medium, high, xhigh, max, ultra
gpt-5.6-luna	low, medium, high, xhigh, max

No tier accepts none or minimal; both floor to low. Requesting max/ultra on a pre-5.6 model steps down to xhigh, then high.

ultra never goes on the wire. Codex treats it as a client-side tier and rewrites it to max before sending (client.rs, reasoning_effort_for_request); the subagent orchestration that distinguishes it lives in the Codex client, not the request body. It is accepted as an alias, sent as max, and excluded from ReasoningConfig["effort"] so the invariant is enforced at compile time. It does not spawn subagents here.

5.6 is opt-in: the legacy gpt-5 alias and the plugin default still resolve to gpt-5.5 / gpt-5.4. Since GPT-5.6 shipped as a limited preview, an account without access degrades sol → terra → luna → gpt-5.5 rather than failing every request.

Fixed

GPT-5.6 is served over the responses-lite request path (#189).

Its catalog entry sets use_responses_lite: true and tool_mode: "code_mode_only". Codex sends those models a different body: tools move into input as a leading additional_tools developer item, base instructions follow as a developer message, top-level instructions becomes "" and tools is omitted, parallel_tool_calls is forced off, image detail is stripped, and an x-openai-internal-codex-responses-lite: true header is sent. Sending the classic shape to a code_mode_only model hands it tools in a field it does not read.

The lite shape is applied at serialization, per attempt, against the model actually being sent — never to the canonical body — so a gpt-5.6-sol request that falls back to gpt-5.5 is re-serialized classic and keeps its tools instead of stranding them in an additional_tools item.

System instructions now come from the Codex model catalog (#190).

Modern Codex carries a full base_instructions string per model and sends that, not the legacy *_prompt.md files. The plugin was sending gpt_5_2_prompt.md — which opens "You are GPT-5.2 running in the Codex CLI" — to gpt-5.2, gpt-5.4, gpt-5.4-mini, and gpt-5.5, so those models got the wrong system prompt and a false identity.

⚠️ Behavior change. This alters the system prompt for existing gpt-5.2, gpt-5.4, gpt-5.4-mini, and gpt-5.5 users. The new text is what Codex itself sends. Models absent from the catalog (gpt-5-codex, gpt-5.1*, gpt-5.2-codex, gpt-5.4-nano, gpt-5.4-pro) keep their prompt file, and a catalog miss falls back to it.

Catalog instructions cache per model id, not per family: gpt-5.5 and gpt-5.4 share the gpt-5.4 family but carry different text. Keys are namespaced (catalog: / family:) because slug-space and family-space overlap — gpt-5.4-nano has no catalog entry but belongs to the gpt-5.4 family, itself a catalog slug. models.json is fetched once per release tag; fetchCatalogText memoizes and shares the in-flight promise, so the concurrent fan-out in prewarmCodexInstructions collapses to one download.

minimal effort no longer reaches the backend for GPT-5.6 (#189). It was clamped only in the Codex branch, which keys off the model name containing codex — 5.6 slugs do not. It now floors to low.

Effort-suffix parsing consolidated (#189). gpt-5.1-codex-max is a model id ending in -max, not a max-effort variant of gpt-5.1-codex. The new max suffix is guarded by a negative lookbehind scoped to that branch alone, so gpt-5-codex-low and gpt-5.1-codex-max-xhigh still parse.

Notes

GPT-5.6 support is verified against the upstream Codex source and the live model catalog, and by 2690 tests — but no request in this release has been exercised against the live Codex backend. GPT-5.6 is preview-gated; accounts without access exercise the fallback chain.

Full changelog: v6.6.0...v6.7.0