Cursor Max Mode and Token Budget Management in Long Agentic Tasks

Picture an agent halfway through a refactor across a dozen files. It renamed a function in file three, updated the callers in file six, and then, by file nine, it has forgotten the rename ever happened. It reintroduces the old name, breaks the build, and starts arguing with itself about which version is correct. That failure has nothing to do with the model being bad at coding. It happens because normal mode hands the model a cut-down slice of context, enough for a single focused edit, not enough to hold a multi-file refactor or a long debugging run in view all at once.

Agentic work has changed what a single "task" even means. It used to be one prompt, one answer. Now it's dozens of model calls chained together, each one needing to see what the last one did, each one building on a growing pile of decisions made earlier in the session. Lose track of that history and the agent doesn't just slow down. So it redoes work it already finished, contradicts an edit it made ten steps ago, or wanders right past the file where the actual bug is sitting.

Max Mode exists to close that gap. Alongside the bigger context window, it also raises the tool call ceiling from 25 to 200 per interaction, which lets a single agent session plan, implement, test, and fix errors in one continuous run instead of stopping every few steps to ask permission to keep going.

What Max Mode does at the request level

Max Mode changes two things about every request: how much context gets packed in, and how many tool calls the agent is allowed to make before it has to stop. Both of those changes stack on top of each other across a long agentic session, and that stacking is the whole story.

On the context side, normal mode has Cursor trim the window down before sending it to the model. Max Mode skips that step and passes the full context window straight to the API, up to 200,000 tokens for Claude models, and considerably more on models built to handle it. On the tool call side, normal mode caps a session at 25 calls (a limit paid plans have since raised); Max Mode raises that ceiling to 200, so planning, writing code, running tests, and fixing what breaks can all happen in one unbroken sequence.

200 tool calls does not mean one giant request: it means up to 200 separate calls to the model, each one carrying its own full context payload, billed at the full rate for whatever got loaded in at that step. Picture step 15 of a 50-step session. The model looks at the current file plus the accumulated trail of everything that happened in steps 1 through 14, reassembled fresh and sent again. That reassembly happens at every single step.

Max Mode is also a plain on/off switch, not something scoped to one conversation. You can leave it off when you're poking around a codebase asking questions, flip it on when you kick off a long autonomous task, and flip it back off once that task wraps.

How Max Mode pricing compounds

Every one of those 200 tool calls bills at the full API rate for a full context window, so a long Max Mode run can cost far more than normal mode. It can cost ten times more, and most of that cost stays invisible until the session ends and the bill arrives.

Cursor changed its billing model recently, and that change is what produced the cost compounding described above. Up until August 24, 2026, Cursor charged a flat per-token rate no matter which model handled the request. That flat rate is gone. Requests now bill at the list price of whatever model actually ran the job, and that splits across two separate pools. The "Cursor Models" pool covers first-party models (Grok 4.7, Grok 4.6, Grok 4.5, and Composer 2.5) with generous included usage. The "Other Models" pool covers third-party frontier models from Anthropic, OpenAI, and Google, charged at each model's own API price, plus a small per-token Cursor Token Rate on Teams and Enterprise plans.

Max Mode now lives only on legacy request-based plans, where it adds a percentage surcharge on top of whatever the base API rate already is. Running Claude Sonnet 4 in Max Mode adds only a modest markup, a bit more than a normal request. Running Claude Opus 4 in Max Mode can climb to several times the cost of a normal request. On the Pro plan, which comes with $20 of included usage, that same $20 covers a lot of ordinary Sonnet 4 requests and a much smaller number of Max Mode ones.

Do the arithmetic on a real session. If every one of 150 tool calls costs a few cents once the full context and surcharge are factored in, the total reaches several dollars before the agent even finishes the task. A single complex Max Mode run, heavy on tool calls, heavy on input context, heavy on output, can rack up a meaningful cost in one sitting. Third-party guides have flagged that heavy Max Mode use can burn through included usage in a matter of days, even on the Ultra plan. None of this is a knock on Max Mode. It's the honest arithmetic that tells a developer when the feature is worth turning on.

The plan structure that determines how much Max Mode you can run

Picking the right Cursor plan for Max Mode work isn't about which tier reads best in the marketing copy. It comes down to one question: does this plan's credit pool survive the number of long agentic sessions actually being run each month?

Hobby, the free tier, caps agent requests so tightly that it isn't built for Max Mode work. Pro+ gives about three times the usage Pro allows, so if you run Max Mode daily, you get real breathing room before you hit a wall. Teams Standard gives each seat its own dual-pool allowance, Cursor Models and Other Models tracked separately, and because Max Mode costs are otherwise the kind of thing nobody notices until the invoice lands, the centralized billing and usage analytics that come with it let a team catch overruns before the invoice does. Teams Premium runs about five times Standard's usage, fitting teams that run agentic pipelines as a regular part of the job. Enterprise, priced case by case, adds pooled usage, invoice or purchase-order billing, and SCIM seat management, the kind of governance layer that keeps Max Mode spending under control across an organization with tens of thousands of engineers.

