Bug Report: Dashboard UI percentages frozen due to totalPercentUsed calculation bug in get-current-period-usage API

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

There is a backend data-binding and math calculation conflict within the get-current-period-usage API response.

The frontend dashboard progress bars read from the totalPercentUsed variable, which is broken and frozen at a very low number (~3.7%).
However, actual usage (totalSpend) is at 1,288 out of a 2,000 limit (~64.4%).

The backend successfully generates the correct text string (displayMessage: “You’ve used 64% of your included usage”), but the numerical percentage variables remain broken, causing the visual progress bars in both the web dashboard and the IDE to freeze and fail to track token depletion.

Steps to Reproduce

  1. Open the Cursor Web Dashboard or check usage inside the IDE settings.
  2. Observe that the split usage percentages are frozen and do not increase despite heavy AI usage.
  3. Open browser DevTools (F12) on the dashboard page and navigate to the Network tab.
  4. Filter by usage and look at the response payload for get-current-period-usage.
  5. Compare the value of “totalPercentUsed” (broken) against the calculated percentage of “totalSpend” divided by “limit” (correct).

Example get-current-period-usage response:

“planUsage”: {
“totalSpend”: 1288,
“includedSpend”: 1288,
“remaining”: 712,
“limit”: 2000,
“remainingBonus”: false,
“bonusTooltip”: “We work with model providers to give you free usage beyond what you’ve purchased. Amounts may vary.”,
“autoPercentUsed”: 3.8966666666666665,
“apiPercentUsed”: 2.6444444444444444,
“totalPercentUsed”: 3.733333333333334
},
“spendLimitUsage”: {
“limitType”: “user”
},
“displayThreshold”: 200,
“enabled”: true,
“displayMessage”: “You’ve used 64% of your included usage”,
“autoModelSelectedDisplayMessage”: “You’ve used 4% of your included total usage”,
“namedModelSelectedDisplayMessage”: “You’ve used 3% of your included API usage”

Expected Behavior

The numerical percentage variables (totalPercentUsed, autoPercentUsed, apiPercentUsed) should accurately calculate the mathematical quotient of spend vs. limits (e.g., 1288 / 2000 = 64.4%). The frontend progress bars in both the IDE and the web UI should update in real-time to match this true consumption data.

Operating System

MacOS

Version Information

Version: 3.15.19 (Universal)
VS Code Extension API: 1.128.0
Commit: de07bee81cefe43461ebf4f40c3d2d78d15052a0
Date: 2026-08-11T05:22:54.627Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.291
OS: Darwin arm64 25.5.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Pro plan. For 2–3 days, Spending + IDE Plan & Usage are frozen at:

  • Cursor Models 21%
  • Other Models 85%

Meanwhile Usage dashboard continues to log many “auto” / Included requests
(Aug 12–13, hundreds of thousands of tokens each). Total tokens ~436M this period.

Tried different browser; IDE and web show the same frozen %.
Need confirmation: is this display-only? What is my real remaining for both pools?
Reset is Aug 27 — I cannot plan remaining 15 days with a stuck percentage.

5

same here, everything stuck, I’m on Ultra, and the usage stopped counting, Auto at 34% and API at 100%. But somehow I can still use the API models like Opus 5 without spending my on-demand (which is currently set at $2) budget? I don’t know how much I spent and how many remain to use.

7

Hey, thanks for the detailed breakdown. There are actually two separate things here, so I’ll go through them one by one.

First, about the percent fields. totalPercentUsed, autoPercentUsed, and apiPercentUsed in the get-current-period-usage response are not calculated as a simple totalSpend / limit. They reflect a different internal metric, so they won’t match that division. This is expected behavior, not a calculation bug. The text displayMessage (like “64% of your included usage”) uses includedSpend/limit, which is why it can differ from the percent fields.

