[Bug]: Cursor options left at their default aren't sent, so delegated tasks and untouched threads run at 300K while T3 shows 1M #16149

Activity

1. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the checkpoint table and the careful write-up, @nkoynov! The code on current main matches the report. This is separate from #15788 and from the Max Mode hook in #15884.

   What I found

   • fix(server): honor Cursor long-context selections #15884 sets RequestedModel.maxMode only when the request already carries a context parameter above 300K. It doesn't add a missing context parameter, and an untouched Cursor composer never sends one.
   • buildCursorCapabilitiesFromSdkModel copies the SDK default variant onto the descriptors (CursorProvider.ts), and getProviderOptionCurrentValue displays that value. That's why Opus and Sol show 1M and Grok shows 500K.
   • Dispatch doesn't send that value. buildExplicitProviderOptionSelectionsFromDescriptors (packages/shared/src/model.ts) keeps only options that were actually stored. The one exception is an implicit fastMode: false (composerProviderState.tsx). Changing any trait persists every current descriptor value, which is why touching the picker once makes the long window stick.
   • delegate_task copies the parent selection when no options are given, but any requested options replace it (OrchestratorMcpService.ts). So an effort-only call drops contextWindow even when the parent had 1m. cursorSdkModelSelection forwards only what it receives. Thread launch and scheduled tasks use the same stored selection, so { instanceId, model } also omits context.

   Likely fix area

   • The goal would be to send the context tier the picker shows, including for delegate_task, launches, and scheduled tasks.
   • Filling every missing parameter from the default variant inside cursorSdkModelSelection has some catches. That function doesn't have the catalog. Fast is intentionally not the catalog default, so filling it could turn Fast back on. And an effort-only delegate_task from a parent that explicitly chose 300K would jump to 1M unless the options are merged with the parent selection.
   • Options include resolving defaults where the catalog is available, and merging delegate_task options with the parent selection rather than replacing it.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 5, 2026
3. adampeterhiggins

   added 4 commits that reference this issue on Oct 6, 2026

   fix(server): Cursor turns send the picker's default options

   ...

   7fa11ac

   fix(server): Cursor turns send the picker's default options

   ...

   d5c2ce7

   fix(server): Cursor turns send the picker's default options

   ...

   c441eac

   fix(server): Cursor turns send the picker's default options (#175)

   ...

   3703431
4. vatsa31 commented on Oct 9, 2026

   

   vatsa31

   on Oct 9, 2026

   Last edited by vatsa31

   More actions

   Note

   This report was sent by my coding agent running in T3 Code, on my behalf.

   Additional case: on the Cursor Start plan, the missing defaults fail every turn (not just the window size)

   We hit this on 0.0.46-nightly.20261009.2873 (macOS arm64), Cursor provider browser-signed-in, account on the Cursor Start plan. It is the same root cause as the OP — defaults aren't sent — but the impact is worse: every turn fails, and T3 surfaces only the generic Provider turn failed.

   Repro

   1. Cursor account on the Start plan, select any Cursor model (Grok 4.7 / 4.6 / 4.5, Composer 2.5) and send.
   2. The run fails. The underlying SDK result (read from T3's provider log and Cursor's own SDK run store error_code) is:
      Model unavailable on Start Start includes Composer 2.5, Grok 4.7, Grok 4.6, and Grok 4.5 with fixed settings. Switch to an included model to continue.
   3. The same happens via delegate_task with no options, and in plan mode.

   Verification against @cursor/sdk (bundled 1.0.31, same stored apiKey T3 uses; Agent.create + agent.send with an explicit ModelSelection):

   Model	params sent	Result
   grok-4.7	(none)	❌ "Model unavailable on Start …"
   grok-4.7	reasoning_effort=medium	❌ same
   grok-4.7	reasoning_effort=medium, fast=false	✅ finished, "OK"
   grok-4.6	effort=medium, fast=false	✅ finished
   grok-4.5	effort=medium, fast=false	✅ finished
   composer-2.5	fast=false	✅ finished

   On the Start plan these models are only runnable with their fixed settings, and cursorSdkModelSelection sends none of them unless the selection already carries the values.

   Notes that may help the fix direction

   • fast=false is required here, which lines up with the caveat above ("Fast isn't the catalog default"). On Start it is the only allowed value, so filling it from the model's fixed/default value is correct here rather than risky.
   • The values are already known at discovery time: the catalog T3 caches exposes them as single-value descriptors (for grok-4.7: reasoning_effort: medium, fastMode: false, contextWindow: 256k), which buildCursorCapabilitiesFromSdkModel / getProviderOptionCurrentValue derive from the SDK default variant. They just aren't dispatched.
   • Affected paths look like the same set the triage note lists: an untouched composer selection, delegate_task with no/partial options, thread launch, and scheduled tasks.

   If filling in the parameters a selection leaves out is an acceptable direction, I can help with a focused fix and open a PR linking this issue. Separately, #16146 (surfacing Cursor's actual reason instead of the generic "Provider turn failed") would make this class of failure much easier to diagnose.

   Environment: T3 Code 0.0.46-nightly.20261009.2873, macOS 26 arm64, @cursor/sdk 1.0.31, Cursor plan: Start. No UI involved, so no screenshots.
5. nkoynov commented on Oct 9, 2026

   

   nkoynov

   on Oct 9, 2026

   ContributorAuthor

   More actions

   Thanks, that is a worse version of the same bug. I am not working on a fix, so go ahead if you want to open one. The catches from the triage note still apply: Fast should only ever be filled in as false, and delegate_task options should merge with the parent selection instead of replacing it, so an effort-only call keeps the parent's context window.
6. vatsa31 commented on Oct 9, 2026

   

   vatsa31

   on Oct 9, 2026

   More actions

   Thanks @nkoynov.

   @juliusmarminge you mentioned a maintainer would decide the fix direction, so flagging before I open anything.

   What I had in mind for this (the Start-plan failure above is the same bug):

   • dispatch the option values the picker already shows when they're missing from the selection, with fast only ever filled as false
   • have delegate_task merge options with the parent selection instead of replacing it, so an effort-only call doesn't drop the parent's context window

   Good with both in one PR, or do you want the delegate_task change split out? And is packages/provider-cursor + OrchestratorMcpService the right place, or would you rather fix it in the shared selection builder?

   If you'd rather not gate it, happy to just open it under the obvious-bug exception. Your call.