[Bug]: Grok model slug grok-build advertised but rejected by Grok CLI ACP (session/set_model → Invalid params / unknown model id) #6075

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Install current Grok CLI (grok 1.0.x) and authenticate (grok login).
2. Install T3 Code (Desktop / AppImage). Enable the Grok provider; wait until status is ready.
3. Open a project and create a new thread with provider Grok.
4. In the model picker, select Grok Build (slug grok-build) — or start a turn while that model is selected.
5. Send any message (e.g. hi).

Expected behavior

• The model picker only lists model IDs that the live Grok ACP agent accepts (from session/new → models.availableModels), or
• Selecting the product-named option Grok Build is aliased to the real ACP model id (grok-4.5 today) so session/set_model succeeds.
• The turn starts normally.

Actual behavior

• T3 advertises both grok-4.5 (Grok 4.5) and grok-build (Grok Build) in the provider snapshot / model picker.
• Starting a turn with grok-build fails during startSession:
  1. session/new succeeds
  2. T3 calls session/set_model with modelId: "grok-build"
  3. Grok returns JSON-RPC -32602 Invalid params with data unknown model id
  4. UI shows a stack originating in Effect schema decode → startSession → ensureSessionForThread → processTurnStartRequested

Selecting Grok 4.5 (grok-4.5) works.

Impact

Major degradation or frequent failure

Anyone who picks Grok Build (or lands on the hard-coded default slug) cannot start Grok turns. The product name and model slug are easy to confuse.

Version or commit

• T3 Code: v0.0.33 (Linux AppImage; also confirmed against current main source)
• Grok CLI: 1.0.0 (grok agent stdio)

Environment

• OS: Linux (Ubuntu)
• Provider cache (~/.t3/caches/grok.json): status: "ready", models include both grok-4.5 and grok-build
• Default text generation selection can be grok-4.5, but choosing Grok Build still fails

Logs or stack traces

Error: Invalid params
    at decodeJsonError (.../effect/dist/SchemaTransformation.js)
    ...
    at startSession (.../apps/server/dist/bin.mjs)
    at ensureSessionForThread (...)
    at processTurnStartRequested (...)

Server trace span (excerpt):

{
  "name": "RpcClient.session/set_model",
  "exit": { "_tag": "Failure", "cause": "Error: Invalid params..." }
}

Provider event sequence for a failing thread:

1. session/new → succeeded
2. session/set_model → failed (errorTag: Die)

Direct ACP repro (outside T3):

# session/new → availableModels is only grok-4.5
# then:
session/set_model { "sessionId": "...", "modelId": "grok-build" }
# → {"error":{"code":-32602,"message":"Invalid params","data":"unknown model id"}}

session/set_model { "sessionId": "...", "modelId": "grok-4.5" }
# → success

Live Grok session/new models (Grok 1.0.0):

{
  "currentModelId": "grok-4.5",
  "availableModels": [
    { "modelId": "grok-4.5", "name": "Grok 4.5" }
  ]
}

(grok models also lists only grok-4.5 as the available model.)

Root cause (from T3 source)

This is not a per-machine Grok install issue. T3 hardcodes the product name as a model slug:

1. Built-in fallback catalog always includes grok-build / Grok Build:

// apps/server/src/provider/Layers/GrokProvider.ts
const GROK_BUILT_IN_MODELS = [
  { slug: "grok-build", name: "Grok Build", ... },
];

2. Default model for the Grok provider is still grok-build:

// packages/contracts/src/model.ts
DEFAULT_MODEL_BY_PROVIDER[GROK_DRIVER_KIND] = "grok-build"

3. Empty/missing model selection falls back to grok-build:

// apps/server/src/provider/acp/GrokAcpSupport.ts
resolveGrokAcpBaseModelId(...) // defaults to "grok-build"

Naming confusion:

• Grok Build = product / CLI (grok)
• Grok 4.5 = current ACP model id

Grok itself advertises “Select 'Grok 4.5' under /model.” There is no alias mapping grok-build → grok-4.5 on either side for session/set_model.

Workaround

In the T3 model picker, select Grok 4.5 (grok-4.5) and use a new thread after changing models (requiresNewThreadForModelChange: true for Grok).

Suggested fix

Any of:

1. Drop hard-coded GROK_BUILT_IN_MODELS / default slug grok-build; default to live discovery only (or to grok-4.5).
2. Alias grok-build → current ACP model id (grok-4.5) in resolveGrokAcpBaseModelId / MODEL_SLUG_ALIASES_BY_PROVIDER.
3. Prefer only session/new → models.availableModels for the picker when discovery succeeds; never leave a non-accepted built-in slug selectable.
4. If session/set_model fails with unknown model id, surface a clear message and fall back to currentModelId from session/new instead of failing the whole turn.

Related (not duplicates)

• [Bug]: Grok provider: skills/slash commands empty; ACP crash on skills-reload (BigInt RequestId) #4109 — Grok skills/slash empty; env notes cache lists both slugs, different failure mode
• Grok provider: native ACP parity (catalog, effort, usage) #5418 / feat(grok): native ACP parity (catalog, effort, usage, plan, multi-agent, compact) #5503 — Grok ACP parity (catalog/effort/usage)
• fix(grok): surface per-model reasoning effort in the composer #5403 — apply reasoning effort via session/set_model (assumes model id is valid)
• Provider notification consumers are interrupted when startSession returns (Cursor, Grok, Codex) #5781 — notification consumers after startSession (session starts; different symptom)

Screenshots, recordings, or supporting files

No response