Cursor Models: What You Can Use After the October Change

Verified on October 25, 2026 against Cursor's live model, subscription, Router and subagent documentation. The consequential distinction is between a model being available and its usage being included: those are different promises.

Cursor models: what models does Cursor use now?

Cursor supports its own Grok and Composer models alongside third-party Claude, GPT and Gemini models, but your subscription determines access. Under The X Subscription, the current subscription system, paid accounts have a weekly Cursor-model allowance shared with Grok. Third-party requests use prepaid credit. Cursor's current model reference documents that split.

The table separates current subscriptions from legacy accounts. “Included” means usage draws from an allowance, not unlimited requests. Free has limited usage; paid allowances depend on the account.

Sources: available models, current subscriptions, and legacy plans. Teams and Enterprise also pay the Cursor Token Rate on eligible third-party requests; the exclusion list matters. Individual accounts do not pay that additional rate.

Monthly individual prices before tax are Free $0, Plus $8, Premium $30, Super $100 and Ultra $200, per Cursor's published prices; see Cursor pricing for allowances, team seats and legacy plans.

Cursor free models and Plus restrictions

Free lets you try the first-party models; Plus is a restricted first-party coding setup. Plus fixes Fast off and reasoning effort at medium, with Grok 4.7 using a 256k context window. It excludes Auto, third-party models and your own API keys. These are explicit plan limits, so a missing Claude entry is not necessarily an installation problem.

For a developer making small changes with Composer, that may be enough. For someone whose workflow specifically depends on Claude or GPT, Plus fails the requirement before output quality enters the discussion. Decide which model access you need before subscribing.

Cursor premium models and the legacy distinction

Premium and higher make third-party models available; they do not include a third-party allowance under the new subscription. The distinction changes for an existing Pro, Pro+ or legacy Ultra account: its monthly Other Models pool still covers third-party usage at the model's API list price. Once that allowance runs out, enabled on-demand usage pays for more. Cursor's legacy-plan reference spells out the difference.

Think of the new account as a membership with an included house menu and separately billed guest dishes. A legacy account also has an allowance for those guest dishes. The same model name can therefore appear on both accounts while drawing from different balances.

A legacy subscriber should inspect actual third-party usage before migrating. Cursor says switching to the new subscription is optional and permanent. A larger first-party allowance cannot replace an included Claude balance if Claude is what you use most.

Best Cursor models for everyday and difficult jobs

Choose by the job's failure mode: slow interaction, incomplete sustained work, or a need for a particular model's behavior. Cursor's selection guidance recommends Composer for interactive coding, Grok 4.7 for the hardest long-running tasks, and Claude Opus or GPT-5.6 Sol for complex multistep work. The examples below apply that guidance to everyday development work.

Composer 2.5: start here when you are actively steering the edit. Cursor describes it as tuned for tool use, file edits and terminal operations. Its model page lists a 200k context window, a fast variant for interactive sessions and a standard variant oriented toward lower token cost.

A component change with a clear failing test is a good starting job: ask for the smallest change, inspect the diff and keep the conversation moving. The stopping rule is repeated repair without resolving the underlying problem. When that happens, improve the specification or escalate the model instead of extending an unproductive conversation indefinitely. Check the speed setting before treating “Composer” as one fixed usage profile.

Grok 4.7: use it when the task needs sustained investigation and verification. Cursor says it improves self-verification and longer-running work relative to Grok 4.6. A cross-file authentication change is the kind of assignment where persistence matters: the agent must connect the request handler, session logic, tests and failure paths. Define those checks before handing over the task.

The Grok 4.7 reference distinguishes a 256k standard context from a 500k maximum, measured in tokens, the chunks of text and code a model processes. Context is how much material a model can consider in a request; capacity does not guarantee that it notices the relevant dependency. Supply the failing behavior and acceptance criteria, not just more files.

