fix(server): Grok ACP threads run at the selected reasoning effort#15319

Problem

Selecting a reasoning effort for a Grok (ACP) thread or a delegated Grok task has no effect: the run's modelSelection carries {"id":"reasoningEffort","value":"low"}, but the Grok session keeps running at its default (xhigh). Grok's session/new advertises effort as a config option named reasoning_effort (category thought_level), while the composer stores it under the capability id reasoningEffort. The generic option loop in configureSession matches by exact id, so it logs "ACP session does not expose requested configuration option(s)" and sets nothing. The Grok flavor's applyModelSelection also called applyGrokAcpModelSelection without requestedReasoningEffort / currentReasoningEffort, so session/set_model went out with only sessionId and modelId, and on a same-model selection it was skipped entirely.

Reported in #15251 with a protocol trace; confirmed by triage on main (aad732901e).

Change

makeGrokAcpAdapterFlavor().applyModelSelection now passes the stored reasoningEffort into applyGrokAcpModelSelection, the same way GrokTextGeneration already does:

• On protocol 1, currentReasoningEffort comes from the session setup's model metadata and the requested effort rides on session/set_model as _meta.reasoningEffort. A same-model selection that only changes the effort now sends set_model instead of being skipped, and an effort the session already runs at sends nothing.
• On newer protocols (setModel carries no _meta), the wrapper writes the session's own thought_level select option through setConfigOption, reading the current value from the live config options, and only calls setModel when the model itself changes.

Same-runtime switches re-run applyModelSelection against the stored session setup, which the adapter only keeps current for the model id, so on protocol 1 a second effort change back to the setup-time value looked like a no-op (Macroscope's review finding). configureSession now hands the flavor the selection the session was last configured with (previousSelection, null on activation), and the Grok flavor baselines protocol 1 on that selection's effort. An effort-free selection leaves the live value unknown, so the next requested effort is sent rather than compared against setup metadata (CodeRabbit's review). Newer protocols keep reading the live thought_level option, re-read it after a model switch, and skip a value the switched-to model does not offer or the agent rejects with a warning, the way the generic option loop does, so the session open does not fail.

No change to applyGrokAcpModelSelection or to the generic ACP option loop. The id-mismatch warning still logs for reasoningEffort; it is cosmetic once the effort is applied and is left for a separate decision because it touches every ACP flavor.

Scope and approval

Bug fix for the triaged issue #15251, where the triage comment confirms the failure on current main, names both code paths, and lists this change ("pass the stored reasoningEffort into applyGrokAcpModelSelection, along with the current effort from session setup, the way text generation already does") as a fix option. One underlying problem; the server-only change touches the Grok flavor, one additive input on the ACP flavor's applyModelSelection contract with its wiring in AcpAdapterV2, and their tests.

Verification

Focused tests, run with vp test run in apps/server:

• GrokAdapterV2.test.ts, Grok model selection carries the reasoning effort, drives the flavor's applyModelSelection with a recording runtime:
  • protocol 1, session default xhigh, selection low → session/set_model for grok-4.6 with _meta.reasoningEffort = "low";
  • protocol 1, session already at low → no request;
  • protocol 1, low applied and then xhigh selected again against the same stored setup → a second set_model with _meta.reasoningEffort = "xhigh"; without the previousSelection baseline this fails with expected [ { …(2) } ] to deeply equal [ { …(2) }, { …(2) } ];
  • protocol 1, low applied, then an effort-free selection, then xhigh → the xhigh set_model is sent because the live value is unknown;
  • protocol 2, config options model + reasoning_effort (thought_level) → setConfigOption("reasoning_effort", "low") and no setModel for the unchanged model;
  • protocol 2, switch to a model whose live option offers only low/high while xhigh is requested → setModel only, no setConfigOption;
  • protocol 2, setConfigOption fails with AcpRequestError → the selection still applies and nothing escapes.
• AcpAdapterV2.test.ts, hands the flavor the selection a live session was last configured with: a fake flavor records previousSelection across openSession and two model switches against the mock agent and sees [null, initial, alternate].
• With the first adapter change stashed, the protocol-1 low and protocol-2 cases fail (expected [] to deeply equal [ { … } ]).
• Results: GrokAdapterV2.test.ts + GrokAcpSupport.test.ts 44 passed; AcpAdapterV2.test.ts 115 passed.
• pnpm run typecheck in apps/server: 0 errors. Correction to the first version of this section: commit 93672759 did not pass it (string | boolean | undefined reached currentReasoningEffort on the newer-protocol branch, 4 errors); 0b66d256 narrows the value.
• vp fmt --check at the repo root: clean. vp lint --report-unused-disable-directives: exit 0; the warnings it prints in the touched files are on lines this PR does not change.
• Not checked: a live Grok CLI session. The session/new transcript checked into the repo advertises the same reasoning_effort option the fix targets, and the protocol-1 path reuses the helper the text-generation path already exercises against the CLI.

Claude Fable 5.1 (claude-fable-5-1) in Claude Code did the implementation; the account holder reviewed and owns the commit.