# How to Reduce Cursor Token Usage

> Cursor burns tokens on @-codebase context, indexed retrieval, MCP tool output and long agent threads. Here's how to cut each one without dumbing the model down.

Source: https://tokenade.net/en/articles/reduce-cursor-token-usage · Updated: 2026-10-16

## How do you reduce Cursor's token usage?

You reduce Cursor's token usage by controlling what gets stuffed into the prompt: the codebase context it pulls in via `@`-mentions and indexed retrieval, the raw terminal output it swallows in Agent mode, the MCP tool results that pile up in the thread, and the conversation history it re-bills on each step. Tighten those four and the cost drops sharply — without making the model worse, because you're cutting noise, not the signal it actually reasons over.

This is the Cursor-specific companion to [How to reduce AI coding agent token usage](https://tokenade.net/en/articles/reduce-ai-coding-agent-token-usage). If you want the agent-agnostic version first, start there. The levers are the same across tools — what changes is the plumbing. Here I map them onto Cursor's concrete behaviour: how its index feeds context, what Agent mode dumps into a thread, and where your money actually goes.

I'm a Ph.D.-in-AI practitioner and I build token tooling for a living, so I'll be blunt about one thing up front: most "Cursor is expensive" complaints are not about the model being greedy. They're about the harness feeding it three times more context than the task needed. That's fixable.

Still deciding whether Cursor is the right tool at all? [Cursor vs Claude Code](https://tokenade.net/en/articles/cursor-vs-claude-code) compares the two on price, design and what each one costs once you're actually working.

## Why does Cursor use so many tokens?

Cursor uses a lot of tokens because it re-reads the entire thread on every turn and front-loads codebase context aggressively. The architecture is the same agentic loop every coding tool runs: at each step the model is re-sent the full conversation plus any tool results. So an oversized chunk pulled in early is paid for again on every turn that follows. (For the mechanics of why context size dominates cost, see [context window](https://tokenade.net/en/glossary/context-window) and [token](https://tokenade.net/en/glossary/token).)

Four patterns drive most of the bill:

**Codebase context via `@` and indexing.** Cursor indexes your repo with [embeddings](https://tokenade.net/en/glossary/embeddings) and retrieves relevant chunks when you `@`-mention files or the codebase. This is genuinely useful — it's [retrieval-augmented generation](https://tokenade.net/en/glossary/rag) applied to your code. But "relevant" is fuzzy, and a broad `@codebase` query can rake in dozens of files, most of which the model skims and discards. You pay full input price for every retrieved chunk.

**Unfiltered terminal output in Agent mode.** Agent mode runs commands — `npm test`, `tsc --noEmit`, `git diff`, build steps — and the raw output lands straight in the thread. A failing test run can emit 10,000+ tokens of stack traces, passing checkmarks and timing tables. The model needed maybe 50 of those tokens: the failing test name and the broken assertion. The rest is cargo, and you re-pay for it every subsequent turn.

**MCP tools.** What an [MCP](https://tokenade.net/en/glossary/mcp) tool returns — a GitHub listing, a browser snapshot, a query result — lands in the thread and is re-sent on every later turn, which quietly compounds across a long session. Tool definitions add a standing cost too wherever the agent loads them all upfront instead of deferring them. See [Best MCP servers for Claude Code](https://tokenade.net/en/articles/best-mcp-servers-for-claude-code) — the principle is identical in Cursor.

**Long Agent threads.** Cursor's Agent keeps the conversation growing. By turn thirty, that early 8,000-token file read is being re-sent for the thirtieth time. The thread doesn't forget — it re-bills.

## How much does this actually cost?

It costs whatever your model's input price is, multiplied by every redundant token, multiplied by every turn it survives — which is why context bloat compounds instead of adding. Current frontier pricing makes the arithmetic concrete:

| Model | Input ($/MTok) | Output ($/MTok) |
|-------|---------------|-----------------|
| Claude Opus 5 | $5 | $25 |
| Claude Opus 4.8 | $5 | $25 |
| Claude Sonnet 5 | $2 | $10 |
| Claude Haiku 4.5 | $1 | $5 |
| GPT-5.5 | $5 | $30 |

Say you're on Sonnet 5 at $2/MTok input. A single 8,000-token file read that rides along for 25 turns costs you 200,000 input tokens — about $0.40 — for one file you read once. Multiply by the dozen files a non-trivial task touches and a single Agent session quietly spends a few dollars on re-reads alone. On Opus 4.8 or GPT-5.5 at $5/MTok, it's worse.

One mitigation Cursor and the providers already give you is [prompt caching](https://tokenade.net/en/glossary/prompt-caching): cache reads bill at roughly 10% of the input rate.

That helps with the stable prefix of a thread, but it doesn't save you from retrieving the wrong files in the first place — you still pay to write them into the cache, and a cache hit on noise is still noise occupying the [context window](https://tokenade.net/en/glossary/context-window). Caching is a discount on a bill you should be shrinking, not a substitute for shrinking it.

The figures above are what the *model* costs. For what Cursor itself charges on top — what Pro includes, and how its token-based billing differs from the request model it replaced — see [Cursor pricing](https://tokenade.net/en/articles/cursor-pricing). For the broader picture, [AI coding agent token costs](https://tokenade.net/en/stats/ai-coding-agent-token-costs) and [LLM API token pricing](https://tokenade.net/en/stats/llm-api-token-pricing).

## Which built-in controls actually help?

**Two ignore files that do different jobs, and a mode that changes what a failed attempt costs you.**

The ignore files are where most of the avoidable spend lives, and the distinction between them is the part people get wrong:

- **`.cursorignore`** blocks access. Files listed there are excluded from indexing *and* from what the AI can reach. Cursor's own documentation gives two uses: keeping API keys, credentials and secrets away from the model — with the honest caveat that "complete protection isn't guaranteed due to LLM unpredictability" — and, in large codebases or monorepos, excluding irrelevant portions for faster indexing and more accurate file discovery.
- **`.cursorindexingignore`** excludes from indexing *only*. Those files stay reachable by AI features but stop appearing in codebase searches. This is the one for large generated files and vendored dependencies: you don't want them surfacing as retrieval results, but you don't want them unreachable either.

If your goal is a smaller bill rather than a security boundary, `.cursorindexingignore` is usually the right tool. Broad `@codebase` retrieval that keeps returning a generated client or a vendored SDK is retrieval you're paying for on every turn it survives.

Both use gitignore-style patterns — `*`, `**`, `?`, `!` to negate. One gotcha worth knowing: you cannot re-include a file whose parent directory was excluded with a wildcard, because excluded directories aren't traversed at all. `public/*` followed by `!public/assets/style.css` silently does nothing; you have to exclude `public/assets/*` and negate inside it. There's also a global ignore list in user settings, empty by default, for patterns you want on every project.

And the limit to hold on to: the terminal and the MCP server tools that Agent uses **cannot** block access to code governed by `.cursorignore`. An ignore file shapes retrieval. It does not shape what a shell command drags into the thread, which is why output filtering is a separate lever rather than the same one.

**Plan Mode** is the other control worth using deliberately. It researches the codebase, asks clarifying questions and produces a reviewable plan before any code is written. The token argument for it is not the planning — it's what Cursor's docs recommend when the result is wrong: revert, refine the plan, run it again, rather than steering an in-progress agent through follow-up prompts. A repair conversation re-sends the whole failed attempt on every turn. Re-running a corrected plan starts clean.

## How to cut Cursor's token usage today

Cut Cursor's token usage by being deliberate about retrieval, filtering tool output, pruning MCP servers, and keeping threads short. Here's the order I'd do it in:

1. **Stop using `@codebase` as a reflex.** When you know which files matter, `@`-mention them by name. Broad codebase retrieval is for genuine "where is X" questions, not for "fix this function I already have open." Precise context is cheaper *and* produces better answers — the model isn't distracted by twelve near-miss files. This is the whole point of [semantic code search](https://tokenade.net/en/glossary/semantic-code-search): retrieve the relevant symbols, not the relevant *files*.

2. **Filter terminal output before it enters the thread.** You don't need 200 passing-test lines; you need the failures. Pipe noisy commands through something that keeps the diagnostic and drops the decoration. This is [output filtering](https://tokenade.net/en/glossary/output-filtering), and on a flaky test suite it's often the single biggest win.

3. **Prune your MCP servers and shrink what they return.** Disable the ones you're not using in the current project: fewer tools means fewer wrong tool picks, and on setups that still load every tool upfront, less manifest overhead on every turn. For the servers you keep, the bigger cost is their output — a GitHub listing or a browser snapshot stays in history for the rest of the session — so compact it before it lands.

4. **Start new threads more often.** When the task changes, open a fresh Agent thread instead of continuing a 40-turn monster. A clean thread doesn't carry forty turns of re-billed history. Treat thread length as a budget, not an afterthought.

5. **Request skeletons, not whole files, for orientation.** When you only need to know a file's shape — its functions, exports, signatures — a [skeleton](https://tokenade.net/en/glossary/context-compression) of 300 tokens beats a full read of 6,000. Read the body only once you know which body you need.

If doing all of that by hand sounds tedious, that's because it is. It's exactly the kind of mechanical discipline a tool should enforce for you — which is the reason I built one.

## Can a tool do this automatically?

Yes — automating these four levers is precisely what Tokenade does, which is why I'm not going to pretend hand-discipline is a real long-term answer. Tokenade sits between your agent and its tools, compacting what they return before it enters the context, and applies the cuts above without you thinking about them:

- [semantic code search](https://tokenade.net/en/glossary/semantic-code-search) instead of eager file dumps;
- [output filtering](https://tokenade.net/en/glossary/output-filtering) on noisy command results;
- skeleton [context compression](https://tokenade.net/en/glossary/context-compression) for orientation reads;
- and MCP output compaction (dedicated handling for GitHub, Playwright, Postgres and other popular servers).

A local, graphical savings report (`tokenade dashboard`) shows you the tokens it actually clawed back, by day, project or model — because a savings claim you can't measure is just marketing.

It works with Cursor, Claude Code, Codex, Copilot, Windsurf and the rest — the levers are tool-agnostic, so the implementation should be too.

Compaction runs entirely on your own machine — your prompts and your code never leave it; I'd want the same. The code is open for you to audit.

It's free and open source (MIT/Apache-2.0) — [install it](https://tokenade.net/en/docs/install). If you've already read [Best Claude Code token optimizers](https://tokenade.net/en/articles/best-claude-code-token-optimizers), you know where it sits in the field.

## What goes wrong (anti-patterns)

The failure modes are mostly over-correction, and they're worth naming because cutting context badly is worse than not cutting it.

**Starving the model.** If you strip context so hard the model can't see the function it's editing, it hallucinates the surrounding code. The goal is removing *noise* — redundant reads, decorative output, unused fields in tool results — not removing the signal the model reasons over. A good optimizer cuts the test-suite checkmarks and keeps the failing assertion.

**Trusting `@codebase` to be precise.** Indexed retrieval is approximate by design. It returns what's *similar*, which on a large monorepo means a generous helping of plausible-but-wrong files. Naming the file you mean is both cheaper and more accurate.

**Measuring nothing.** "Feels cheaper" is not a metric. Without a number — tokens saved per session, cost before and after — you can't tell whether your changes helped, hurt, or did nothing. This is why I insist on a dashboard rather than a vibe.

**Confusing caching with reduction.** [Prompt caching](https://tokenade.net/en/glossary/prompt-caching) discounts repeated context to ~10% of input price, which tempts people to stop caring about what's in the prompt. But cached noise is still noise the model has to read past, and you still paid to write it. Cache *after* you've trimmed, not instead.

## Frequently asked questions

### How do I minimize token usage in Cursor?

Name the files you need with `@` instead of reaching for `@codebase`, filter long terminal output, disable MCP servers you aren't using in this project, and open a new Agent thread when the task changes. Each of those cuts context that would otherwise be re-sent on every turn of the thread.

### How do I use fewer tokens in Cursor without getting worse answers?

Cut noise, not signal. Passing-test lines, near-miss retrieval results and bloated tool results add tokens without helping the model. Keep the file you are editing and the failing assertion; drop the rest. Precise context is usually cheaper and more accurate at the same time.

### How do I optimize Cursor's token usage on a large codebase?

Add generated files and vendored dependencies to `.cursorindexingignore`. They stay reachable, but stop surfacing in codebase searches you pay for. Use `.cursorignore` only for what the AI should not reach at all, such as secrets.

### Does Plan Mode save tokens in Cursor?

It can. When a result is wrong, Cursor's docs recommend reverting, refining the plan and running it again rather than steering the agent with follow-up prompts. A repair conversation re-sends the whole failed attempt on every turn; a corrected plan starts from a clean thread.

---

**See also:**
- [How to reduce AI coding agent token usage](https://tokenade.net/en/articles/reduce-ai-coding-agent-token-usage) — the agent-agnostic pillar
- [How one Cursor prompt burned 300M tokens](https://tokenade.net/en/case-studies/cursor-auto-mode-token-bill) — what auto mode can cost when nobody is watching
- [How to reduce Claude Code token usage](https://tokenade.net/en/articles/reduce-claude-code-token-usage) — the same levers for Claude Code
- [Context engineering](https://tokenade.net/en/articles/context-engineering) — the discipline behind all of this
- [Best Claude Code token optimizers](https://tokenade.net/en/articles/best-claude-code-token-optimizers) — where the tools stand