Skip to content

feat(orchestrator): Surface Grok reasoning effort options - #5160

Draft
mwolson wants to merge 1 commit into
pingdotgg:t3code/codex-turn-mappingfrom
mwolson:feat/grok-reasoning-effort
Draft

feat(orchestrator): Surface Grok reasoning effort options#5160
mwolson wants to merge 1 commit into
pingdotgg:t3code/codex-turn-mappingfrom
mwolson:feat/grok-reasoning-effort

Conversation

@mwolson

@mwolson mwolson commented Aug 1, 2026

Copy link
Copy Markdown
Contributor

What Changed

  • Add a Reasoning selector for Grok 4.5 with Low, Medium, and High choices on
    web and mobile.
  • Read Grok's reasoning-effort capabilities from ACP model metadata, with a
    narrow fallback for Grok 4.5 when that metadata is absent.
  • Start Grok ACP with the selected --reasoning-effort value and keep
    spawn-bound options out of the generic ACP config-option path.
  • Lock reasoning changes after a thread starts because loaded Grok sessions
    preserve their original effort. Web explains blocked changes with the
    existing new-chat toast, and mobile keeps the choices disabled.

Why

Problem and Why it Happened Fix
T3 Code always starts Grok at its default High effort even though Grok 4.5 supports Low, Medium, and High. Surface Grok's advertised effort menu through the existing provider-option UI.
Grok ACP does not expose reasoning effort as a session config option, so session/set_config_option cannot apply it. Pass the selected effort to grok agent --reasoning-effort <value> stdio when the provider process starts.
Loading an existing Grok session keeps the effort chosen at session creation, even if a respawn uses a different flag. Treat reasoning effort as session-bound and preserve the thread's committed selection after the thread starts.
Older or partial Grok metadata can omit the effort menu, while explicit negative capability data must remain authoritative. Use a Grok 4.5 fallback only when metadata is absent, and suppress it when Grok explicitly reports no support or an unusable menu.

UI Changes

  • Before: Grok has no Reasoning section in the traits menu.
  • After: new Grok threads can select Low, Medium, or High. Started threads keep
    their original value and direct attempted changes to a new chat.
  • Before/after media is pending while this PR remains draft.

Validation

  • vp check passes with no errors.
  • Full vp run typecheck reaches all 15 packages. The changed server, web, and
    mobile packages pass; the CTM base retains one unrelated
    HttpResponseCompression.ts BodyInit error in an untouched file.
  • Focused web tests: 46 passed.
  • Focused mobile tests: 10 passed.
  • Focused server tests pass except for the existing environment-dependent Grok
    missing-binary probe; the same probe fails on the clean base when the locally
    installed Grok binary remains discoverable.
  • Live AppImage validation confirmed Low starts
    grok agent --reasoning-effort low stdio, Grok session metadata records Low,
    a started thread reports the provider lock, and a new thread can select High
    successfully.

Checklist

  • This PR is small and focused
  • I explained what changed and why
  • I included before/after screenshots for any UI changes
  • I included a video for animation/interaction changes

Note

Surface Grok reasoning effort as a spawn-bound option in the orchestrator and UI

  • Adds GROK_REASONING_EFFORT_OPTION_ID and supporting utilities in GrokAcpSupport.ts to resolve and pass --reasoning-effort as a CLI flag when spawning the Grok agent process.
  • Extends the ACP adapter in AcpAdapterV2.ts to support spawnOptionIds on flavors, excluding those options from ACP config validation and setConfigOption calls, and logging a warning on mismatch.
  • Updates GrokProvider.ts to parse reasoning effort menus from ACP model _meta and advertise a Reasoning select capability on discovered Grok models, with a fallback for grok-4.5.
  • Blocks option changes mid-thread on both web (ChatComposer.tsx) and mobile (ThreadComposer.tsx) when the active provider requires a new thread for model changes, showing a warning toast and reverting to the committed selection.
  • Behavioral Change: reasoning effort for Grok is now applied at spawn time rather than via session config, so changing it mid-thread is blocked and requires starting a new thread.
📊 Macroscope summarized bbf8c77. 12 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

Grok 4.5 supports low / medium / high reasoning effort (default high), but T3 Code always started the agent at the provider default with no control.

Advertise a Reasoning select option from ACP model _meta (supportsReasoningEffort / reasoningEfforts), with a fallback menu for grok-4.5 when _meta carries no effort information (an explicit supportsReasoningEffort: false suppresses it), and apply the selected effort as 'grok agent --reasoning-effort <value> stdio' at spawn. Grok ACP has no session/set_config_option, so a new spawnOptionIds flavor hook excludes spawn-applied options from the generic ACP config-option path, and a changed spawn-bound value on an active session logs a warning instead of failing.

A live probe (grok 0.2.117) confirmed a loaded session keeps its original effort even when the process is respawned with a different flag, so effort is session-bound: the web traits picker and the mobile options menu lock option changes on started threads for providers that require a new thread for model changes, and a locked web thread displays and dispatches its committed selection rather than draft or sticky values.
@coderabbitai

coderabbitai Bot commented Aug 1, 2026

Copy link
Copy Markdown

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: cd9f0c8a-4007-4dcd-8b87-506385f233c2

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

  • 🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@github-actions github-actions Bot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:L 100-499 changed lines (additions + deletions). labels Aug 1, 2026
if (input.lockedProvider === null) {
return false;
}
const provider = input.providers.find((snapshot) => snapshot.instanceId === input.instanceId);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Medium components/ChatView.logic.ts:457

isStartedThreadOptionChangeBlocked compares only provider.driver with lockedProvider, so when handoff is enabled and the user switches a started thread to a different instance of the same driver (e.g. two Grok accounts), it still returns true. This wrongly disables option changes for the newly selected instance, even though that instance will start its own provider process and should accept its own spawn-bound reasoning effort. The check needs to distinguish the running provider instance from another instance sharing the same driver — e.g. by comparing instanceId against the locked instance rather than just driver against lockedProvider.

🤖 Copy this AI Prompt to have your agent fix this:
In file @apps/web/src/components/ChatView.logic.ts around line 457:

`isStartedThreadOptionChangeBlocked` compares only `provider.driver` with `lockedProvider`, so when handoff is enabled and the user switches a started thread to a different instance of the same driver (e.g. two Grok accounts), it still returns `true`. This wrongly disables option changes for the newly selected instance, even though that instance will start its own provider process and should accept its own spawn-bound reasoning effort. The check needs to distinguish the running provider instance from another instance sharing the same driver — e.g. by comparing `instanceId` against the locked instance rather than just `driver` against `lockedProvider`.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size:L 100-499 changed lines (additions + deletions). vouch:unvouched PR author is not yet trusted in the VOUCHED list.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant