The billing reporting still needs some work on making it clear what exactly uses premium requests. Additionally there is an issue with how they are being totaled or I’m not understanding the data that’s available.
I’ve been checking in on my account settings to monitor my usage. I just saw a spike in premium requests from ~60 to. ~90. This happened in a couple minutes within the same composer window and coincided with some anthropic network issues.
At first I saw a jump of a few requests. Up until this point I had been seeing 1 fast request = 1 composer interaction up to 25 tool calls where one must resume – which continues to cost 1 additional request. This coincided with the toolCallComposer log in account settings (which btw doesn’t show unless you turn on usage based pricing a flaw in it’s own).
At first I saw a small jump of maybe 5-10 premium usage requests in a minute or so from ~60 to ~70. My first though was that the billing is naive and charging once per http retry. Then I checked back a moment later to see my requests shoot up to ~90 something.
Now my billing just reset on the Feb 24th. Right now my account shows 96 requests in that day and a half or so. If I extract the logs starting at the billing cutoff and get some counts:
Where are the additional 30 fast requests coming from? Maybe HTTP retry on anthropic API and not getting logged? It’s definitely not a billing cutoff date misunderstanding as I can clearly see the last slow request on Feb 23rd before my billing reset. It’s been long enough that I doubt it’s an eventual consistency issue. I believe fast apply is free but even if it was 1/3 of a fast request that doesn’t add up either.
@danperks flagging you instead of adding on to the last billing transparency issue. Thanks in advance.
Thanks for the detailed breakdown of what you’re seeing. You’re right that there’s currently some inconsistency with the analytics. We had some sync issues today but this should be more accurate going forward
For now, the most reliable way to track your usage is through the Usage page which shows your current premium request count. The detailed logs might take a bit to catch up, especially during API hiccups
Just to clarify a few things:
fastApply doesn’t count towards premium requests
Each Claude 3.7 interaction counts as 1 premium request
Retries shouldn’t count as additional requests
I’ll make sure the team knows about the logging discrepancy you’re seeing between the total count and the detailed breakdown
Each Claude 3.7 interaction counts as 1 premium request
Retries shouldn’t count as additional requests
Appreciate it @danperks. If this is the case I do suspect folks are getting overcharged.
I definitely didn’t interact with Claude 30 times over the course of a few minutes in the same composer. Are requests logged somewhere?
I haven’t seen any updates in totals in my usage logs
There’s also a discrepancy between toolCallComposer and the number of interactions in my history. A difference of 9 over the course of today so far. I believe a couple are from reverting but 9 seems unlikely. So there may be a separate issue there.
So I suspect it’s a consistency issue. My money is on a charge per retry and those failed requests not making it to the logs.
I’ve got the team looking into your concerns, but the standard here should be as I mentioned in my last message and we don’t currently believe our implementation deviates from this!
Appreciate the investigation work on your end, will let you know if we find anything abnormal.
Again, really appreciate it! However I would politely request an audit and an explanation for the discrepancies even if you believe it’s a correct implementation. I don’t mind losing a couple bucks from a bug on your end, however I do care about not being able to trust Cursor to be transparent about said bugs.