[Bug] Agent model composer-2.5[fast=false] set in Desktop but ACP session bills/runs as fast=true #4004

Activity

1. NocturnusCoder commented on Jul 31, 2026

   

   NocturnusCoder

   on Jul 31, 2026

   Last edited by NocturnusCoder

   Author

   More actions

   Added a public screenshot copy — the Buzz relay media URL requires community auth and is not viewable by maintainers.

   

   Gist: https://gist.github.com/NocturnusCoder/05290e272d734628939705d90887f83a

   Update: Gist PNG was re-uploaded as proper binary (first upload was corrupted via API). Issue body restored after accidental wipe during edit.
2. NocturnusCoder commented on Jul 31, 2026

   

   NocturnusCoder

   on Jul 31, 2026

   Author

   More actions

   Related: user reports Bumble (configured for Grok) also bills as Composer 2.5 Fast — likely systemic ACP model-switch failure, not Composer-specific.
3. NocturnusCoder commented on Jul 31, 2026

   

   NocturnusCoder

   on Jul 31, 2026

   Last edited by NocturnusCoder

   Author

   More actions

   Internet research — same issue across ACP clients (not Buzz-specific)

   Cross-client reports with identical symptom (picker/env says X, usage bills composer-2.5-fast):

   • PhpStorm/JetBrains: https://forum.cursor.com/t/model-selection-in-phpstorm-via-acp-is-not-working/162121 (Cursor staff: "known issue… defaults to composer-2.5-fast")
   • Zed Composer Fast lock: https://forum.cursor.com/t/composer-2-5-classic-via-custom-acp/161417
   • ACP variant/thinking unavailable: https://forum.cursor.com/t/cant-select-thinking-level-or-variant-in-cursor-acp/161317 (Cursor: without parameterizedModelPicker capability, only default variant per model; Composer default = Fast; no ETA for third-party clients)
   • session/set_model metadata-only: https://forum.cursor.com/t/bug-agent-acp-model-switching-updates-session-metadata-but-does-not-change-the-inference-backend/157312
   • Repro gist: https://gist.github.com/juliusmarminge/65f5a313afcedaffe015716c7b7db13b
   • Zed root-cause + fix (advertise clientCapabilities._meta.parameterizedModelPicker: true): Cursor ACP in Zed: Composer 2.5 Fast Mode Issue zed-industries/zed#57571
   • Non-fast launch still bills fast: https://forum.cursor.com/t/document-and-stabilize-non-fast-model-selection-for-acp-stdio-sessions/165622

   Suggested Buzz fixes: (1) buzz-acp declare parameterizedModelPicker in ACP initialize, (2) pass --model at cursor-agent spawn per agent, (3) fail loud on model mismatch instead of silent Fast fallback.
4. iroiro147 commented on Aug 1, 2026

   

   iroiro147

   on Aug 1, 2026

   Contributor

   More actions

   Confirmed: this is an upstream cursor-agent / ACP issue, not a Buzz bug.

   From the comments already on this issue:

   "PhpStorm/JetBrains: https://forum.cursor.com/t/model-selection-in-phpstorm-via-acp-is-not-working/162121 (Cursor staff: 'known issue… defaults to composer-2.5-fast')"

   Buzz correctly propagates BUZZ_ACP_MODEL=composer-2.5[fast=false] through crates/buzz-acp/src/commands/launch.rs; the harness env is correct (per issue repro). cursor-agent ACP then ignores the suffix and defaults to composer-2.5[fast=true] on its own bug tracker. Identical ACP-client reports exist for PhpStorm/JetBrains and Zed with the same fallback.

   The Buzz-side workaround would be to post-process the model list returned from cursor-agent's session/new into Desktop's model picker (so users can't pick a variant that isn't actually supported at startup), but that masks the upstream bug and the right fix belongs in cursor-agent. Suggest closing as upstream-blocked and tracking Cursor's own fix; the related systemic work for client-side catalog-vs-run mismatches is #3934.
5. mikececco commented on Aug 3, 2026

   

   mikececco

   on Aug 3, 2026

   More actions

   #4519 may be relevant here, though it addresses the visibility of this, not the mismatch itself.

   If composer-2.5[fast=false] isn't a byte-exact match for an entry in the harness catalog, resolve_model_switch_method (crates/buzz-acp/src/acp.rs:2110) returns None, and pool.rs:958 warns and starts the session on the agent's own default — which would present exactly as "Desktop says fast=false, session runs fast=true".

   Whether that's what's happening here is checkable: with #4519 the picker shows <model> not applied when the harness refused the request. If the warning appears, the divergence is Buzz-side model resolution rather than an upstream cursor-agent bug; if it doesn't, the request was accepted and the discussion in this thread about upstream behaviour stands.

   Worth noting #4054 deliberately pins exact-match semantics, so I've left the matching logic alone — #4519 only makes the outcome observable either way.
