Skip to content
OTFotf
All posts

Cursor pricing in 2026: what individual and team builders actually pay

D
DaveAuthor
7 min read
Cursor pricing in 2026: what individual and team builders actually pay

If you are choosing an AI coding tool for a real product, Cursor pricing is easier to understand when you separate the advertised plan from the usage your team will actually create. The current public page lists a free Hobby tier, a $20-per-month Individual tier, a $40-per-user-per-month Teams tier, and custom Enterprise pricing. The higher Individual and Teams variants are presented as plan options, but the public page does not show every price or usage allowance in its readable text.

That last detail matters. Do not build a budget from a screenshot, an old comparison article, or a number copied from a different billing cycle. Start with the current Cursor pricing page, then estimate how many people need the editor, how much work they will delegate, and which controls you need around the codebase.

What does Cursor cost right now?

The public pricing page currently describes these four groups:

  • Hobby: Free. The page lists limited Agent requests and access to Composer, with no credit card required.
  • Individual: $20 per month for the displayed entry plan. The page lists extended Agent limits and access to additional models, cloud agents, MCPs, skills, hooks, and Bugbot on usage-based billing.
  • Teams: $40 per user per month for the displayed Standard option. Teams adds centralized billing and administration, shared team context for cloud agents and automations, usage analytics, team privacy controls, and SAML/OIDC SSO.
  • Enterprise: Custom pricing. The page lists pooled usage, invoice or purchase-order billing, SCIM seat management, repository and model controls, audit logs, service accounts, and priority support.

The page also shows a Premium option beside Teams and Pro Plus and Ultra beside Individual. It does not expose a separate numeric price for those variants in the text we can verify. Treat them as selectable plan options, not as prices you can safely repeat from an older article.

Which plan fits a solo builder?

The free tier is useful for evaluating the editor and its agent workflow. It is not a promise that a production project can be completed without a paid plan. Limited requests can be enough for small experiments, but a serious build usually needs a repeatable workflow: inspect the repository, make a bounded change, run the checks, review the diff, and then continue.

The displayed $20 Individual plan is the first obvious budget line for a solo builder who uses the tool regularly. The important question is not whether $20 is affordable in isolation. It is whether your project is structured well enough that each agent session produces a reviewable change instead of a long, ambiguous rewrite.

Before paying, write down three numbers:

  1. How many features you expect to ship this month.
  2. How many focused sessions each feature needs.
  3. How much time you will spend reviewing and testing each result.

If the answer to the third question is “almost none,” changing plans will not solve the problem. A cheaper plan with narrow tasks is often a better fit than a larger plan used as a substitute for repository conventions.

For practical prompt structure, see five prompt patterns for shipping real features in existing codebases. The useful pricing decision comes after you know how you work, not before.

11 production screens. Login, database, payments — all wired.

The SaaS Dashboard Kit ships everything already connected. Nothing to set up. Live demo at saas.otf-kit.dev.

See the live demo

What does Teams add for a small product team?

Teams is not just an individual subscription multiplied by the number of developers. The displayed $40-per-user-per-month Standard price buys a management layer around the coding workflow. The official page names centralized billing and administration, usage analytics, team-wide privacy mode, access to shared team context, and SSO among the additions.

That is relevant when several people touch the same product and you need answers to operational questions:

  • Who has access to the repository?
  • Which users are active members?
  • Is usage rising because of a launch, a new project, or an unbounded task?
  • Can a departing contributor be removed without leaving billing in an unknown state?
  • Does the team need SSO or a shared privacy policy?

The Teams setup documentation says billing is per active user and that added or removed users are charged pro rata for the remaining time, subject to the plan’s billing behavior. It also documents optional domain matching and SSO setup. Confirm the current terms before you model a large team, because billing rules are more specific than a simple “price times headcount” calculation.

A ten-person team using the displayed Standard price would produce a simple list price of $400 per month before taxes, discounts, or any usage-based charges. That arithmetic is not a forecast of your invoice; it is just a starting point. Keep seats, optional features, and usage-based products as separate lines in the budget.

How should you compare the plan options?

Use a small decision table rather than a feature-count race.

Choose Hobby when: you are testing the editor, learning the workflow, or making occasional small changes.

Choose Individual when: one person owns the product and needs regular agent-assisted implementation without team administration.

Choose Teams when: multiple contributors need centralized administration, analytics, shared context, privacy controls, or SSO.

Talk to Enterprise when: procurement, pooled usage, SCIM, audit logs, service accounts, or formal access controls are requirements rather than nice-to-haves.

The higher options may be sensible for a heavy user, but do not assume that a higher allowance fixes an unclear task. Set a policy first: one issue per session, explicit files in scope, a required test command, and a human review of the diff. That policy makes any plan easier to evaluate.

What should be in your monthly budget?

Put Cursor in the same spreadsheet as the rest of the product work, but do not confuse the editor subscription with the cost of shipping the application.

Your budget should have at least these rows:

  • editor subscriptions by active user;
  • any separately billed agent, review, or usage-based feature;
  • hosting and database usage;
  • model or API usage outside the editor;
  • monitoring, email, and payment fees;
  • the time required to review generated code and repair bad assumptions.

That final row is the one teams omit. Generated code still needs tests, migration review, authorization checks, and deployment verification. The subscription can reduce typing; it does not remove those responsibilities.

A production-oriented starting point helps keep that review work visible. Use the web app template production checklist to inventory authentication, data handling, deployment, and operational gaps before you decide that more editor capacity is the answer.

A safer way to trial Cursor pricing

Run a two-week trial with one real feature, not a toy prompt. Record:

  1. the task description;
  2. the files the agent changed;
  3. the number of review cycles;
  4. the checks that passed or failed;
  5. the time from first prompt to deployed result;
  6. any usage or billing warning shown by the product.

Do not measure only generated lines. A short patch that passes the checks and ships is more useful than a large rewrite that creates a second week of cleanup.

At the end, compare the result with the plan you paid for. If one builder is the bottleneck, evaluate an individual upgrade. If coordination, access, and billing are the bottleneck, evaluate Teams. If neither is the bottleneck, keep the cheaper plan and improve the work boundary.

The practical answer

Cursor’s current public pricing is straightforward at the entry points: Hobby is free, Individual starts at $20 per month, Teams starts at $40 per active user per month, and Enterprise is custom. The displayed page also includes higher Individual and Teams options whose numeric prices are not exposed in the text we can verify.

Use those numbers as starting points, not as a claim about your final bill. Match the plan to the people using it, separate subscriptions from usage-based services, and test the workflow on a feature that has to survive review and deployment. The best plan is the smallest one that supports a disciplined loop from request to tested diff.

If you are comparing starting points for a product rather than just an editor, browse the OTF production-ready kits. The useful comparison is not more generated code; it is how much application setup your agent has to invent before the first real feature can be reviewed.

Sources

ai-toolsarchitecturecursor
OTF SaaS Dashboard Kit

Ship the product, not the setup.

  • 11 production screens — auth, billing, team, analytics, settings
  • Real database, payments, and login — all wired on day 1
  • AI configs pre-tuned so your agent extends instead of regenerates