Document and stabilize non-fast model selection for ACP/stdio sessions

Ideas Feature Requests
, , ,
1

Feature request for product/service

Cursor SDK

Describe the request

When driving Cursor through the Agent Client Protocol (cursor-agent acp), ACP clients need a documented and reliable way to select non-fast / standard model variants such as Composer 2.5 standard or Grok 4.5 standard/high non-fast.

Cursor models already expose the concept of speed / quality tiers in the product, and Composer/Grok routing by model family appears to work through the launch --model flag. However, the fast vs non-fast tier does not currently appear to be selectable or attestable in a durable way for ACP/stdio sessions.

Observed behavior on cursor-agent, for example 2026.06.04:

  • Launching ACP with --model composer-2.5[fast=false] still results in session storage showing providerOptions.cursor.modelName = composer-2.5-fast.
  • Launching ACP with --model grok-4.5[effort=high,fast=false] still results in session storage showing a fast runtime slug such as cursor-grok-4.5-high-fast.
  • Bare non-fast CLI slugs such as composer-2.5 or cursor-grok-4.5-high likewise resolve to *-fast at runtime.
  • In-session session/set_config_option / session/set_model can acknowledge the requested id or update metadata, including compound ids such as composer-2.5[fast=false] or grok-4.5[effort=high,fast=false], but they do not provide reliable attestation that the actual runtime model changed.
  • For Composer/Grok, ACP configOptions often advertise only fast/default compound ids, while launch accepts non-fast bracket or CLI forms but runtime still coerces to fast.

Ground truth from Cursor ACP session storage shows providerOptions.cursor.modelName as a *-fast slug even when launch --model requested fast=false or a bare non-fast CLI id.

So today:

  1. Family routing, such as Composer vs Grok, works via launch --model.
  2. Speed / quality tier routing, such as fast vs non-fast, does not appear to be durable for ACP/stdio sessions.
  3. ACP clients cannot honestly confirm a non-fast selection from protocol responses alone.

Feature request:

Please make non-fast model selection selectable and durable for ACP/stdio sessions.

Concretely:

  • Honor fast=false and equivalent non-fast bracket / CLI forms so the actual runtime providerOptions.cursor.modelName is a non-fast slug when that variant is available for the account.
  • Document the canonical non-fast ids or parameter format that ACP/stdio clients should use, including how launch --model, ACP advertised values, and runtime modelName relate to each other.
  • Expose a stable post-selection attestation, or keep launch --model, advertised config, and runtime modelName consistent enough that ACP clients can tell whether non-fast actually applied.

If Cursor’s intended path is a parameterized ACP model picker or an ACP client capability such as _meta.parameterizedModelPicker, please document it as a stable public contract, including:

  • The exact client capability flag and semantics.
  • The expected configOptions shape for parameterized models.
  • Whether launch-time --model <id> is supposed to be honored before and after session/new.
  • How clients should verify the effective runtime model after selection.

Use case:

Orchestration MCP servers, editor integrations, and automation tools such as Rutherford need reproducible Composer/Grok quality tiers, not only the fast path, when spawning cursor-agent acp --model <id>.

see also: GitHub - Artemonim/rutherford-mcp-server: Give your AI agent a crew. Model Context Protocol (MCP) tool to delegate, consensus build, debate, and review across Claude Code CLI, Codex CLI, Kiro CLI, and others. · GitHub

Version: 3.11.18 (system setup)
VS Code Extension API: 1.125.0
Commit: a1d1c20f31cb834d7d50581e6da017d2b822e380
Date: 2026-07-11T21:40:27.094Z
Layout: IDE
Build Type: Stable
Release Track: Nightly
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.22631

Operating System (if it applies)

Windows 10/11

5

Hey @Artemonim!

On this point:

Can you try launching the model with single quotes around the model name?

agent --model 'composer-2.5[fast=false]'

Doing so prevents the shell from treating [...] as a glob.

7

ACP client launches via argv (not an interactive shell), and the model string including [fast=false] already reaches cursor-agent intact. Separately, launching with the catalog non-fast CLI ids composer-2.5 and cursor-grok-4.5-high still records runtime providerOptions.cursor.modelName as composer-2.5-fast / cursor-grok-4.5-high-fast. So this does not appear to be shell globbing.

Report

What we already knew / rechecked

1) Rutherford does not rely on shell quoting

prepare_argv builds:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File …\cursor-agent.ps1 acp --model composer-2.5[fast=false]

The model arg is a separate argv token. Check: model_arg_literal=True.

So for Rutherford/ACP spawn, missing quotes is not the failure mode.

2) Brackets already reach cursor-agent

When launching with composer-2.5[fast=false], Cursor rejected it with:

Cannot use this model: composer-2.5[fast=false]. Available models: … composer-2.5, … composer-2.5-fast …

The full bracket id appears in the error, so it was not stripped by shell globbing. Quoting would not change that path.

3) Non-fast CLI slugs still coerce to fast at runtime

Fresh cursor-agent 2026.06.04-5fd875e ACP turns (argv launch, validation bypassed only to allow CLI hyphen ids):

Launch --model Session Runtime providerOptions.cursor.modelName
composer-2.5 416b66cd-… composer-2.5-fast
composer-2.5-fast 8ffeb091-… composer-2.5-fast
cursor-grok-4.5-high 8eb26640-… cursor-grok-4.5-high-fast
cursor-grok-4.5-high-fast 5e3117b4-… cursor-grok-4.5-high-fast

No brackets involved for the non-fast CLI slugs. Quoting cannot fix this.

15

Update: reproduced with Grok 4.6 — both effort and speed selection are affected

Retested on September 25, 2026:

  • Windows, Cursor Agent 2026.08.25-3e8eec8.
  • ACP/stdio through Rutherford, with launch-time model selection.
  • Fresh sessions, not resumed conversations.
  • Connectivity-only prompt requesting PONG, with no tool use or file changes.
Requested model Response Model slug recorded in Cursor’s session store
grok-4.6[effort=xhigh,fast=true] PONG cursor-grok-4.6-high-fast
grok-4.6[effort=xhigh,fast=false] PONG cursor-grok-4.6-high-fast

Both corresponding Cursor Agent logs contain:

Invalid parameter combination for grok-4.6; falling back to default variant.

Session IDs, if useful for investigation:

  • Fast: 40b0a09e-fa6f-4be1-a41d-81f969aba0b3
  • Non-fast: 60e6dc1d-2c93-4e68-ad64-f31ea6d1d1af

This extends the original observation: the recorded selection changes from xhigh to high in both cases, and from non-fast to fast in the second case. A successful response therefore does not establish that either requested parameter was honored.

Rutherford’s own model fallback was disabled (allow_model_fallback=false). That is an orchestrator setting, not a Cursor ACP capability; the logs show fallback occurring inside Cursor.

Earlier TLS interception problems were addressed before this retest. Both calls completed without TLS or ACP handshake errors, while the selection problem remained.

Could you clarify:

  1. Are these xhigh combinations supported through ACP, and what is the canonical launch syntax?
  2. If a combination is unsupported or unavailable for an account, can Cursor return a structured rejection instead of substituting a default?
  3. Can ACP expose the effective model, effort, and speed after resolution, including whether fallback occurred?

The model identities above come from Cursor’s local session storage, not from asking the model to identify itself.

reported by Astra