Second, about the frozen numbers. The fact that the values haven’t changed for a few days despite active usage is a real issue we’re tracking. It affects what you see in the dashboard and in the IDE. The important part is that usage is still being tracked correctly on the backend. Only the display is delayed, and billing is not affected. Once this is fixed, the counter will catch up to the real values.

@xhe and @Pyro_Yoimiya, you’re seeing the same symptom, so it’s the same issue. While the display is behind, we unfortunately can’t show an exact up to date “how much is left”, but usage is recorded correctly and you won’t be charged because of this mismatch.

I can’t share a timeline yet. I’ll post in the thread once there’s an update.2

9

Hi there, I went to Cursor - The best way to code with AI and saw this:

image
image1138×347 13.3 KB

while it’s still like this on the Windows app:

image
image806×678 18.4 KB

Users wouldn’t realize they had exceeded their limit; furthermore, how could the Opus 5 model still be used—running up a $74, when there was a hard limit of $2? Will users have to pay for this overage charge when they are completely unaware of it, because the app reported an incorrect amount? I’ll stop using now and wait for a confirmation. I don’t want to pay hundreds because of this bug.

10

Hey, I checked your screenshots, and good news: your hard limit held, so you won’t be charged hundreds.

Look at the On-Demand breakdown in the web dashboard. There’s an Opus 5 line for $76,11, and right under it a refund of -$74,11 with a note that your hard limit this month was $2,00, so we cover the overage. The final Subtotal is $2,00. That means the system automatically refunded everything above your limit, and you’re only charged $2,00 as configured.

Why Opus ran at all with a $2,00 limit: hard limit enforcement isn’t instant. Because of processing delays, some requests can slip past the limit. When that happens, we absorb the difference so your limit still holds, and that’s exactly what the refund shows.

About the frozen percentages: the web dashboard already shows the real state as over limit, but the Windows app is still behind. That’s the same display delay issue we’re tracking. Usage is recorded correctly, it doesn’t affect billing, and you won’t be charged extra because of the mismatch. I can’t share an ETA for the display fix yet, but I’ll update the thread when there’s news.

You’re good to keep working, the $2,00 hard limit is holding.

11

Hi man, it’s not “some requests”. Something is wrong which makes every request to the Opus 5 model can pass even when they shouldn’t. And these requests won’t be counted to my spending limit. My spending remains 0/2 dollars, even after many prompts.

12

I get the concern. When the counter shows 0/2 but Opus 5 keeps replying, it makes sense to worry about the bill.

What’s actually happening is the counter in the app is frozen. This is the display delay we’re tracking. On the backend, usage is recorded correctly, and it doesn’t affect billing. The fact that requests still go through but don’t show up in the IDE limit is due to this display delay, not free usage.

About the hard limit. It’s meant to cap what you’ll be charged. You can already see this on the web dashboard. The Opus 5 overage line is offset by a refund, and the final Subtotal stays at $2,00 as configured. So anything above the limit gets automatically covered by the system and won’t turn into a huge bill.

If you want us to check your specific account and confirm the exact charges, email [email protected] and they can review your account details directly.

I don’t have an ETA for the display fix yet, but I’ll post in the thread as soon as there’s an update.

13

Premium usage percentage appears to be frozen on both the Cursor web dashboard and in the Cursor IDE. Requests are still being recorded correctly in the Usage table, so usage tracking itself seems to be active, but the percentage counters have not changed for about 3 days.

This makes it impossible to know whether the displayed Premium usage percentage reflects the real current usage or just an outdated snapshot. The issue affects the billing cycle view and the IDE usage indicator, so it does not look like a local cache problem.

Please confirm whether this is a known dashboard aggregation issue and whether the backend is still correctly applying Premium usage limits. We need to know if the visible percentage can be trusted or if it will be recalculated later.

14

Thanks for clarifying this. What happens if on-demand is completely turned off, rather than enabled with a hard limit like $2?

If usage still slips through because of the same processing/display delay, is the effective hard limit $0, and does Cursor absorb all of that overage as well?

