Reasoning Mode: Pro support for GPT-5.6 family models

[anyin233]

Description

ref: GPT-5.6 Reasoning Mode

Reasoning mode and reasoning effort are independent. Mode selects standard or pro execution, while reasoning.effort controls how much reasoning the model applies within that mode. If you omit reasoning.effort, GPT-5.6 defaults to medium in both modes.

This is a new parameter introduced by OpenAI in response API.

Use Case

Now openai introduces Pro-series model in their API, by enable this, we can use more powerful model in oh my pi.

Area

Provider / Model support

Proposed Solution

A new variant selector or toggle for GPT-5.6 family model, allow user switch between standard and pro.

Alternatives Considered

No response

[roboomp]

This looks feasible, but it should be treated as a new OpenAI Responses execution-mode selector rather than another reasoning effort tier. The current code already models effort separately (reasoningEffort / reasoning.effort, with GPT-5.6 shifted effort mapping in packages/catalog/src/model-thinking.ts and OpenAI/Codex serialization in packages/ai/src/providers/openai-codex/request-transformer.ts), so reasoning.mode: "standard" | "pro" should stay orthogonal to minimal/low/medium/high/xhigh.

Main scope if accepted:

• add catalog/provider metadata for models that actually accept OpenAI reasoning.mode;
• add a typed per-request option and wire it into OpenAI Responses/Codex request serialization;
• expose the selector through CLI/config/UI without changing existing effort semantics;
• add tests proving mode=pro and effort=<tier> can be combined and omitted independently.

Open maintainer decisions before implementation: should users select Pro as a request toggle, as separate catalog model variants, or both; what default should be used when the field is omitted; and whether this applies only to first-party OpenAI GPT-5.6 IDs or also OpenAI-compatible relays that advertise the same family.

[feelmypain]

I reproduced this on OMP 16.4.0. The Codex subscription endpoint rejects the generated reasoning.mode: "pro" field, while standard GPT-5.6 Sol with max/xhigh works.

I prepared a tested fix: feelmypain@bfd3e37

It keeps Pro mode for direct OpenAI Responses, removes unsupported synthetic Codex Pro aliases, migrates stale cached aliases, and preserves future provider-discovered Pro models.

My account is not currently vouched, so I cannot open a PR without it being automatically closed. Maintainers can review/cherry-pick this commit or advise on getting the contribution vouched.

[roboomp]

I re-ran a focused local serialization check rather than the live Codex subscription endpoint: a Codex gpt-5.6-sol-pro-shaped model carrying reasoningMode: "pro" plus reasoningEffort: "xhigh" produced reasoning: { effort: "max" } with no reasoning.mode field. Recorded as not reproduced on the current worktree.

I also reviewed feelmypain/oh-my-pi@bfd3e37; the direction matches the split discussed above: keep reasoning.mode=pro for direct OpenAI Responses, do not send it to the Codex subscription endpoint, and avoid stale synthetic Codex Pro aliases while preserving future provider-discovered models.

Since this issue is still triaged as an enhancement and no maintainer-authorized implementation/PR is open from this bot, I am leaving code untouched. Maintainers can review or cherry-pick the linked commit if they want to accept the implementation path.

[RealForce1024]

Adding a concrete Codex subscription-route use case from OMP 16.5.2.

Environment and requirement

• OMP: 16.5.2
• Current working route: openai-codex/gpt-5.6-sol through ChatGPT/Codex OAuth
• Required billing path: the existing Codex subscription; switching to direct OpenAI API billing is not acceptable for this use case

Observed behavior

1. openai-codex/gpt-5.6-sol is available and exposes low, medium, high, xhigh, and max effort.
2. openai-codex/gpt-5.6-sol-pro is absent.
3. The available Pro alias is openai/gpt-5.6-sol-pro.
4. Selecting that alias crosses the provider boundary from openai-codex to openai, stops using Codex OAuth/subscription credentials, resolves OPENAI_API_KEY, and routes to api.openai.com. In this case it surfaced a redacted 401 Incorrect API key from a stale environment key; even with a valid key, the request would be API-billed rather than consume the Codex subscription.
5. Current catalog code intentionally projects generated GPT-5.6 Pro aliases only to openai and removes stale synthetic openai-codex Pro aliases.

