Pricing, Composer, and MAX Mode

Billing depends on the plan and routing mode

Cursor’s billing is not one universal two-pool model. Cost can depend on your plan, selected model, routing mode, included usage, and any on-demand or token-based usage available to that plan. Use the live Cursor pricing page and your usage dashboard as the source of truth.

• Included usage - plan-specific usage that covers some requests or model work.
• Additional usage - on-demand or token-based charges that may apply after included usage, depending on plan and configuration.
• Routing choices - Auto or other routing modes can change which model is selected and how usage is accounted for. Do not infer billing from the model name alone.

The safe decision pattern is:

   • Use Auto for routine work when its current routing and price fit.
   • Use a specific model or MAX Mode when the quality or context is worth the
     current cost.
   • Check the usage dashboard before repeating an expensive pattern.

That’s the lever. You’re choosing a model and a routing/billing posture together. The skill is spending deliberately, the same spend-where-it-pays instinct from the modes chapter aimed at the meter instead of the latitude.

Teams add a Cursor Token Rate

On Teams plans there’s an extra layer: a Cursor Token Rate applied on top of the model’s underlying cost. So the API-pool math on a team plan isn’t just “the model’s per-token price” - it’s that price plus the team rate. If you’re on an individual plan this won’t bite; if you’re on a team plan, it’s why the same model can cost differently than a teammate on a personal account quoted to you.

Composer

One name on the roster isn’t a third-party vendor’s - Composer is Cursor’s own model, built by Anysphere. Cursor 2.0 introduced it as Anysphere’s first agentic coding model - a frontier model billed as roughly 4x faster than similarly intelligent models - and the line has since iterated through several versions, so the current Composer in the picker is newer than the 2.0-era original. It’s an agentic coding model: trained for the edit-test-fix loop the agent runs, not a general chat model bolted into an editor.

The reason Composer matters here is that it is Cursor’s own agentic model, not that it guarantees one billing treatment. Its availability, included usage, and pricing can vary by plan and release. Choose it when its behavior fits the task, then confirm the current cost in Cursor’s pricing and usage surfaces.

MAX Mode: maximum context, per-token pricing

MAX Mode expands the context window to the selected model’s maximum. It can also change how the request is billed, depending on the model and plan, so confirm the current treatment before using it.

So MAX Mode is the explicit “I need this model’s full context and will check the resulting cost” button. The right time to press it is a genuine whole-codebase reasoning task where the limiting factor is how much the model can see at once - a cross-cutting refactor, a bug whose cause and effect are in different corners of budgetcli. The wrong time is everyday work, where you may be paying for context you do not use.

The friction: model and plan behavior changes

Here’s the sharp edge: model availability, context limits, and billing treatment change. Some models or plans may require MAX Mode or apply different usage rules, while others may not. Check the picker and pricing details for the current release instead of assuming a model-selection rule from an older tutorial.

The operator takeaway doesn’t depend on which models are on the list this month: selecting a stronger or longer-context model can change the request’s cost. That’s not a reason to avoid those models - it’s a reason to reach for them on purpose, on the turns where their reasoning earns the current bill, rather than leaving one pinned out of habit.

With the pools straight, one workflow from the last chapter reads differently: it isn’t only a quality trick, it’s a way to spend the expensive pool exactly once. Next: plan with one model, build with another