Skip to content

Surface grok-web served model at runtime and flag new models - #6

Draft
ernop wants to merge 1 commit into
masterfrom
cursor/grok-web-served-model-surfacing-d7ce
Draft

Surface grok-web served model at runtime and flag new models#6
ernop wants to merge 1 commit into
masterfrom
cursor/grok-web-served-model-surfacing-d7ce

Conversation

@ernop

@ernop ernop commented Aug 8, 2026

Copy link
Copy Markdown
Owner

Why

xAI released Imagine Image 2.0 on 2026-08-07 as the new consumer Quality Mode on grok.com. The grok-web transport pins no model — it sends only enable_pro and the server picks — so the serving model can change under us with no code change. The imagine WebSocket already reports the serving model on every response (model_name + mode), but we only logged it quietly. This makes the runtime say, visibly, when a generation was served by a model other than the previously observed one.

What changed

  • GrokWebClient: new BaselineServedModelNames (imagine-x-1, the only name observed before the 2.0 release) with IsBaselineServedModel, plus a loud once-per-process-per-distinct-name log announcement (==== GROK-WEB MODEL CHANGE: ... ====) fired inside GenerateImageAsync when a generation is served by any other model.
  • TaskProcessResult: carries ServedModelName/ServedModelMode (null except where a transport reports one).
  • GrokWebImagineGenerator: populates those fields and appends ** NEW MODEL ** to its OK log line for non-baseline names.
  • UI (UiJobs + app.js + style.css): gen-result events gain servedModel/servedModelMode/servedModelIsNew; the result cell shows the reported model name beside the pixel size, rendered as an accent "— new model!" pill when outside the baseline, with the full explanation in the tooltip. Events persisted before this change simply lack the field and render unchanged.
  • AGENTS.md: documents the feature and the maintenance step (add a confirmed-stable new name to the baseline so the announcement retires).

Display/telemetry only — never a gate or a fallback; generation results are used exactly as returned. The app-chat edit/video path reports no model identity and is unchanged.

Services affected

grok-web only (text-to-image WebSocket path). No settings changes required.

Verification

  • dotnet build MultiImageClient.sln: 0 errors.
  • dotnet test: 57/57 pass.
  • Not live-verified against grok.com from this environment (no cookies here); the first grok-web run will log the served model_name and, if it isn't imagine-x-1, print the model-change banner and show the pill on the job card.
Open in Web Open in Cursor 

The imagine WebSocket pins no model (only enable_pro); grok.com picks the
model server-side, and xAI shipped Imagine Image 2.0 as the consumer
Quality Mode on 2026-08-07. Every response already reports model_name/mode;
now that identity is surfaced instead of just quietly logged:

- GrokWebClient: BaselineServedModelNames (imagine-x-1, the only name
  observed pre-release) + a loud once-per-process-per-name log announcement
  when a generation is served by any other model.
- TaskProcessResult carries ServedModelName/ServedModelMode; the imagine
  generator populates them and flags NEW MODEL in its OK log line.
- UI gen-result events add servedModel/servedModelMode/servedModelIsNew;
  the result cell shows the reported name beside the pixel size, as an
  accent 'new model!' pill when outside the baseline.

Display/telemetry only; never a gate or fallback. The app-chat edit/video
path reports no model identity and is unchanged.

Co-authored-by: Ernest French <ernestfrench@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants