Claude Code vs Cursor vs Codex: Which One for a Real Project, Not a Demo

Claude Code, Cursor and OpenAI Codex are the three AI coding tools most often compared by developers and, increasingly, by the people who pay them. They are not three versions of the same thing. One is an agent you talk to from a terminal, one is a code editor with AI built in, and one is an agent that can run tasks in the cloud while you are doing something else. Which you should use depends on who is doing the work and how much of it you intend to read afterwards. This comparison is written for someone who has to choose, or has to understand what their developer chose, and it is based on the vendors' own documentation rather than on anyone's favourite.

Quick answer

If a developer is doing the work inside an existing codebase and wants an agent that reads the whole project, edits across files and runs the tests, Claude Code is designed for exactly that. If the developer lives in their editor and wants completions and chat without changing how they work, Cursor is the editor. If the work is a backlog of well-specified tasks that can run in the background and come back as changes to review and turn into pull requests, Codex is built around that model. If you are not a developer and are choosing a tool to build an application yourself, none of the three is the right starting point: they assume someone will read the output.

What each tool is, in the vendor's own words

Claude Code

Anthropic describes Claude Code as an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. It runs on several surfaces: a terminal CLI, extensions for VS Code and JetBrains, a desktop app and a web interface. The documentation notes that most surfaces require a Claude subscription or an Anthropic Console account, and that the terminal, VS Code and JetBrains versions also support third-party model providers. The centre of gravity is the terminal: you give it a task in plain language, it works through the project, and you review the result.

Cursor

Cursor is an AI-first code editor: completions, chat about the codebase, multi-file edits and, from the Premium plan upwards, cloud agents and AI code review. Its commercial model is the part most second-hand comparisons describe wrongly. According to Cursor's own models and pricing documentation, read on 9 November 2026, Cursor is sold as part of "The X Subscription", a single subscription covering Grok, Cursor and X. The pricing page on the same date listed Free, Plus at $8 per month, Premium at $30, Super at $100 and Ultra at $200, plus Teams and Enterprise plans. Free and Plus do not include third-party models at all: the documentation limits Plus to Cursor's own models (Grok 4.7, 4.6 and 4.5, and Composer 2.5). From Premium upwards, third-party models such as Claude, GPT and Gemini can be used in Cursor, but at the model's API list price, paid from prepaid credit on top of the subscription; the included weekly usage pool covers Cursor's own models only. If you expect to use Claude or GPT models inside Cursor, that distinction decides your real monthly cost.

OpenAI Codex

OpenAI positions Codex as an agent that is included in your ChatGPT plan: on the page as read in euros on 9 November 2026, Plus at €23 per month with weekly Codex usage for focused sessions, Pro at €103 for higher limits, and Business at €21 per user per month for teams of two or more seats, billed annually. It is available inside ChatGPT, as a cloud service with reusable environments per repository that keeps working after you close your laptop, as an IDE extension and as a CLI installed with npm. The page emphasises running many agents in parallel and automatically reviewing pull requests.

Side by side

Three realistic situations

Feature lists do not decide this. Situations do. These three are the ones businesses most often describe when they explain why they went looking for a developer, and the reasoning applies regardless of which vendor is ahead in a given month.

Adding a feature to an existing Laravel application

The job touches a migration, a model, a controller, a validation rule and two tests. The tool has to understand how the existing code does things and follow it. An agent that reads the project and runs the test suite, which is how Claude Code presents itself and how Codex works in the cloud, fits this better than editor completions do. Laravel has published its own tooling for this: the Laravel Boost documentation describes guidelines and agent skills intended to help AI agents write better Laravel code and lists Cursor, Claude Code and Codex among the tools it works with. The value is in the conventions the tool is given, not in the brand.

Day-to-day work on a Next.js front end

Components, styling, small state changes, a dozen edits an hour. The developer wants the AI inside the editor, suggesting as they type and answering questions about the file in front of them. That is the editor model, and it is what Cursor is. The same developer may still reach for a terminal agent for the one change that spans fifteen files.

A backlog of small, well-defined tickets

"Add an index to this table." "Rename this field everywhere." "Write tests for this module." Tasks like these can be described completely in advance, run without a person watching, and come back as changes to review and merge. That is the background-agent model Codex is built around, and the quality of the outcome depends almost entirely on how carefully the tickets were written and how carefully the results are read.

What none of them replaces

Every one of these tools produces code faster than a person can read it. That is the point, and it is also the risk. Across the projects that arrive at a developer after being built this way, the problems are consistent and have little to do with which tool was used: authorisation that was never completed, keys written where they should not be, validation that exists in the interface and not on the server, duplicated code from abandoned prompts, and no tests. A 2026 study of AI-authored commits across thousands of repositories, Debt Behind the AI Boom, found that 22.7% of the issues it tracked were still present in the latest version of the repository rather than fixed, and its authors call for stronger quality assurance in AI-assisted development.

• Someone has to read the diff. All three tools show you what changed. Whether anyone looks is a process decision, not a product feature.
• Tests are the only memory the tool has. An agent that can run your tests will catch its own mistakes. An agent working on a project with no tests will not.
• Rules files are worth the hour they take. Each tool reads a project-level instruction file. Writing one that states your conventions is the cheapest quality improvement available.
• Security is never the default. No tool adds authorisation checks, secret management or rate limiting unless asked, and often not completely even then.

Which one should you choose?

If you are a developer: try the one that matches where you already work. Terminal people tend to settle on Claude Code, editor people on Cursor, and teams with a queue of defined work add Codex for the background tasks. Using two is common and not wasteful.

If you are paying a developer: ask which tool they use and how they review its output, and listen for the second half of the answer. A developer who can describe their review process is giving you the only guarantee that matters. One who says the tool "handles it" is describing vibe coding, whatever it says on the invoice.

If you are a founder building it yourself: these tools will let you go further than you expect and then leave you with an application nobody has read. That is a fine way to validate an idea. Before the application takes payments or stores other people's data, the question becomes what it costs to have a developer fix a vibe-coded app, and how to choose one.

Conclusion

Claude Code, Cursor and Codex are different shapes of the same capability, chosen by workflow rather than by quality rankings that change monthly. Pick by where the work happens and who is watching. Then put your effort where the tools cannot: the conventions you give them, the tests they can run and the person who reads what they produce.