Grok 4.6 and Grok 4.5: retain them where an existing workflow earns its place. Cursor still lists both, but its Grok 4.6 page recommends 4.7 for stronger self-verification and longer work. There is little reason to make an older version your default for a new difficult task merely because it is familiar. There is also little reason to disrupt a passing workflow without evaluating the replacement. The Grok 4.7 versus Grok 4.6 comparison covers that migration decision.

Claude Opus and GPT-5.6 Sol: choose deliberately for complex work or a second approach. Their availability is useful when a problem benefits from a different model's interpretation. Keep the task and acceptance tests stable when switching, so you can judge the result instead of rewarding a more convincing explanation.

Cursor's GPT-5.6 Sol page describes persistent agent work and concise planning/debugging responses, but also names overuse of subagents and occasional waiting for an explicit instruction to execute. If the model proposes the right fix and stops, give a clear implementation instruction. A polished plan is not a completed ticket.

Gemini: evaluate it when you already have a reason to prefer it. Cursor's general guidance notes a preference among some users for Gemini Pro; that is not a published claim that Gemini wins a particular coding category. The live catalog includes Gemini 4 Argon, Gemini 3.1 Pro and Gemini 3.8 Flash, alongside newer Claude entries such as Opus 5.5 and Sonnet 5.5. Check the directly selectable catalog, because those names are separate from Auto's routing pool.

The practical default is Composer for work you can review continuously, Grok 4.7 when sustained investigation is the bottleneck, and an approved third-party model when its output justifies the separate usage. Keep human review and repository checks as the acceptance standard for all of them.

Cursor Auto model: Cost, Balance and Intelligence

Auto is a selection mechanism, not another model, and the newer Cursor Router currently requires Teams or Enterprise. Cursor's Router reference scopes Balance and Intelligence to that system. Plus explicitly excludes Auto. Do not assume every account sees the same Auto menu.

These mode definitions and billing rules come from Cursor's Router documentation. Cursor describes Balance as the default for new users, while team admins control which modes are offered. “Suggested use” is the operational interpretation: start a routine ticket on the ordinary setting and escalate when the task, rather than curiosity, calls for it.

The current documented Router pool is GPT-5.5, Claude Opus 5, Grok 4.6 and Claude Fable 5. Cursor warns that the pool changes and a model may become directly selectable before routing includes it. Grok 4.7 and GPT-5.6 Sol being in the picker therefore does not establish that Auto routes to them. Use the published pool as the reference.

For a team lead, routing policy also has dependencies. Blocking Grok 4.6 disables Router; blocking both GPT-5.5 and Claude Opus 5 also disables it. Blocking just one of the latter reduces routing quality, according to Cursor. Review an allowlist as a working routing configuration, not simply a list of preferred vendors.

Enterprise admins must enable Router, and team controls can restrict modes or impose Auto. The admin controls explain why a developer may be unable to change a setting that another account can see. A third-party route still follows third-party billing; selecting Auto does not turn it into included first-party usage.

How to switch models without losing track of your settings

Change the model in the chat or agent panel, then check its settings before sending the next task. Cursor says the selection persists across conversations. That persistence is convenient until yesterday's expensive or specialized choice quietly becomes today's default. Model-switching instructions are the same starting point for a named model or Auto.

Cursor multiple models: how subagents choose theirs

The parent model picker does not determine every subagent's model. A subagent is a separate worker delegated part of the job. Cursor's built-in workers select a model for the subtask; custom workers default to inherit, which uses the parent's model, or can specify a model ID. The parent can also name a model when launching a worker. Cursor's subagent reference documents these paths.

A concrete custom configuration can live in .cursor/agents/local-review.md:

---
name: local-review
description: Reviews a bounded code change for correctness.
model: "composer-2.5[fast=false]"
---
Review the supplied diff and relevant tests.
Report concrete defects with file references. Do not edit files.

The model setting explicitly selects standard-speed Composer 2.5. Use model: inherit instead when you want the worker to follow the parent. The model syntax comes from Cursor's configuration reference.

