GPT 5.6 Sol Pro support?

[rosstex]

Awesome repo! I saw #305 seems to add ChatGPT 5.6 Sol Pro support, is there a reason the docs/repo haven't been updated to show that 5.6 Sol Pro as the primary ChatGPT model?

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 21, 2026, 1:02 PM ET / 17:02 UTC.

Summary
GPT-5.6 Sol and Pro are already supported and documented; this issue remains necessary only for the maintainer-owned decision on Oracle’s shared implicit default.

Reproducibility: not applicable. this is a request to choose an implicit model policy, and the existing explicit API, browser-alias, and config paths are source-documented.

Root-cause cluster
Relationship: canonical
Canonical: #336
Summary: Merged API and browser work implements GPT-5.6 Pro support, but neither decides the remaining implicit-default policy.

Members:

• partial_overlap: feat(api): add GPT-5.6 Pro reasoning controls #335 - Merged API reasoning controls provide explicit GPT-5.6 Sol Pro support but do not change Oracle’s unconfigured default.
• partial_overlap: fix(browser): drive ChatGPT's Advanced → Effort submenu for reasoning effort #361 - Merged browser picker support makes the Pro effort selectable but deliberately leaves the default-model policy outside its scope.
• partial_overlap: fix(browser): preserve current Pro alias routing #377 - Merged current-Pro alias routing supports GPT-5.6 Sol plus Pro effort while preserving the explicit GPT-5.5 Pro default path.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Should an invocation with no model selection retain the shared gpt-5.5-pro default, or adopt an engine-specific GPT-5.6 Sol Pro default policy?	Retain the shared default: Keep gpt-5.5-pro as the unconfigured default and direct users who want current ChatGPT Pro behavior to generic Pro aliases or explicit GPT-5.6 Sol settings.

Why: Current support intentionally distinguishes explicit GPT-5.5 Pro, generic browser Pro aliases, and API reasoning mode; selecting a new implicit default requires choosing compatibility, cost, and API/browser semantics.

Next step
A maintainer must choose the cross-engine implicit-default policy before a safe implementation boundary exists.

Review details

Best possible solution:

Keep the explicit GPT-5.6 Sol/Pro paths and define an engine-specific unconfigured-default contract before changing Oracle’s shared default.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is a request to choose an implicit model policy, and the existing explicit API, browser-alias, and config paths are source-documented.

Is this the best way to solve the issue?

No: changing the primary default without a cross-engine policy would conflate browser Pro effort with API reasoning mode; a maintainer decision must define the desired compatibility contract first.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Changing the shared implicit default would alter unconfigured API and browser behavior; GPT-5.6 API Pro requires explicit reasoning controls, while browser Pro is a separate effort selection.

Codex review notes: model internal, reasoning high; reviewed against 083bba7e61f4.

Label changes

Label justifications:

• P3: This is a compatibility and product-default policy decision, not a demonstrated current workflow failure.
• impact:auth-provider: The request concerns default model and reasoning-mode routing across Oracle’s OpenAI and ChatGPT paths.

Evidence reviewed

What I checked:

• Current API support: Current documentation defines GPT-5.6 Pro as an explicit Responses API reasoning mode using gpt-5.6-sol, --reasoning-mode pro, and an optional effort. (docs/openai-endpoints.md:70, 083bba7e61f4)
• Current browser support: Browser documentation states that generic current-Pro aliases select GPT-5.6 Sol with Pro effort, while gpt-5.5-pro intentionally pins the historical GPT-5.5 target. (docs/browser-mode.md:108, 083bba7e61f4)
• Default remains intentional and distinct: The shared built-in default is still gpt-5.5-pro; browser tests verify it targets GPT-5.5 with Pro effort, whereas generic Pro aliases target GPT-5.6 Sol with Pro effort. (src/oracle/config.ts:10, 083bba7e61f4)
• Current-Pro routing provenance: Commit 39b0d41 explicitly preserved the historical gpt-5.5-pro target while routing generic current-Pro aliases to GPT-5.6 Sol with Pro effort. (src/cli/browserConfig.ts:25, 39b0d416a937)
• Release provenance: The generic current-Pro browser route shipped in v0.18.0; API reasoning-mode support shipped in v0.17.0. (CHANGELOG.md:3, 39b0d416a937)
• Maturity helper unavailable: The required shortlist could not run because this checkout has no qa/maturity-scores.yaml; this is a product-direction request, so no maturity label is selected.

Likely related people:

• steipete: Authored the current-Pro alias routing that preserves the explicit GPT-5.5 Pro target while moving generic Pro browser aliases to GPT-5.6 Sol. (role: recent default-routing contributor; confidence: high; commits: 39b0d416a937; files: src/cli/browserConfig.ts, docs/browser-mode.md)
• enki: Introduced the merged GPT-5.6 Pro reasoning controls that establish the API-side behavior relevant to any shared-default change. (role: API reasoning-mode introducer; confidence: medium; commits: 3942429f5d9b; files: docs/openai-endpoints.md, src/oracle/run.ts)
• mkubenka: Authored the merged browser picker work that made the GPT-5.6 Sol Pro effort selectable and verified. (role: browser effort-flow contributor; confidence: medium; commits: 573b6c7d87e8; files: src/browser/actions/thinkingTime.ts, tests/browser/thinkingTime.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.