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

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

• #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.

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):

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.

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.

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.

Additional reproduction: combined X Subscription Plus rejects Grok 4.5, 4.6, and 4.7

I'm seeing the same fixed-settings failure described in the Start-plan comment above, now on the combined X Subscription Plus plan.

Authentication succeeds and the Cursor provider catalog lists all three Grok models as available. Sending a message with any of them fails. This blocks Grok usage through T3's Cursor provider on this account.

Environment

• T3 Code Nightly desktop on macOS arm64.
• Server reported 0.0.46-nightly.20261013.3042 during investigation.
• Bundled @cursor/sdk version 1.0.35.
• Provider protocol: cursor-agent-sdk.local.
• Combined subscription tier reported by Cursor's error: Plus.

Reproduction

1. Sign in to a Cursor provider instance using the combined Plus account.
2. Create a thread, select Grok 4.7, leave the model options untouched, and send a message.
3. Repeat with Grok 4.6 and Grok 4.5.
4. Each run ends with the same SDK error.

Sanitized log evidence

Both agent.open and run.start send only the model ID, with no params:

The corresponding run.completed results report status: "error" and:

Observed failure times on October 13, 2026, in UTC:

• Grok 4.7: 13:04:32.184Z
• Grok 4.6: 13:09:05.047Z
• Grok 4.5: 13:10:07.759Z

The same account's catalog exposes only these allowed choices:

• Grok 4.7: contextWindow=256k, fastMode=false, reasoning_effort=medium.
• Grok 4.6 and 4.5: fastMode=false, effort=medium.

The persisted selections for these failed runs contain only the provider instance and model, without options. Inspection of the installed T3 bundle confirms that cursorSdkModelSelection serializes only explicit modelSelection.options; catalog defaults are used to label the picker, without being added to those requests. The SDK then constructs an empty parameter list when params is omitted.

This appears to be another affected subscription tier for the same omission. The earlier Start-plan report's successful explicit-parameter controls are particularly relevant. I have not run that control on this Plus account, so I am not claiming a verified workaround or fix here.

Only model settings, versions, and error excerpts are included above. Account identifiers, credentials, local paths, conversation IDs, and prompt content have been omitted.

Reran it on unmodified main 6318bfc597 in a Linux VM: T3 server from source, a Cursor API key, claude-opus-5-5, and the same prompts as the original. I also ran main plus only #21074's SDK bump to 1.0.38, because on plain main the window can't show the difference. maxTokens is the checkpoint's tokenDetails.maxTokens, and "sent" is the params Cursor received for that run.

On unmodified main everything gets the standard 300K window, explicit 1M included. That's #15788: SDK 1.0.35 never sets Max Mode, and #21074's bump fixes it. With only #21074 applied, explicit 1M gets 1M, but the untouched composer still sends only fast=false and gets 300K while the picker shows 1M. I checked that one in the real web UI too, and the thread's stored selection is [fastMode=false].

The delegate_task half changed with #16595: an effort-only child now inherits contextWindow from a 1M parent and gets 1M. It still drops to 300K when the parent never had a context option, like a thread started from an untouched composer. So what's left is that the defaults the picker shows aren't sent.