The billing consequence is easy to miss. A parent on Grok, Composer or Auto can delegate to a named third-party model. That worker uses prepaid credit under the new subscription or Other Models on a legacy plan. Its task card shows the model that ran, and the usage dashboard records the matching model. Plan restrictions and admin blocks can override a configured choice.

For a team reviewing a billing surprise, start with those worker records. Do not conclude that the allowance was misapplied merely because the main chat displayed a first-party model. Each subagent has its own context and token usage, so delegation also needs a useful purpose: independent investigation, a distinct review, or work that benefits from a separate context.

Cursor custom models: bring your own API key

Your own API key changes who pays for supported inference; it does not remove plan, feature or provider restrictions. Plus excludes BYOK, short for bring your own key. Cursor's key documentation supports OpenAI standard non-reasoning chat models, Anthropic Claude, Google Gemini, Azure OpenAI and AWS Bedrock, within each provider's supported configuration.

To connect one, open Cursor Settings > Models, choose the provider, enter the key and save. On eligible individual plans, the provider bills those requests directly and they do not consume Cursor's included model usage or prepaid credit. On Teams and Enterprise, eligible requests still carry Cursor's Token Rate. Tab completion continues using Cursor's built-in models.

This is useful when an organization already owns a provider account and wants inference billed there. It is not proof that every model variant or every Cursor feature will use that account. Verify the specific model appears in the picker and that the workflow you need is supported before moving a team's billing assumptions.

There is also a data-handling boundary: requests still pass through Cursor's backend for prompt construction. Cursor says keys are transmitted securely and not persisted, but its Zero Data Retention policy does not apply to BYOK; the provider's policy governs. Choose the connection that matches your organization's requirements, not just the invoice you prefer.

Regional availability can narrow your model menu

A missing model can reflect provider geography as well as your plan. Cursor's regions reference says provider restrictions can remove models from the picker. Select another enabled model, or use Auto if your account offers it. A provider key works only where that provider permits access; it cannot bypass a regional block.

For a distributed engineering team, check the intended setup from each developer's region before writing a standard that assumes an identical model menu. If a model is missing, check the plan, the admin allowlist and provider availability in that order. That is a more useful diagnosis than repeatedly reinstalling the editor.

What the October change does not prove

A changed subscription menu is not evidence that GPT has disappeared from Cursor. On the verification date, Cursor still documents GPT-5.6 Sol. A social post is not enough to establish a departure or a cutoff date. Make today's workflow decision from the current catalog and your account's actual access.

Auto also does not mean “the newest model every time.” Its validated pool differs from the full catalog, and its purpose is task-dependent selection. If a specific model is part of your acceptance criteria, select it directly where available rather than hoping the router chooses it.

Finally, a larger context window or a higher effort setting does not replace a precise task. For a difficult bug, provide the reproduction, the expected behavior and the tests that must pass. More capacity can accommodate more evidence; it cannot supply missing requirements.

If your requirement is portable provider access across coding clients, the Cursor alternatives comparison addresses that separate decision. Portability is a reason to evaluate a fallback without assuming any provider has left Cursor.

Who should act now, wait, or keep their setup

Builders should change the default only when they can name the problem it solves. If Composer produces reviewable edits on routine work, keep it. If difficult tasks repeatedly stop short, evaluate Grok 4.7 with a clear completion condition. If the failure is an ambiguous specification, fix the specification first.

Team leads should inspect routing and subagents now. Confirm allowed models, visible Auto modes, underlying-model visibility and custom worker overrides. A policy that approves only the parent model leaves part of the actual workflow unexamined.

Buyers who need Claude, GPT or Gemini should rule out Plus. Legacy subscribers should wait to migrate until they understand the allowance they would lose. A working legacy account is not forced to adopt the new billing structure merely because the public plan names changed.

On Monday, take an ordinary ticket and a difficult ticket from your own backlog. Record the chosen model, settings, worker models, completed checks and usage. Keep the setup that delivers acceptable work with the least correction and predictable consumption. Those observations are more useful than standardizing the whole team on a model name alone.

Frequently asked questions

Join the newsletter for practical guides to model changes and the workflows they affect.