Requested behavior

• If the Codex subscription endpoint now or later exposes Pro mode or a provider-native equivalent (for example an Ultra/Pro SKU), expose it under openai-codex/* without requiring OPENAI_API_KEY or changing the billing route.
• If the subscription endpoint still rejects reasoning.mode: "pro", make the limitation explicit in the model picker: label openai/*-pro as direct API only, and warn or require confirmation before a selection changes provider, authentication, and billing from openai-codex to openai.
• Keep execution mode orthogonal to reasoning.effort; do not model Pro as another effort tier.

Acceptance criteria

A subscription user either:

1. remains on openai-codex when an upstream-supported Pro/native subscription route exists; or
2. receives a clear “not available through Codex subscription” explanation, without an implicit switch to API-key authentication and pay-per-token billing.

This is not a request to forward a direct OpenAI API key through the Codex endpoint; the requirement is to preserve the subscription route or clearly explain that it is unavailable.

[roboomp]

Confirmed the catalog facts. In packages/catalog/src/models.json the openai-codex provider carries gpt-5.6-sol (api openai-codex-responses) with no -pro sibling, and gpt-5.6-sol-pro exists only under API-billed routes (openai via openai-responses, plus relays like kilo/openrouter via openai-completions). So selecting the Pro alias does cross from the Codex OAuth/subscription route to an OPENAI_API_KEY + api.openai.com route, which is the silent billing/auth switch you described. This is consistent with the prior fix scoping reasoning.mode=pro to direct OpenAI Responses and dropping the synthetic openai-codex Pro aliases, because the Codex subscription endpoint rejects reasoning.mode: "pro".

Your three asks are reasonable and split into two independently shippable pieces:

1. Subscription-native Pro (blocked upstream): re-exposing openai-codex/*-pro requires the Codex subscription endpoint to accept reasoning.mode (or a provider-native Pro/Ultra SKU). Until that exists, adding the alias back just reintroduces the rejected-field failure. This one is gated on OpenAI, not on us.

2. Picker/selection UX (actionable now, orthogonal to effort): labeling openai/*-pro as direct-API-only and warning/confirming before a selection changes provider + auth + billing is a self-contained improvement that does not depend on (1). Keeping execution mode orthogonal to reasoning.effort is already how the code models it.

Open maintainer decisions before any implementation:

• Should the cross-provider-billing guard be generic (any selection that changes provider/auth/billing class) or special-cased to GPT-5.6 Pro?
• Is a warning sufficient, or is explicit confirmation required, and should there be a config/flag to suppress it for non-interactive use?
• What is the exact "not available through Codex subscription" surface — model-picker annotation only, or also a resolve-time error when a subscription-only session lands on an API-only alias?

This remains an unaccepted enhancement, so I am not implementing anything; a maintainer needs to accept it (and pick the UX scope for piece 2) before code lands.

[Ak-Surya]

Agreed with @roboomp's framing — keeping reasoning.mode orthogonal to reasoning.effort makes the semantics way clearer than adding another effort tier. Mixing "how the model executes" with "how much it reasons" would get confusing fast once more providers add mode-like flags.
On the scope list: the catalog metadata piece (which models actually accept reasoning.mode) feels like it should land first since everything else — request serialization, CLI/config exposure, tests — depends on knowing which models support it. Happy to help test the mode=pro + effort= combination once there's a branch up, especially edge cases where effort is omitted entirely.

[roboomp]

Agreed on the ordering: the catalog metadata (which model ids actually accept reasoning.mode) is the prerequisite the request serialization, CLI/config exposure, and tests all key off, so it should land first. Worth noting a live constraint from the thread — the Codex subscription endpoint currently rejects reasoning.mode: "pro", so the metadata almost certainly scopes to direct OpenAI Responses ids rather than openai-codex/* until upstream exposes a subscription-native Pro/SKU.

The mode=pro + omitted-effort edge case you flagged is a good acceptance target: per OpenAI's docs GPT-5.6 defaults effort to medium in both modes, so the serializer must send mode without an effort field and not synthesize a default tier.

This is still an unaccepted enhancement — a maintainer needs to accept it before a branch goes up. Once it's accepted and there's a branch, the mode+effort combination testing help is welcome.