Why I moved my AI-ITOps and coding work from Claude to Cursor

If you have read anything here you know I have been running everything through Claude Code for months. It built my VCF environment, I built tens of coding projects with it (my GitHub), and most of what I have written this year came out of those sessions.

Now I have moved two of my workstreams to Cursor: AI-ITOps and coding. Everything else stayed on Claude.

You will also notice in this post that I started running some of my agents on Tanzu Platform rather than on a laptop. That move is a bigger story than a tooling switch and I will write it properly in another post. It matters here only because it is what makes some of what follows possible.

One thing to state up front: this post is not an endorsement nor a review of Cursor or of Claude Code. It is me sharing my experience with both.

Cursor gives access to many more models

This is the headline. Cursor is not tied to one provider, so I pick the model per task rather than getting whatever the tool ships with.

That matters, I learned, because most ITOps work is not hard reasoning. It is volume. Read this log, rename these things, walk this config, run the same check across four hosts, do it again because something changed. Paying frontier rates for that is waste. Dropping to something cheaper and faster for the grind, while keeping the good model for the parts that actually need thinking, is a real structural advantage.

So I can use Gemini, Grok, Codex, Opus, Sonnet, even Fable. But interestingly I am now mostly using auto mode.

I went in sceptical. Letting the tool pick the model sounded like a way to get ineffective results.

In practice it has been one of the most effective parts of the switch, and it is specifically where the cost savings come from. It routes the easy work cheaply and escalates when the task warrants it, and I have stopped thinking about it, which is the highest compliment you can pay a feature like this.

I moved from the $120 Claude subscription to the $20 Cursor one and it has not stopped me yet. As the work grows I will probably need the $60 tier, but the difference in cost effectiveness is very noticeable. I completely rebuilt my VCF environment end to end and it did not move the usage needle, to the point where I started doubting the usage reporting.

Another thing worth mentioning, and that also deserves its own post, which is that I route also plenty of the work to my local models. A lot of the newer work runs on gpt-oss:120b on the DGX Spark in my own environment, now exposed to Tanzu Platform as an OpenAI-compatible model with its own service plan, and work can route to it from Cursor. And Cursor does it really well using its Tanzu worker (see next section). So the choice is not just cheap model versus expensive model. It is also local versus hosted, on data that has reasons to stay on my own hardware.

I also have to admit that Musk is a genius for buying them, because auto mode defaults to Grok a lot and Grok does a great job.

The agents are tidier

Another point in Cursor’s favour is that the way it arranges workers and agents is simply more organised than what I had assembled myself with Claude. I know where things are running and I can see what each one is doing.

The structure is a headless worker that you push wherever you need Cursor to operate, and you manage all of it from the client. You can spin up multiple agents per worker, which makes the whole thing simple to run.

The clearest example is that a Cursor worker is a thing I can run on my own platform. agent worker start on a Cloud Foundry cell, easily: outbound HTTPS to Cursor, tool calls executing on the machine that runs the CLI. It is a workload like any other workload, scheduled and supervised by the platform rather than by a shell script I wrote and have to remember.

With Claude Code the model is different. The whole thing runs where you need the work done, and the session is the unit. If I want Claude Code operating in three places, that is three sessions on three machines, each with its own state, each needing something to launch it and something to notice when it dies. In my case that something was a dispatch service I wrote myself, plus a tmux socket, plus a set of rules about how sessions get started and recovered.

To be fair, a good part of that clumsiness is my own doing. I built my orchestration layer by hand over months and it grew the way hand-built things grow. But part of what you buy in a product is that someone already made those decisions and made them consistently.

The day to day difference is that switching between projects is now a client-side action rather than an infrastructure one. I am not asking myself where a session lives, whether it is still alive, or which machine I need to be on to reach it.

What stayed on Claude, and why

Everything personal. All my writing cleanup, and I hope Claude was not offended helping me clean up this post. And this website, which is still built and published through Claude Code.

That is a different job and it fits comfortably in the $20 Anthropic subscription. Writing is not volume work, and the website is not an estate to be operated. Both are cases where I want the strongest model in the loop, and where I already have history that is worth something.

The same holds for the hard technical problems. The certificate investigation I wrote about, three layers deep with a wrong answer sitting in memory that had no command line to read it from, was not a volume problem. That was a thinking problem. Claude owns the model and it shows on exactly that kind of work.

What it comes down to

Most ITOps work is busy work. Sequencing, checking, repeating, verifying across four hosts instead of one. It is not intellectually hard, there is just a lot of it, and the tool that wins that category is the one that is cheapest and best organised at volume. Some of my coding work falls into the same category, and it is on Cursor now for the same reason.

Thinking work is the opposite. Fewer tokens, higher stakes per token, and model quality is the entire product.

That local models post is coming, because I am building an environment that runs some agents on Tanzu and some on VKS, as a proof of concept for what agentic work should look like in an enterprise. Stay tuned.

That’s what the lab is for.