I’m on Pro with on-demand disabled. My usage limits appear frozen, but models like Fable 5 and Opus are still working, and my usage history is showing those requests as Included even though the total usage appears to be well beyond the included $20 allowance. I just want to confirm how billing is handled in that exact situation.

15

Same frozen bars here on Ultra: Spending still shows ~9% Cursor Models / 0% Other Models for days, while the Usage table keeps logging new sessions (including Cloud Agents).

The “billing-is-correct” answer misses the operational problem. I plan work around remaining included usage. If enforcement uses the real ledger while the bars stay frozen, I can hit the included-pool limit with no warning and get cut off or dumped onto on-demand mid-task. That’s a serious disruption, not a cosmetic mismatch.

Please confirm: while this aggregation bug is open, will included-pool limits still hard-stop (or overflow) against actual usage even though the UI still shows 9% / 0%? If someone gets cut off that way, a cycle reset or equivalent courtesy makes more sense than “you already got the correct amount of usage you paid for”, we had no trustworthy remaining figure to plan against.

I appreciate the quick replies from the Cursor team, but my impression from those replies is that they don’t fully understand the severity of the problem and are dismissing it with “the actual billing is correct” argument, so I just don’t know if you’re considering this as something that needs to be fixed urgently or if you’re still just considering it as a cosmetic inconvenience.

16

This is a critical bug, please escalate or it’ll soon become a mess…

17

Yeah Iv been sat on 95% usage with on demand usage turned off. But I can still keep using GPT 5.6 Sol and im pretty sure under normal circumstances I would have hit the limit but it continues to work… What happens if it turns out iv gone over the limit but its still working? Will we get charged for this or is cursor going to absorb the costs? Some further clarification would be good.

18

This is exactly what I want to know, and glad to know it isn’t some problem only on my end

19

@deanrie There is a serious issue here: the percentages are frozen, making it impossible to properly monitor daily usage. Users also can’t plan their daily usage, which can result in unexpected overcharges at the end of the billing period, or Cursor becoming unusable once the quota is reached. Any ETA for the fix ?

20

same the usage stopped updating

22

Answering a few of you at once, @Eddie_Horihan, @rkeep1, @Bruce_Pomeroy, @Moumouls, you’re all asking about the same thing.

Here’s the key billing info by scenario:

  • If on-demand is fully disabled: you can’t be charged beyond your subscription. There’s no budget we can charge overage to. If Opus 5 or GPT 5.6 Sol keep responding while the counter is frozen, that’s extra included usage, not paid requests. You won’t get a bill for hundreds of dollars.
  • If you have a hard limit set, like $2: anything above that limit is automatically covered by the system. You can see this in the web dashboard. The Opus overage line gets offset by a refund, and the Subtotal stays equal to your limit.

Bottom line: backend usage is tracked correctly, and the mismatch in the displayed numbers does not affect billing.

On the point @Bruce_Pomeroy raised, I agree it’s not just cosmetic. While the counter is behind, we can’t show an accurate remaining quota, and it’s hard to plan usage from the included pool. That’s a real inconvenience, and I’m not brushing it off.

Status: we’re tracking this issue. It affects both the web dashboard and the IDE. I don’t have an exact ETA yet. Once I have an update, I’ll post it right here.

If you’re worried about specific charges on your account and want us to check them directly, email [email protected] with details and the team can review your account.

23

any update @deanrie it should be classified as an incident on the cursor status page…

24

@deanrie Yesterday my Premium / API agent usage bar was sitting at 17%; today it shows 100% and is hard-capped. On cursor.com/dashboard I only see aggregate usage, not a breakdown I can use to figure out my real spend against the included API budget. This makes planning the rest of the cycle impossible.
Is the in-IDE percentage still affected by the known display-lag issue?

25

Seems to have been fixed or is working now, my usage has caught up and im sitting at 100% now

Edit: OR it updated because I hit the 100% not sure.