Why Cursor Agent mode burns through your requests way faster than you expect

You gave Cursor’s Agent mode one prompt — “add pagination to this table” — and by the time it’s done, your usage dashboard shows a dozen requests against it, not one. If you’re on a spending cap, that single task might have eaten a real chunk of it. And if you check which model actually ran the task, it’s not always the one you picked.

If you’re searching “cursor agent using too many requests,” “cursor burning through credits fast,” or “cursor keeps switching my model,” this is almost certainly why: Agent mode isn’t one request per prompt, and the model you selected doesn’t always stay selected.

Why this happens

Two separate mechanisms stack on top of each other here, and most people only ever notice the combined effect (a bill or a quota that drains faster than the task felt like it should).

Agent mode is several model calls per task, not one. When Cursor runs a multi-step agent task, each step — reading a file, running a search, proposing an edit, checking the result — is its own model call, billed separately. A task that looks like “one prompt” to you can be eight, ten, or more requests under the hood by the time the agent finishes reading context, editing three files, and verifying its own work. The more files and tool calls a task touches, the more it costs, even though you only typed once.

“Auto” model selection can override your explicit pick mid-task. Cursor’s community forum has a steady stream of reports of the model selector silently flipping to “Auto” — or from a cheaper variant to a pricier “Thinking” or “High” version of the same model — right after a plan-generation step completes, with no dialog and no confirmation. One reported case had Cursor auto-enabling models the user hadn’t approved after a spending limit was hit. The costly part isn’t just the pricier model itself: a model swap mid-conversation can force Cursor to rebuild context for the new model, which means more requests on top of the ones you already spent.

How to tell if this is your bug

1. Open Cursor’s usage dashboard and look at the per-request breakdown for a single task, not just the total. If one prompt maps to a wall of individual line items, that’s the multi-call behavior, not a billing glitch.
2. Check the model name shown in the composer at the start of an agent run versus partway through — especially right after a “Build Plan” or planning step finishes. If it reads “Auto” and you picked something specific, it switched.
3. If a spending cap is involved, check whether new models appear enabled in your settings that you didn’t turn on yourself. That’s the forum-reported worst case, not the common one, but it’s worth ruling out if a bill spiked hard.

The fix

Re-pin your model after every planning step, not just at the start. If your workflow uses “Build Plan” or similar multi-phase agent flows, the model can revert to Auto specifically at the phase boundary — check the selector after the plan lands, before you let the agent execute it.

Turn off Auto mode for work where cost matters, rather than trusting it to pick sensibly. Auto is meant to balance cost and capability for you, but on multi-step agent runs the “capability” side of that trade can silently win.

Reserve Agent mode for actual multi-file edits, not exploration. If you’re asking questions about the codebase or want a plan without execution, Cursor’s non-agentic Ask mode answers without spinning up the same multi-call chain — save Agent mode for the point where you actually want files changed.

Set a hard spending cap in Cursor’s usage-based billing settings. Since Cursor moved off the flat 500-request pool to usage-based billing pegged to model API cost, an unwatched multi-step run has no natural ceiling except your account limit. A cap turns a surprise bill into a stopped task you can restart deliberately.

Split large asks into smaller agent runs. A single sprawling prompt that touches many files compounds every one of the mechanisms above — more files means more tool calls, and a longer run gives Auto more chances to intervene. Smaller, scoped agent tasks are cheaper in aggregate and easier to audit in the usage dashboard.

How to confirm it’s actually fixed

Run a comparable task to the one that surprised you, and check two things afterward: the usage dashboard’s per-request count for that task (it should track roughly with the number of files and steps involved, not balloon past it), and the model name Cursor actually used for the whole run — including after any plan step — matches what you picked at the start. If both hold, the model is staying pinned and the request count is proportional to the work, not to a background switch you didn’t ask for.