There is a recurring argument on X where someone posts a side-by-side of Claude Code, Codex, and Cursor (or, one year ago, Windsurf), and three hundred people fight about which one is better.
I have been an early user of Cursor, testing it basically since it was founded. Now, however, I do most of my work in Claude Code, running in a terminal, avoiding fancy IDEs. If I have to look at the code, I basically do it either by just looking at the GitHub's PRs or through Cursor.
My point is that the reliance on one specific IDE is what creates these fights and forces people to keep switching from one to another. Some people like to build workspaces and routines through years, and these constant switches are lowkey an entry cost that they are not willing to pay. And it makes sense.
So here I am going to explain how I have developed immunity to the Codex vs Claude Code debate and I just use both in the same place: Claude Code. But first, let me explain why I left Cursor, because Cursor does indeed have a very complete catalog of models, right?
Why I left Cursor
As I was saying, Cursor lets you pick between Claude, GPT, Gemini, even their own (Composer). But Cursor does not own those models. It sits between you and the API, deciding how the models are gonna see your prompts, what parts of your codebase the model actually sees and, in the default mode, which model handles the request. You get a polished experience in exchange for handing that layer to someone else. That is a reasonable trade-off for most tasks and people, though. It just stopped working for me. When Anthropic released Claude Code, I tried it and found I could do things that were awkward or just more difficult to achieve in Cursor.
This happened around a year ago, when Anthropic was the only company offering a CLI for their models. OpenAI and Google followed with Codex and Gemini CLI, but by then I had already built my workflow around Claude Code, and Claude Code was just ahead of the curve. Cursor eventually released their own CLI in January 2026, which is model-agnostic too. Fair enough. But at that point I had already wired everything around Claude Code, and switching for switching's sake is exactly the habit I am trying to avoid.
Now, many people prefer Codex to Claude Code. I want to explain why I think that debate misses the point.
The setup
Claude Code, Codex, and Gemini CLI all run in a terminal. They can call other programs, read files, write files, run shell commands. But many users are not comfortable in the terminal, especially on Windows (I don't blame them). That is why all three companies also released IDE extensions. This creates a problem: if you use only one provider's extension, you are tied to that provider.
When Anthropic changed their rate limits, or when OpenAI did the same a few days ago, people locked into one tool felt it immediately. The fora filled up with "Claude Code is dead, switching to Codex" and then, a week later, the reverse. The same thing happens every time a new model drops, which is now every few months. If your entire workflow lives inside one provider's IDE, every policy change or model release is a disruption.
There is also a practical cost to the IDE extensions. They automatically send extra context to the model (open files, editor diagnostics, text selections) that the terminal CLI does not. That means more tokens per turn, which adds up. Anthropic's own documentation confirms that the VS Code extension only supports a subset of the commands and skills available in the CLI. And there are open reports of the extension consuming noticeably more tokens than the terminal for the same work. You can still use skills in the extension, but not all of them, and you are paying more per interaction for the convenience of a GUI.
So what if you could use all of them from the same place? That is what I do. I use Claude Code as an orchestrator that dispatches tasks to whichever model is best suited for the job, or whichever model I want a second opinion from.
The way this works is through something Claude Code calls "skills". A skill is just a markdown file with instructions and a shell command. My /gemini skill tells Claude to take whatever question I give it and send it to Gemini's CLI for an answer. /codex does the same thing with OpenAI's Codex. I have one for OCR, one for committing code, one for opening a persistent session with another model. None of them are longer than a page. Claude Code reads the skill, runs the command, and brings the result back into the conversation. I stay in one terminal, but I am talking to three or four different models depending on the task, and they can talk to each other through me.
What this looks like in practice
Last week Google released gemini-3.1-pro. My /gemini skill was still pointed at 2.5-pro. The first instinct of someone that hasn't build these skills would be: "Oh now I need to open Gemini CLI and switch to it if I want to use the new model of Google".
Instead, I told Claude, in three sentences, that there was a new model and to update the skill. It grepped my skill directory, found the old model ID in two files, checked the new one against Google's docs (Claude Code's /chrome skill is fantastic), updated both files, and searched the rest of my config for stale references. Done.
Writing these skills is not a one-shot thing, though. I don't even write them from scratch myself. Who knows better the format Claude prefers: Claude or me? You write what you want, ask Claude to format it, ask it to try it, realise the instructions are ambiguous or the output format is wrong, tweak it, try again. My /gemini skill went through maybe five or six versions before it reliably did what I wanted. It is closer to tuning a recipe than writing a program. But once a skill works, it just works, and you stop thinking about it.
Why I care about this as a researcher
I have seen many people that still use LLMs by pasting a question into ChatGPT and copying the answer into a notebook. That is fine for quick lookups or brainstorming. But the thing that changed my work was not a better chat interface. It was realising that I could have a model run things overnight, OCR my PDFs in the background to build my personal library, and get a second opinion from different models before I wake up. I do versions of this regularly. It just works.
The bottleneck here is not the models. The models have been good enough for a while. The bottleneck is the human who still treats them like a search engine instead of like a research assistant that can actually run things. If you only ever ask a model one question at a time through a browser tab, you are using maybe five percent of what it can do for you.
I am not saying everyone should use a terminal. But I find the objections funny. When computers were invented, nobody complained that you had to type commands into a black screen, that was just how you used a computer. Then windows and a mouse arrived and people forgot the terminal existed. Now that the terminal is useful again for a different reason, the same objections come back: "it's unfriendly", "it's intimidating".
The same pattern shows up with the models themselves. The people who refuse to delegate a regression to Claude Code because "then students won't learn how to write a regression in Python" are making the same argument that was made against calculators, against Stata's point-and-click menus, against every tool that ever lowered the cost of doing something hard. It usually turns out that the tool makes more people able to do the work, not fewer.
Maybe in two years there will be an IDE that does all of this with a nice interface. If that happens, great. But right now, the terminal is where you get the most control, and control is what matters when you are running real research through these systems. And if you are one of the people complaining that Claude Code burns through your tokens too fast, check whether you are using the VS Code extension or the terminal. You might be paying for context you never asked the model to see.