6. wpfleger96

   added a commit that references this issue on Aug 18, 2026

   feat(managed-agents): close five Claude Code agent-config gaps (#4557)

   ...

   50a7113
7. kaalph

   added 2 commits that reference this issue on Aug 21, 2026

   feat(managed-agents): isolate Claude Code agent config per-agent root

   ...

   dd701fb

   feat(managed-agents): isolate Claude Code agent config per-agent root

   ...

   4868e1b
8. BradGroux

   added a commit that references this issue on Aug 23, 2026

   feat(managed-agents): close five Claude Code agent-config gaps (block…

   ...

   962238d
9. mkumas commented on Aug 24, 2026

   

   mkumas

   on Aug 24, 2026

   More actions

   Adding a measurement that I think settles the open question in this thread, because it
   contradicts the "upstream cursor-agent bug, close as upstream-blocked" reading above.

   The non-fast variant is reachable from the same cursor-agent binary. The gate is a client
   capability, so the fix is client-side.

   Controlled pair

   Two ACP handshakes against the same binary, same account, minutes apart, initialize +
   session/new only — no prompt, no turn. The only difference is one boolean in the client's
   initialize:

   clientCapabilities._meta.parameterizedModelPicker	configOptions	model currentValue	fast option
   absent (what buzz-acp sends today)	2 — mode, model	composer-2.5[fast=true]	absent
   true	3 — mode, model, fast	composer-2.5	present, category: model_config, values ["false","true"]

   cursor-agent 2026.08.11-e8db854. In both runs the model list held 35 rows and exactly one
   Composer 2.5 row; declaring the capability changes which form that row takes.

   Why

   The mode is chosen purely from the client capability:

   clientSupportsParameterizedModelPicker(){
     return true === this.clientCapabilities?._meta?.parameterizedModelPicker }
   getModelPickerMode(){
     return this.clientSupportsParameterizedModelPicker() ? "parameterized" : "variants" }

   and the two modes read different fields of the same model object:

   • variants enumerates model.variants[], one option per materialised variant. Only the fast
     Composer 2.5 row is materialised, so a non-fast selection is unrepresentable and resolution
     falls through to options[0].
   • parameterized does not read variants[] at all. It reads model.parameterDefinitions[],
     where fast is an ordinary boolean whose values fall back to ["false","true"].

   buzz-acp does not declare the capability — the string does not appear in the shipped binary —
   so it gets variants mode by omission.

   Two consequences worth separating

   1. The persisted CLI selection is silently overwritten, not merely ignored. Once a session
      resolves to the fast row, the adapter writes that resolution back into cursor-agent's own
      persisted config on its next config flush. So a correctly-set non-fast selection is replaced
      on disk, and re-setting it is undone within about an hour. It presents as configuration drift
      with no author, which is a slow thing to diagnose.
   2. It reproduces with BUZZ_ACP_MODEL unset entirely. In that case no
      session/set_config_option is attempted at all and the session still runs fast — so the
      exact-match path in resolve_model_switch_method (fix(desktop): surface model requests the harness rejected #4519 / test(buzz-acp): pin exact-match boundary for unadvertised model variants (#4004) #4054) is not required to produce
      this symptom. Worth knowing, because a fix confined to model-string matching would leave this
      case untouched.

   Cost

   Per Cursor's published pricing, Composer 2.5 is $0.50/$2.50 per M input/output and the fast
   variant $3.00/$15.00 — 6× on both sides, for what Cursor describes as the same intelligence
   differing in latency. For a long-running headless agent nobody is waiting on, that is the whole
   delta. That is a list-price ratio rather than an observed invoice — I have not reconciled a
   bill against it.

   Possibly the same root cause as #6114

   parameterDefinitions is also where thinking/reasoning/effort parameters live, and the adapter
   has an explicit thought-level branch for them. So a client in variants mode would be unable to
   select those either, for the same structural reason. I measured only fast, so treat the
   generalisation as read-from-source rather than tested.

   Corroboration

   Same root cause reported against two other ACP clients: zed-industries/zed#57571 (whose reporter
   worked around it by patching initialize to advertise the capability) and tiann/hapi#967, #968.

   What I did locally

   As a stopgap I put a small wrapper in front of cursor-agent acp: it reads only the first line
   of stdin, sets _meta.parameterizedModelPicker, then execs the real binary and splices the
   rest through untouched. After that the non-fast selection both applies and stops being
   overwritten. I am not offering that as the fix — it is a local patch of someone else's
   protocol negotiation and I would rather delete it. I mention it only because it is a workaround
   people are independently reaching for, which seems like useful signal.

   Happy to run any other handshake variation that would help.
10. mfethe1

    added a commit that references this issue on Sep 2, 2026

    feat(managed-agents): close five Claude Code agent-config gaps (block…

    ...

    1fea545
11. abipalli

    added a commit that references this issue on Oct 7, 2026

    feat(managed-agents): close five Claude Code agent-config gaps (block…

    ...

    7093010