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.