Annual billing knocks a meaningful percentage off the price across every paid tier, and at the rate Max Mode burns through credits, that discount changes the real cost of running it regularly. Once the monthly pool runs dry, overage billing kicks in automatically at the same API rates, unless a spend limit has been set under Settings → Billing. On Teams plans, on-demand usage is switched on by default, so a session that crosses the monthly line will bill extra without any warning. On the individual plans (Pro, Pro+, Ultra), that overage behavior has to be turned on deliberately first.

The limits of bigger context

It's tempting to treat a bigger context window as a pure upgrade: more tokens in, better output out. That assumption doesn't hold. Past a certain point, stuffing more into the context window can actively make the model worse at finding the piece of information it actually needs.

This is sometimes called the "lost in the middle" problem: across a range of tasks, models reliably pay attention to the start and end of their context window, and consistently miss material sitting in the center. Dump 200,000 tokens of an entire codebase into a request aimed at one specific module, and the model doesn't necessarily get smarter about that module. It can miss it completely while its attention gets pulled toward the noise surrounding it.

Long sessions make this worse in a different way. Every tool output, every piece of conversation history, every intermediate decision from earlier steps keeps accumulating in the context, and a lot of it goes stale fast. By step 47 of a long agentic run, the model is no longer reading a clean, focused prompt. It's reading everything that happened across the previous 46 steps, much of which no longer applies to the problem in front of it, and that pile can pull the model toward patterns that stopped being true steps ago.

That's the honest complication in all of this: Max Mode's bigger ceiling is necessary, but it isn't the whole job. Getting the window is half the work. What actually goes inside that window at each step is what decides whether the agent stays on track or drifts. The teams that get reliable results out of long agentic runs aren't the ones who simply flip Max Mode on and walk away. They actively shape what the model sees at every single step.

Managing context consumption across a long Max Mode session

Treat context like a budget, not a tap that's always open. That's the shift that separates a Max Mode session that finishes cleanly from one that drifts, stalls, or quietly burns through a month's credits halfway through a task.

Start by scoping context to what the current step needs. If the agent is editing one function, it doesn't need every open tab from three files ago sitting in its context. Closing anything irrelevant trims Cursor's indexed context and lowers the input token cost of every call that follows. On a session that stretches across many steps, actively summarize what's already been done and strip out stale tool outputs so they don't pile up in the background. That pruning habit, done deliberately rather than left to chance, is a big part of what separates agent runs that stay reliable from ones that start to drift by step 40.

Long tasks also do better broken into checkpoints. Instead of one unbroken 150-tool-call marathon, split the work into a sequence of shorter sessions, where each new one opens with a clean, summarized brief of what the last one actually accomplished. That keeps the thread intact, so step 41 doesn't drag in 40 steps of accumulated noise. Not every step needs Max Mode. Exploring a codebase or asking what a module does doesn't call for 200,000 tokens of context. Save Max Mode for the steps that genuinely need the full picture, like cross-file refactors and end-to-end test runs, and run everything else in normal mode.

Model choice matters here too. Running Max Mode with Claude Sonnet 4 instead of Claude Opus 4 changes more than quality, it changes the cost per step, and that multiplies across every single tool call in the session. Gemini models bring their own context ceiling and cost profile into that same calculation.

One habit deserves more weight than the rest: set a spend limit under Settings → Billing before kicking off a long Max Mode session. Skip that step, and overages bill automatically after the fact; nothing stops a runaway session from draining a month's pool before the task is even finished.

When Max Mode is worth the cost

Max Mode earns its premium when missing context would produce wrong output, but it wastes money when normal mode's smaller window was already going to be enough.

Reach for Max Mode when the agent genuinely needs to hold several large files in view at once: a refactor that spans multiple services, an API contract change that touches a long list of consumers, a large test suite migration where the pieces don't make sense in isolation. Reach for it when a bug or a data flow is scattered across files that normal mode would truncate before the agent ever sees the connection. And reach for it when the task is long enough that normal mode's 25-tool-call ceiling would force a stop partway through. If a task genuinely needs all 200 calls, it almost certainly needs the full context that comes with them too.

Skip Max Mode when the work is scoped to one file or one clearly defined function, where the model doesn't need the rest of the codebase to write something correct. Skip it for exploratory work, understanding what a module does, asking a question about an API, reviewing a diff, where the extra cost buys no extra accuracy. And skip it when the monthly credit pool is already running low and a bigger task is coming later in the billing cycle. Pro's $20 of included Other Models usage disappears fast at Max Mode rates, and that budget is worth protecting for the task that actually needs it.

The obvious objection: nobody knows in advance whether a task is going to need the full context or not. Starting in normal mode and letting the agent's own failure tell the story is the practical answer. If it stalls because it can't see a file it needed, that's the signal to restart in Max Mode with a tighter, more deliberate scope, not to run Max Mode by default on everything.

How Cursor's broader agentic architecture shapes Max Mode

Max Mode is one piece of a larger agentic system built around multiple frontier models, cloud-run agents, and tooling meant to extend what a single session can do, including MCP integrations and automations that carry context across an entire team.

With that multi-model structure, a developer actively chooses the cost-versus-capability tradeoff at each step. Cursor's architecture lets a developer pair Max Mode with whichever model fits the step in front of them, Claude Sonnet for the routine parts of a task, Opus for the steps where getting the decision right outweighs getting it cheap. Framed that way, token budget management becomes infrastructure planning: deciding, step by step, where the full context window earns its cost and where it doesn't.