Pricing... Nuanced perspective and tips

Hello there! I feel for all the people who are disappointed with Cursor, mainly with the changes in pricing. However, I want to offer a more nuanced perspective.

  • I started a complex, agentic project in October 2024. I wanted to accelerate development, so I jumped on Cursor in Jan 2025. The project is 1758 files (git ls-files | wc -l). So only new code files, libraries are excluded.
  • Pro plan. Working 8am to 10pm every day of the week.
  • Using Cursor as a peer programmer. So, lots of chat messages and iterations, including design, architecture, and coding sessions.
  • Composer conversations average 35–50 turns.
  • Using exclusively Gemini 2.5 Flash (and occasionally Pro), with 5-10% of MAX mode.

I think that this context could potentially place me in the bucket of people that get bigger monthly bills. However, I am rarely billed anything except for the Pro plan $20.

However, I approach my use of Cursor as I do with how I architect my application.

  • I make extensive use of project rules to do context engineering. Most of the project concepts, major modules and classes, have associated project rule files, to describe the mental-model of these system components. This dramatically reduces the model need to continuously parse the project to understand its architecture, related modules, flows, etc. Using context engineering is one of the best way to increase the cache hits ratio.
  • I do a somewhat topic-focussed unit of work in each conversation. So project context is limited to 5–10 files, plus cached project rules.
  • I place extensive, Cursor generated module docstrings in each module. The model does not have to parse a lot of related files to understand what the module is doing. This is the detailed version of the mental-model level project rule for this module. No tool calls necessary to get these docstrings, and it prevents internal reboots of the LLM, which break the chain of though.
  • SRP makes each class and module mostly self-contained. Again, less context needed, less tool calls, less project rules needed to get the context of an SRP compliant module.
  • Each module exposes its interface (constants, enums, types, etc.) in a separate “*_defs.py” file. Thus, if the model needs to retrieve those, it does not need to read the full module logic (classes, utility functions, etc.) just to get a constant or an enum.
  • Again, all classes, types, enums, etc… have LLM-friendly specific docstrings. The model again has less digging to do to understand the context.

So, yes… Cursor is not perfect. But it’s the future. I started coding 45 years ago. I’ve seen the arrival of IDEs, auto-complete, refactoring, Copilot, and now AI agents. Cursor and all the others are awesome, but they are totally new and evolving products. We need to give them time, and do our part by using them properly.

Anyway, just a few thoughts… and many big thank you to the Cursor team, and all the other similar teams out there who are changing the way we transform ideas into working products, 100x faster and 100x cheaper than 30 years ago.

1 Like

I tried to automate it, but due to inexperience, I realized late that I had gone down the wrong path.

And also recently, a repository semantic search tool was added to Cursor, and I’m starting to think that Agent Docstrings was outdated even before the release of the fully stable version :smiling_face_with_tear:

Why Cursor and not Kiro or Claude ?

None of your approach seems very Cursor specific.

Seeing as you use Gemini most of the time, why not use the free Gemini Plugin in VSCode ?

People aren’t particularly annoyed at Cursor the Product, in fact they are annoyed they can’t use Cursor as much as they used to.

Which is also why Cursor the Team are pretty much ignoring everyone. Everyone that unsubs saves Anysphere money and extends their runway.

Anysphere knows Cursor is worth more than $20 a month, you know it, I know it, everyone knows it.

But when you paid a year’s sub up front and then they decide to give you 20% of what you got last week - that stings.