Skip to lesson
Exit
Cursor Product & Architecture1 / 2

2 min lesson

The request math behind "why did one chat cost 30 requests?"

Name the parts in "The request math behind 'why did one chat cost 30 requests'" and give the practical job of each one.

Step 1 of 2

The request math behind "why did one chat cost 30 requests?"

The most confusing billing ticket on legacy request-based plans is a single chat that burned a surprising number of requests. The answer is a concrete mapping, not a bug, and being able to walk it through calmly is what closes the ticket.

How requests are calculated
Non-max-mode models
Usually consume roughly one or two requests per use. This is what users expect.
Max-mode models
Map their underlying API cost back to a request count. That's how a single chat can consume ~30 requests.
A request ≈ 8 cents
On legacy request-based plans a request roughly equals ~8¢, so a 30-request Max-mode chat reflects ~$2.40 of model API cost, not an overcharge.
Tokens map to dollars
Each model has distinct input/output/cached rates; heavier models and longer agent runs cost more. Cloud-agent pricing is usage-based and draws from the team's pooled usage.

Walk the user through the mapping: Max mode trades a bigger context window for a higher request count. It's pricing working as designed.

Say it like this

"That 30-request chat isn't a glitch. You were on a Max-mode model, which maps its API cost back to requests, and on the legacy plan a request is about 8 cents. So a heavy Max-mode chat lands around 30 requests. If you don't need the larger context, switching to a standard model keeps it at one or two requests per turn."