browser: --browser-thinking-time extra-high selects Pro instead of Extra High (GPT-5.6 Sol)

[ozeron]

Summary

On ChatGPT browser mode with GPT-5.6 Sol, --browser-thinking-time extra-high ends up selecting the UI effort labeled Pro, not Extra High. CLI override cannot currently request Extra High without hitting Pro.

Observed with @steipete/oracle@0.17.0.

Expected

CLI flag	ChatGPT UI effort
high / extended	High
extra-high	Extra High (non-Pro)
heavy	Pro (explicit only)

Docs / skill guidance treat extra-high as the non-Pro max effort and heavy as Pro. Users should be able to override Extra High from the CLI.

Actual

1. normalizeThinkingTimeLevel("extra-high") returns "heavy".
2. For GPT-5.6, thinking-time selection prefers a menu item whose label contains pro when TARGET_LEVEL === "heavy".
3. Session meta stores thinkingTime: "heavy"; logs show Thinking time: Pro (already selected).

Contrast: --browser-thinking-time extended correctly logs Thinking time: High and stores thinkingTime: "extended".

Repro

npx -y @steipete/oracle@0.17.0 --engine browser --model gpt-5.6-sol \
  --browser-thinking-time extra-high \
  --copy-profile "$HOME/Library/Application Support/Google/Chrome" \
  --slug "repro-extra-high-vs-pro" --timeout 10m \
  -p "Reply with exactly: ok" \
  --file README.md

Then check:

# expecting Extra High; getting Pro / heavy
jq '.browser.config.thinkingTime' ~/.oracle/sessions/repro-extra-high-vs-pro/meta.json
# → "heavy"

Control (works as High):

npx -y @steipete/oracle@0.17.0 --engine browser --model gpt-5.6-sol \
  --browser-thinking-time extended \
  ...
# log: Thinking time: High
# meta: thinkingTime = "extended"

Code pointers (0.17.0)

Alias collapse — src/oracle/thinkingTime.js (dist: dist/src/oracle/thinkingTime.js):

case "heavy":
case "extra-high":
case "extrahigh":
case "xhigh":
  return "heavy";

GPT-5.6 Pro preference when heavy — src/browser/actions/thinkingTime.js injected selector:

• LEVEL_TOKENS.heavy includes 'extra high'
• For TARGET_IS_GPT56_MODEL && TARGET_LEVEL === 'heavy', option finder returns items with hasToken(itemText, 'pro')
• currentEffortPillMatchesTarget treats a Pro pill as a successful heavy match for GPT-5.6

Inconsistency: model selection already treats Extra High as non-Pro (isNonProIntelligenceThinkingLabel includes 'extra high' and scores it highest), but thinking-time selection conflates Extra High with Pro via heavy.

Suggested fix

1. Keep extra-high as its own normalized level (do not map to heavy).
2. Split tokens:
   • extra-high → match extra high / 极高 only (no pro)
   • heavy → match Pro / heavy only
3. Gate the GPT-5.6 “prefer Pro” branch so it runs only for TARGET_LEVEL === "heavy", never for extra-high.
4. Same for verification / “already selected” Pro shortcuts.
5. Update help text so aliases are unambiguous: extra-high = Extra High UI; heavy = Pro UI.

After that, CLI override remains --browser-thinking-time extra-high with no new flag required.

Environment

• @steipete/oracle: 0.17.0
• Engine: browser (Chrome copy-profile)
• Model: gpt-5.6-sol / GPT-5.6 Sol
• Host: macOS

Happy to test a PR build if useful.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 3, 2026, 6:13 PM ET / 22:13 UTC.

Summary
This issue remains necessary: current main still collapses extra-high into heavy, and the GPT-5.6 selector treats that level as Pro. The linked, open repair PR is a concrete candidate, so this issue should remain open until it lands or is superseded.

Reproducibility: yes. —current main source provides a high-confidence reproduction path: parsing extra-high produces heavy, and the GPT-5.6 browser picker then prefers Pro for that target. A real browser run is documented in the linked PR context but was not run during this read-only review.

Root-cause cluster
Relationship: canonical
Canonical: #353
Summary: This issue is the canonical report for the distinct Extra High-versus-Pro mapping defect; an open PR is its candidate fix.

Members:

• fixed_by_candidate: fix(browser): keep extra-high distinct from Pro thinking time #354 - The PR explicitly closes this issue and changes the reported normalization and GPT-5.6 effort-selection boundary, with claimed live browser proof.

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

Next step
An open linked PR already owns the bounded repair, so creating another fix PR would duplicate active contributor work.

Review details

Best possible solution:

Review and land the focused repair in #354 after confirming its browser proof and compatibility coverage, then retain heavy only for explicit Pro selection.

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

Yes—current main source provides a high-confidence reproduction path: parsing extra-high produces heavy, and the GPT-5.6 browser picker then prefers Pro for that target. A real browser run is documented in the linked PR context but was not run during this read-only review.

Is this the best way to solve the issue?

Yes—the linked PR’s approach preserves the existing override while splitting the previously conflated normalized intents, which is narrower than adding a new flag or changing default behavior.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Until the linked PR is reviewed and merged, an explicit extra-high request can still select Pro on GPT-5.6 Sol, changing cost and runtime behavior from the documented non-Pro intent.

Codex review notes: model internal, reasoning high; reviewed against 0f0bdb6a752e.

Label changes

Label justifications:

• P2: The browser override selects an unintended reasoning effort and affects users who explicitly request Extra High, but it is not a service outage or data-loss event.
• impact:other: The issue concerns unintended browser-run cost and reasoning-effort selection, which does not fit the more specific owned impact categories.

Evidence reviewed

What I checked:

• Current-main normalization defect: The current normalizer maps extra-high, extrahigh, and xhigh to heavy, so it cannot preserve the requested Extra High intent. (src/oracle/thinkingTime.ts:40, 0f0bdb6a752e)
• Current-main Pro routing: For GPT-5.6 Intelligence menus, the selector explicitly looks for a Pro item when the normalized target is heavy; the current verification path also accepts a Pro pill for that target. (src/browser/actions/thinkingTime.ts:459, 0f0bdb6a752e)
• Current regression expectation: The current CLI test still expects every Extra High alias to normalize to heavy, matching the reported behavior rather than the requested contract. (tests/cli/options.test.ts:197, 0f0bdb6a752e)
• Feature provenance: Blame attributes the current normalization and GPT-5.6 selector lines to the v0.17.0 release commit, identifying the current feature-history owner; the issue reports the same released version. (src/oracle/thinkingTime.ts:40, 0f46c76a0d1d)
• Open repair candidate: The provided GitHub context identifies an open, mergeable PR with closing syntax and reported live-browser proof for the exact normalization and selector change; it has not merged, so it does not yet resolve this issue. (ca5dd5cf385e)
• Maturity classification unavailable: The required maturity helper could not locate a qa/maturity-scores.yaml scorecard in this target checkout, so no maturity label is selected.

Likely related people:

• Peter Steinberger: Current blame attributes the normalization and GPT-5.6 picker behavior to the v0.17.0 release commit. (role: introduced current behavior; confidence: high; commits: 0f46c76a0d1d; files: src/oracle/thinkingTime.ts, src/browser/actions/thinkingTime.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.