Skip to content

[Bug]: Cursor Other Models shows 100% available when account rejects models #29895

Closed as not planned

Description

@EtanHey

Before submitting

Area

apps/server — Cursor usage limits

Steps to reproduce

  1. Sign in to the Cursor provider in T3 with a merged Cursor/X account that does not include the Other Models pool.
  2. Open Usage → Limits and observe Other Models at 100% remaining.
  3. Through T3's Cursor provider, send a minimal reply OK prompt to one Claude, GPT, and Gemini model.

Expected behavior

When Cursor reports Other Models as unavailable to the signed-in account, T3 should not present the pool as 100% available. Show an unavailable/not-included state or another status that reflects the account's actual entitlement.

Actual behavior

T3 shows Other Models at 100% remaining, but the model requests are rejected:

  • Claude Opus 5: Claude Opus 5 is not included in your weekly usage Buy credits or switch to a Grok model to continue.
  • GPT-5.5: GPT-5.5 is not included in your weekly usage Buy credits or switch to a Grok model to continue.
  • Gemini 3.6 Flash: Gemini 3.6 Flash is not included in your weekly usage Buy credits or switch to a Grok model to continue.

The Cursor Grok 4.5 probe and Cursor Auto probe both returned: Weekly usage limit reached. It resets in 2 days. Buy credits to keep going now, or upgrade your plan for more weekly usage.

No credits were purchased. These were one-prompt T3 delegate probes.

Impact

The Limits page signals that Claude, GPT, and Gemini are available when the account rejects all three as not included, which can mislead users about usable model capacity.

Related issues

Activity

  1. juliusmarminge commented on Nov 3, 2026

    @juliusmarminge
    Member

    Tried this on main at 61c3794 with the Cursor provider enabled on a fresh dev server, signed in with a Cursor API key on a monthly (non-unified) plan.

    • Usage → Limits showed Other Models at 0% left, which matches what Cursor's DashboardService/GetCurrentPeriodUsage returned for that account (apiPercentUsed: 100). So the bug didn't reproduce on this plan.
    • T3 shows "Other Models 100% left" only when Cursor sends apiPercentUsed: 0 for the account. If Cursor omits the field, the row is hidden. So for your merged Cursor/X account, Cursor most likely reports apiPercentUsed: 0. We need to see what else that response contains before we can tell "not included" apart from "unused".

    Could you share these for the affected account? Remove anything identifying; the access token is never part of the response body.

    1. The JSON body of GetCurrentPeriodUsage, especially everything under planUsage (apiPercentUsed, autoPercentUsed, totalPercentUsed, and any apiLimit, autoLimit, apiSpend, autoSpend, limit, remaining), plus the top-level namedModelSelectedDisplayMessage and displayMessage.
    2. The JSON body of GetPlanInfo, especially includedUsagePeriod and isMerged.
    3. What T3 showed for Cursor Models and Overall at the same time, and how the Cursor provider is signed in (Cursor CLI login, browser sign-in, or CURSOR_API_KEY).

    With an access token in $TOKEN, both bodies come from:

    for m in GetCurrentPeriodUsage GetPlanInfo; do
      curl -s -X POST "https://api2.cursor.sh/aiserver.v1.DashboardService/$m" \
        -H "Authorization: Bearer $TOKEN" -H 'connect-protocol-version: 1' \
        -H 'content-type: application/json' -d '{}'; echo
    done
  2. EtanHey commented on Nov 3, 2026

    @EtanHey
    ContributorAuthor

    The affected account is a merged Cursor/X account.

    1. Cursor API responses (HTTP 200; snapshot taken 2026-11-03 21:25Z):

    GetCurrentPeriodUsage

    {
      "planUsage": {
        "remainingBonus": false,
        "bonusTooltip": "We work with model providers to give you free usage beyond what you've purchased. Amounts may vary.",
        "autoPercentUsed": 100,
        "totalPercentUsed": 100
      },
      "namedModelSelectedDisplayMessage": "You've used 100% of your included total usage",
      "displayMessage": "You've hit your usage limit"
    }

    GetPlanInfo

    {
      "isMerged": true
    }

    includedUsagePeriod was absent. No email, user/team/account IDs, or names were present in the included fields, so none needed redaction. I omitted other top-level fields outside the requested scope: billingCycleStart, billingCycleEnd, spendLimitUsage, displayThreshold, enabled, autoModelSelectedDisplayMessage, autoBucketModels, planInfo, and nextUpgrade.

    1. From that same provider usage response, T3's limits mapping is Cursor Models 0% left (autoPercentUsed: 100), Other Models absent (apiPercentUsed was not returned, so there is no Other Models row), and Overall 0% left (totalPercentUsed: 100). This snapshot does not show Other Models at 100%.

    2. T3 sign-in: an Oct 29 note records a stored Cursor API key; I couldn't verify through available T3 MCP whether that remains the active credential. The API request here used the local authenticated Cursor session, and cursor-agent status reported authenticated.

  3. juliusmarminge commented on Nov 12, 2026

    @juliusmarminge
    Member

    I tried to reproduce this on the current build and could not.

    Commit 62dc589 (origin/main). Called Cursor's API with the VM's CURSOR_API_KEY (exchange_user_api_key, then DashboardService GetCurrentPeriodUsage and GetPlanInfo). This account is also merged (isMerged: true). Its planUsage had only autoPercentUsed and totalPercentUsed (both about 2.64), with no apiPercentUsed: the same shape as the reporter's 2026-11-03 snapshot. Ran T3CODE_DEV_SEED=0 vp run dev on a fresh database, paired in the preview browser, and added Cursor via Settings → Providers → Add provider → Cursor → Next → Add instance. Usage → Limits then showed a single Cursor meter, '97% left ↻ 5d 15h', with no Other Models row and no Overall row. The reporter's own follow-up says their account returns no apiPercentUsed, so T3 shows no Other Models row ('This snapshot does not show Other Models at 100%'). T3 only shows 'Other Models 100% left' when Cursor sends apiPercentUsed: 0, and no merged-account response we or the reporter captured does that.

    Closing as not planned. If it still happens for you, reply with the exact steps and the version you are on and it will be looked at again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions