I pay $200 a month for Cursor.
It is still a lot of money to spend on a coding tool. The useful explanation for why I stay is not a feature matrix. It starts before I open Cursor at all.
This is preference and familiarity as much as anything else. Other tools have moved on. I know that. I still prefer working here.
Most of the serious thinking happens first
For a new project I usually plan extensively with ChatGPT before I touch the repository.
I know I could plan inside Cursor. I choose not to. I already pay for a separate ChatGPT subscription, and I would rather burn the talky talky capacity there and keep Cursor’s usage for actual development. ChatGPT is where I am happy to ramble until the shape of the work settles. Cursor is where I want that shape to become code.
I review the plan myself. I do not take unchecked output from one AI and paste it into another as if that were a process.
Eventually a Google document becomes the master control document and development plan. Then I ask my Basecamp agent to create Kanban-style task cards for the phases. One phase can become several cards, depending on the work and who can do it. VPS setup, GitHub and deployment automation, and local Docker setup might be split so another team member can take the GitHub work. That split is useful on some projects. It is not required for every project.
Then the project comes into the workspace
I use a custom Basecamp Agent skill, not an agent CLI, to bring the control document and the relevant cards into the workspace. I also save an initial LLM context Markdown file in the workspace root. That is just how I start.
Before I ask the agent to build much, I talk the project through with it, check that it has the context it needs, and try to establish staged work rather than “generate the whole product now.” Early goals usually include repository setup and deployment automation to a test environment. Basecamp gets updated as the work moves.
The context has layers: the master control document, tailored context documents, task-specific context or prompts on individual cards, and updated progress information as things change.
The intended result is that another team member could pull the repository and continue if I go offline. That is the design of the handover process.
None of this is an exclusive Cursor feature. The same documents and habits could sit beside another editor. Cursor is simply where those habits currently live for me.
Before this, I worked between ChatGPT, a Claude terminal workflow and myself. The constant switching started to annoy me. I preferred having the coding agent directly beside the project files.
Around that period I also helped nontechnical colleagues configure filesystem MCP access for Claude. That experience did not make me anti-Claude. It reinforced how much I liked an environment that already worked with the local project without that separate filesystem setup. Cursor still uses MCP for plenty of things. The distinction that mattered to me was ordinary local project access.
I also still half-thought of GitHub Copilot as the earlier code-completion assistant in VS Code, rather than whatever agent capabilities it has now. That view is dated. I want to revisit Copilot properly before I pretend I have a current comparison.
Other tools have evolved. Agent workflows are no longer a niche party trick. Preference still matters once the category fills up.
Models are part of the preference, not a leaderboard
I used to watch new Anthropic models fairly closely. Later I used Composer and Grok options available through my Cursor setup and enjoyed having model choices. Plans change.
Model choice matters to me. So does the editor. So does the staged workflow around both. Having options inside the place I already work is part of why I stay.
The usage numbers still baffle me
Sometimes I look at the dashboard and see enormous totals. Billions of tokens overall. Roughly a hundred million in a day, if I am remembering the figures correctly.
My question is basically: what work drove that, and is there something I should do differently?
Cursor does provide analytics. I have not yet found the available information sufficient to pinpoint the cause as clearly as I would like. I also try not to treat displayed totals as if every number were brand-new, directly billable generation. The figure can be large without teaching the useful lesson on its own.
This frustration has not made me leave. It has made me more interested in better working practices.
Automated checks, then a human look at the product
When the agent finishes a task, I usually want it to commit the output. In my custom setup that triggers a hook and another skill I created for testing and checking criteria. If those configured checks pass, the workflow permits a push and deployment to the testing site.
That automation is mine. It is not a built-in guarantee supplied by Cursor, and the tests do not cover everything that matters.
Then I review the actual product on the testing site.
I often give further design feedback because generated interfaces can feel generic, or they quietly invent extra steps nobody asked for. I learned that again on a Streamlit table cleanup, and the lesson was not “never use the agent.” It was that speed and taste are different jobs.
My review questions are ordinary enough: do I like the result, does it solve the intended problem, is the interaction useful, does it introduce unnecessary steps, and what security concerns need checking?
I want to understand the product and the problem. I do not need to locate the exact line responsible for every interface element before I can decide whether the thing is any good. That is where my attention is most useful once the agent has drafted a surface.
Passing automated checks and looking at a preview also do not prove security. Security needs proper technical checks. My central contribution is direction, judgment and checking what the generated product actually does.
Why I still open Cursor
I still prefer Cursor because the agent sits next to the files, the project context stays in the workspace, and the staged process I have built around planning, cards, checks and a testing-site review fits the way I already work.
The subscription is expensive. Familiarity is part of the answer. So is refusing to hop between three tools just to get one feature written. Competitors are catching up. Usage analytics still leave me squinting at large numbers. None of that changes the quieter fact underneath: this is currently where I prefer to build.
