Sign up
View stargazersSign up

[Bug]: Cursor Plus subscription fails with 'Model unavailable on Plus' on all included models#24386

opened11d agobyAAchuAshwath

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

packages/provider-cursor

Steps to reproduce

  1. Authenticate with a Cursor account that has the Cursor Plus subscription (unified Cursor + Grok pool).
  2. Start a thread in T3 Code using the Cursor provider.
  3. Select any of the included models (Composer 2.5, Grok 4.7, or Grok 4.6).
  4. Send a message/prompt.

Expected behavior

The turn should run and succeed using the selected model included under the plan.

Actual behavior

The turn immediately fails with a terminal provider error:

1Model unavailable on Plus Plus includes Composer 2.5, Grok 4.7, Grok 4.6, and Grok 4.5 with fixed settings. Switch to an included model to continue.

This occurs for every model listed under Cursor in T3 Code, including Composer 2.5.

Impact

Blocks work completely

Version or commit

T3 Code (Beta) 0.1.2

Environment

  • OS: macOS (Darwin arm64)
  • Provider: Cursor (authenticated via browser login)
  • Subscription: Cursor Plus (unified Cursor + Grok pool)
  • Models tested: Composer 2.5, Grok 4.7, Grok 4.6

Logs or stack traces

1Model unavailable on Plus Plus includes Composer 2.5, Grok 4.7, Grok 4.6, and Grok 4.5 with fixed settings. Switch to an included model to continue.
AAchuAshwath10d ago
Synced from GitHub

Findings

Cursor Plus rejects these models when the request contains only the model id. The same models succeed when the catalog’s fixed settings are sent explicitly. Reproduced outside T3 with @cursor/sdk 1.0.35 (the version this app uses), in an empty workspace, using the stored browser-login credential:

ModelRequestResult
Composer 2.5model id onlyModel unavailable on Plus…
Composer 2.5fast: "false"finished
Grok 4.7model id onlysame Plus error
Grok 4.7context: "256k", reasoning_effort: "medium", fast: "false"finished

Composer 2.5 was repeated both ways; the results stayed the same. Plus’s catalog lists a single allowed value for each of these settings, and that value is the default.

T3 shows those defaults in the traits menu, then omits them from the request:

  • A parameter is turned into a boolean only when the catalog lists both true and false. Plus’s Fast value is only false, so it stays a select option (packages/provider-cursor/src/server/status.ts).
  • The composer injects an implicit Fast default only for a boolean fastMode descriptor (withImplicitFastModeDefault in apps/web/src/components/chat/composerProviderState.tsx).
  • Dispatch keeps only options the user has explicitly selected (buildExplicitProviderOptionSelectionsFromDescriptors in packages/shared/src/model.ts).
  • The Cursor adapter then sends the model id with no params (cursorSdkModelSelection in packages/provider-cursor/src/server/sdkModel.ts).

Workaround confirmed in the installed beta

On Grok 4.7 the traits menu shows one already-selected row per setting: Context 256K Default, Fast false Default, Effort Medium Default. Clicking Fast does not change the menu. The click still writes every current value as an explicit selection. This thread’s saved selection became:

  • contextWindow: 256k
  • fastMode: false
  • reasoning_effort: medium

The next Grok 4.7 turn succeeded. That write is also remembered for Grok 4.7, so later Grok 4.7 threads in this app should keep sending the settings. Composer 2.5 is stored separately and still needs the same click on its own Fast row.

A build that sends the catalog’s fixed settings without requiring that click would fix the models that only expose one allowed value.