I’ve been thinking a lot about the tools we’re using for AI-assisted coding, and I’ve hit another aha moment that feels blindingly obvious in retrospect.
There’s a fundamental misalignment between Cursor’s business model and what I need as a developer. It’s not a problem with their product exactly—it’s more structural than that.
The Math Doesn’t Work
Here’s the deal: Cursor has a fixed monthly subscription price. This creates an inherent tension that I don’t think can be resolved.
For Cursor to grow as a business (which they need to do as a VC-backed company), they have two options:
- Acquire more users
- Increase their margins
The first path is fine. But eventually, they’ll need to do the second. And here’s where things get problematic.
How does Cursor increase margins? They can’t easily raise prices—developers are price sensitive and competitors exist. So the only real lever they have is to reduce costs. And the primary cost in their business? Token usage.
This means Cursor is economically incentivized to reduce the number of tokens their users consume.
Quality vs. Economics
But here’s the problem: high-quality AI-assisted development often requires more tokens, not fewer. To get the best results I need:
- Comprehensive context about my codebase
- Detailed planning and architecture discussions
- Thorough testing and code reviews
- Extensive memory between sessions
All of these quality-enhancing features consume tokens. Lots of them.
So Cursor is stuck in a bind: their economics push them to limit token usage, but my success as a developer depends on generous token usage. Their incentives directly conflict with mine.
The Alternative: Open Agents
This is why tools like Cline are so interesting. Being open-source and decoupled from a specific business model, they don’t care how many tokens you use. Their incentives aren’t distorted by needing to constrain your usage.
With Cline, I pay for the tokens I use directly from the model provider. There’s no middleman trying to optimize for reducing my consumption. If I need 100K tokens to properly understand my codebase and write high-quality code, I can use 100K tokens.
Where This Leads
I suspect this fundamental misalignment will eventually manifest in one of several ways:
- Cursor will implement increasingly aggressive token-saving measures that degrade quality
- They’ll switch to a consumption-based model (which would be better aligned)
- They’ll be outcompeted by tools with better aligned incentives
I’m already seeing signs of the first option. Cursor has been implementing various “optimizations” that reduce token usage but sometimes at the expense of context and quality.
The Hidden Benefit of Token Awareness
Here’s a counterintuitive insight: there’s actually value in being forced to think about token usage.
In Cursor, you can get complacent. You can just keep dumping context in and getting output without thinking critically about what you’re doing. The subscription model hides the real costs and tradeoffs.
But when you’re directly paying for tokens with something like Cline, you’re forced to become a better LLM engineer. You have to:
- Think carefully about what context matters
- Craft more precise prompts
- Develop better memory systems
- Build more effective workflows
Always being reminded of your context size constraints forces you to optimize your processes and hone an absolutely valuable skill: how to drive an LLM correctly.
This is a skill that will only become more valuable as AI becomes more integrated into development workflows. The developers who master efficient, effective LLM usage will consistently outperform those who don’t.
What Matters to Me
As a developer, my primary goal is shipping high-quality code quickly. Full stop.
If a tool helps me achieve this, I’ll gladly pay for it. But when a tool’s business incentives work against my goals, that’s a structural problem that will only get worse over time.
This is why I’ve been gradually moving toward Cline. Its incentives are better aligned with mine. The model gets all the context it needs, and I get better output.
The Future
Let me be clear: I love Cursor. I’m still a paying customer, and I use it regularly for small problems where its UI shines. It’s a great product with thoughtful UX, and they continue to improve it.
But I’m also realistic about the long-term trajectory. The economic gravity of their business model will always pull them toward token conservation, while the gravity of good development pulls in the opposite direction—toward comprehensive understanding and high-quality output.
For complex projects where I need deep context and comprehensive assistance, I’m increasingly gravitating toward tools with aligned incentives. The fixed subscription model for AI coding assistants creates an inherent tension that’s difficult to resolve.
For now, I’m happy to use both tools for what they do best. Cursor remains excellent for certain workflows, but I’m investing more of my development process in tools where the economic incentives point in the same direction I want to go.
I may not always be a Cursor customer, but that’s not because they’ve built a bad product—it’s because the underlying business model creates constraints that may eventually limit its utility for the kind of development work I do.
If I had anything to say to the CXO of cursor it would be this:
Keep charging me $20 a month, stop trimming the context and let me bring my own api key. I’d pay that, and keep paying it if you can match the quality of Cline. Also, if you’re not trying your asses off to hire Cline guy or Roo Code guy, you’re doing yourself a disservice.