We cancelled Cursor. Here's the bill that did it.

This is the honest version of why we run our own LLMs - because the other version ( privacy, control, open weights, the future of the field ) is true but it wasn't the first reason. The first reason is on the receipts.

For a long while, Cursor was a non-issue: a flat subscription, plenty of headroom, and one of the better coding tools out there. Then we started building the kind of things we actually sell - automations that run LLMs constantly. Background agents overnight, pipelines that chew through whole codebases, eval loops that retry until the answer is right. Each of those is fine on its own. Together, they turned the bill from a monthly line item into a monthly decision.

The month that did it for us

Baseline first: we were on Cursor Teams - fast premium requests per seat, $384.00 USD a year - about NZ$672 at writing-time rates. Steep, sure, but it was a fixed number, and a fixed number is a budget line, not a decision. We were fine with it. What we weren't fine with is what started landing on top of it.

We exported our usage from Cursor and did what any rational software engineer does with a CSV. We looked at it.

209 billed requests in 17 active days - 187 million tokens - and about half of it ( NZ$116.02) was on-demand overage on top of the flat subscription that already covered NZ$103.95worth of usage. Half the bill was effectively a surprise, which is the opposite of what you want from a fixed-cost tool.

The standout wasn't the monthly total. It was the single NZ$14.63 request: one agent run on Claude Opus that burned 8.7M tokens chasing an answer. Multiplied by the nights when three automations are running at once, that's how a weekday lands at NZ$60.08.

And for scale: that's a lot of corned beef. A serious, sit down and think about it amount of corned beef.

To be clear, this wasn't hobby usage. Across the year to date (Jan 1 - Sep 22), Cursor suggested 231,447 lines of code and we accepted 222,907 of them - a 96% accept rate, across 137 active days, with a peak month of 83,535 suggested lines in June. That number is why this decision felt weighty: you don't easily walk away from a tool your own keystrokes depend on.

Here's where the money went, by model:

The part nobody warns you about

The bill was the trigger, but there was a second reason sitting underneath it, and it only becomes visible when you look at your pipeline of work, not your invoice.

A meaningful share of our work comes with an NDA: client data, client code, client names, none of which are supposed to leave the building. And to be fair about it: we were on Cursor's Zero Data Retention plan, which is their data-privacy setting, and a decent one. But ZDR means your code isn't trained on and isn't kept around. It doesn't mean your code stops passing through third-party servers on the way to an answer - every SaaS coding tool, including Cursor and the frontier APIs it calls, is a place where that data does leave the building. We weren't necessarily breaking the letter of any contract, but the moment a prospective client asks how their code gets processed, the honest answer is we can't promise you it never touches a third party's servers. And an honest answer like that quietly disqualifies you from contracts you'd otherwise win. That's not a hypothetical. It's a real, recurring, invisible revenue ceiling - one that shows up in a procurement questionnaire long before it shows up on a bill.

So the question stopped being "is a self-hosted LLM good enough?" and started being "when is it good enough, and how do we get there?"

"The bill was the trigger. The NDA was the reason it stuck."

What we run now

Our coding and automation work now runs against open-weights models on our own hardware: the same questions still get answered, and the data never goes anywhere. The flat, predictable running cost means an automation that would have been a NZ$14.63 request is now just... a request. Volume stopped being a fear.

And because we like our receipts to be live rather than monthly, every local run gets tracked - every model, every token, every automation - on an internal usage dashboard. This is running across our coding agents, general chat, automations, and some open-source contributions. Here's what the numbers looked like on 22 September:

…and how fast is it?

The other question we get, usually right after does it actually work?, is speed. Fair question - a local model should be judged on it like anything else. Our dense daily driver in the garage, measured the way you'd feel it (one request at a time, waiting for the first word):

The honest trade-offs

A local model is not a frontier model. On open, general knowledge and raw reasoning, the biggest hosted models still lead - and we will tell you when a problem genuinely needs them. But for the work most businesses actually need - answering over your knowledge, drafting in your voice, moving your data - a well-chosen open-weights model paired with a good RAG pipeline is most of the way there, at a fraction of the cost, with your data in the building. We pick the model, size the hardware, and prove it with evals before anyone relies on it.

Sometimes the right answer is a hybrid: local for the steady state, frontier for the hard edges. We'll design for that too - but the default now starts on our own metal, and it should probably start there for yours.

If you want it done for you

1. 01. We build the pipeline first - ingestion, chunking, embeddings, retrieval - so the model is answering from your knowledge, not its own imagination.
2. 02. We shortlist open-weights models for your task, run them on our hardware, and compare them with evals built from your real questions.
3. 03. You get a system you own: model, pipeline, and infrastructure, with monitoring, guardrails, and an upgrade path when the next model lands.

*while downing a flat white, refreshed for accuracy