Grok model selected in cli. Usage shows gpt-5.6-sol-medium

Support Bug Reports
, ,
14

Same pattern here. Facts only from my machine (Cursor desktop, Windows), Aug 10–11 2026.

What I selected

  • Chat model picker: Grok / grok-4.5 for a multi-day Agent session on a uni-app chart/history bug.

What local storage shows (same machine)

  • Parent chat bubbles in %APPDATA%\Cursor\User\globalStorage\state.vscdb (cursorDiskKV / bubbleId:*) carry modelInfo.modelName = grok-4.5 and have requestIds (examples from that chat: 9ad5f627-7e2a-4f43-a4c4-59259042faeb, a3dbe72f-ebd3-4612-8e00-040a09d5af72, 0336ed43-c5dc-40ad-978d-b5c857ddee9b).
  • In the same DB, composerData:* entries also record composer-2.5 / composer-2.5-fast (and related slugs) far more often than grok-4.5.
  • agentKv:* samples include cursor-grok-4.5-medium-fast and at least one composer-1.
  • The agent transcript for that session contains multiple Task tool calls with an explicit "model": "fast" (not the parent Grok slug).

What happened in the work (Aug 10–11)

  • Same Agent chat was used for a CSS fake-landscape history-chart fix.
  • The agent repeatedly claimed a “unified chart interface,” but kept three near-duplicate skeletons (basic/cell/satellite) and only shared tiny helpers—not a real shared contract. I had to call that out; only then was a mixin/finalizeHistoryChartLayout path introduced.
  • Cell legend vs Y-axis overlap was “fixed” by a cell-only helper, then had to be pushed back into the shared layout path after I asked why a “unified” API still special-cased one chart.
  • Alarm-entry satellite auto-tooltip and cell legend alignment were asserted as aligned, then failed verification on device and needed rework.
  • Large rewrites / half-reverts burned a long stretch of the session (chart tip / setOption graphic / restore cycles) with little durable progress relative to token spend.

Why I’m posting

  • UI says Grok; local parent bubbles say grok-4.5; local composer/agent/Task traces still show other model slugs (composer-*, model: "fast") in the same workflow.
  • Staff replies in this thread already say Task subagents do not inherit the selected model and that the parent can pass another model into Task. That matches what I see locally.
  • From a user’s point of view that is still “label ≠ what ran for a large part of the work,” and the last two days’ output quality in that Grok-labeled session is inconsistent enough that I have a reasonable basis to doubt I’m getting the product that was labeled in the picker.

Please check the Request IDs above on the backend (Privacy Mode off on my side) and say which model(s) actually served those turns and any Task subagents attached to them.