Picking one

You have now read one lesson on each of the other three agents, and the landscape lesson explained what all four share: a model, a harness around it, tools, a rules file, and a permission system. This lesson is the decision. It is short on opinion about which model writes better code, because that answer changes with every release and would be wrong by the time you read it. It is long on the things that do not change monthly: what you already pay for, how you like to work, and what it costs to change your mind later.

Every price and product claim below was checked on 2026-09-17 against the vendor's own page, and each one links to that page. If the number on the page and the number here disagree, the page wins, and the recheck date at the bottom tells you how stale this is.

Answer five questions

Start here. Tap one answer per row. The scoring is a small table of points, written from the four tool lessons, a few dozen lines of plain code with nothing hidden. The result names a tool to start with and a runner-up, with the two answers that mattered most.

If the picker named the tool you already had a feeling about, good, go install it. If it named something else, the rest of this lesson is the reasoning behind the points, so you can decide whether the picker or your gut is wrong.

The decision table

Six factors, four tools. The first four rows are about you. The last two are about the tool. A worktree, mentioned in the Grok column, is a second checkout of the same repository in its own folder so two agents can edit at once without colliding. An OS sandbox, in the Codex column, is a wall the operating system puts around every command the agent runs, so a command cannot write outside the project or reach the network unless the sandbox mode allows it.

Read the table by row, not by column. Nobody scores four out of four on every row, and the point is to find the row you care about most. A gutter company owner in Washington who has never opened a terminal should stop at row two: Cursor, or the Claude desktop app, and the rest of the table is noise. A developer who lives in a terminal and pays for ChatGPT should stop at row three. The rows about team use and maturity only matter once someone other than you will run the agent on code that has to be right.

What each one costs, as of 2026-09-17

Three of the four are bundled with a chat subscription you may already have. Only Cursor is a separate purchase. Every figure below is a monthly price in US dollars as shown on the vendor's page on the date in the heading, before tax. Prices move, so tap the link before you decide anything.

• Claude Code. Included with Claude Pro at $20 a month or $17 a month on the annual plan, Max from $100, and Team and Enterprise seats. The free Claude plan does not include it. claude.com/pricing
• Codex. Included on every ChatGPT tier. Free is framed as enough for quick tasks, Go is $8, Plus is $20, Pro starts at $100 with a multiple of the Plus usage, and Business is $20 per user on annual billing or $25 monthly. Local and cloud tasks share one allowance per five-hour window. learn.chatgpt.com/codex/pricing
• Cursor. Pro is $20, Pro Plus is $60, and Ultra is $200 a month for individuals. Teams seats are $40 Standard or $120 Premium per user per month. Cloud Agents bill at API pricing on top, with a spend limit you set. cursor.com/docs/models-and-pricing
• Grok Build. The announcement says it is available to SuperGrok and X Premium Plus subscribers, or through an xAI API key billed per token. SuperGrok is $30 a month and SuperGrok Plus is $100 at x.ai/pricing. X Premium Plus starts at $40 a month or $395 a year on the web in the United States and includes SuperGrok access, per help.x.com.

The pattern is plain once the numbers sit side by side. If you pay for any of the three chat apps, one coding agent is already in the bill. The question is not which agent to buy. It is whether the one you already own does the job, and the only way to find out is one real task, not one more review.

Running two at once

The picker gives one answer because you should start with one. Once that one is doing real work, a second agent earns its place in a narrow role, and the person who runs this site is the example. Claude Code is the main tool: it opens first, it gets the long jobs, its settings hold the deny rules, and its hooks run the checks. Codex is the second opinion. When Claude Code finishes a change, Codex is pointed at the same repository and asked to review the diff, or is given the same task in its read-only sandbox to see whether it names the same files. Two harnesses reading the same code from different models catch things one of them misses.

The part that makes this cheap is a single rules file. The repository behind the lesson you are reading has one AGENTS.md with the real rules and a CLAUDE.md whose entire contents are the line @AGENTS.md. Codex reads AGENTS.md on its own. Claude Code follows the import. Both agents load the same build command, the same never-touch list, and the same house style, and a rule changed once is changed for both. The one AGENTS.md for every tool lesson shows the setup line by line, and it takes about a minute.

Two habits keep the pair from turning into a mess. First, one agent edits at a time. The second opinion reads and comments; it does not also change files, or you will spend the afternoon reconciling two sets of edits. If you do want both editing, give the second one its own worktree, which is exactly the feature Grok Build leads with. Second, commit before the first agent starts, so git diff shows the whole change and either agent can be asked to review it against the snapshot.

What lock-in actually is here

Lock-in is anything you would have to redo if you switched tools. For these four it is smaller than people fear, and it helps to know exactly which pieces move and which do not.

• The rules file: portable. Codex, Cursor, and Grok Build read AGENTS.md without any setup, and Claude Code reads it through the one-line import. Grok Build also reads CLAUDE.md and the rule folders of the other tools. Plain prose rules, such as run the tests before committing or never invent a phone number, work in all four. Tool-specific lines, such as prefer a named permission mode, belong in that tool's own file.
• Skills: mostly portable. Claude Code, Codex, and Grok Build all use the same shape, a folder holding a SKILL.md with a name and a description in the frontmatter and the procedure in the body, and each one scans a folder or two under your home directory for them. What does not carry is Claude-specific frontmatter such as allowed tools or a forked context, which the other two ignore. The Cursor lesson covers its scoped .mdc rules instead; check cursor.com/docs for what it loads before you count on skills there.
• MCP configuration: per tool. The servers are the same standard everywhere, so a server you set up once works in all four. The file that names it is not shared: Claude Code keeps it in its own JSON, Codex and Grok Build in their TOML settings, Cursor in .cursor/mcp.json. Each has an add command, so the re-entry is a line per server, and the token stays in an environment variable either way.
• Session history: not portable. Every past conversation lives in that tool's own folder in its own format, and a new tool starts with an empty context window. The one exception in this set is Grok Build's import command, which pulls Claude Code sessions in, one direction only. This is the real reason to put facts that never change into the rules file instead of into a conversation: a rules file survives a tool switch, a transcript does not.

So the honest lock-in bill is a settings file, an MCP list, and your muscle memory for the slash commands. The rules and the skills, the part that took thought, come with you.

How to switch later

When a real task fails, or a plan you pay for changes, switching is a checklist, not a project.

1. If your rules live in CLAUDE.md, rename the file to AGENTS.md and leave a CLAUDE.md holding only @AGENTS.md. If they already live in AGENTS.md, skip this step. Every tool in this module now reads the same rules.
2. Install the new tool with its one-line script, sign in, and ask it to list the rules it loaded before it touches anything. The Grok and Codex lessons both end with a version of that prompt. If a rule is missing, fix the file, not the tool.
3. Re-add the MCP servers you actually use with the new tool's add command, and re-create any deny rules in its settings. Claude Code's /init folds in Cursor rules, and /import copies a Codex or Gemini CLI configuration once, if you are switching in that direction.
4. Give the new tool a task you have already done with the old one, so you know what good looks like, and compare the diffs. Keep the old tool installed for a month. Nothing about running two costs you anything but disk space.

Try this yourself

One rule for the next week: no more reviews until you have run one real task.

1. Scroll up and answer the picker honestly, especially the question about what you already pay for.
2. Install only the tool it recommended. Not the runner-up, not the one from the headline. The install line for each is in its lesson.
3. Open it in a folder with a git commit in it and an AGENTS.md with three rules, start in plan mode (or Codex's read-only sandbox), and paste this:

First, list the rules you loaded for this folder and which file each came from. Then plan, but do not make, one change: add a "Request a quote" section to the home page with a name field, a phone field, and a short message box. Tell me every file you would touch and why.

Read the plan, approve it, read the diff, and decide. That is the whole evaluation, and it will tell you more than any benchmark chart will. If the tool you picked was Claude Code, or you want to see how far one of these can be set up when you go all the way, the Claude Code module is the deep dive: nine lessons from the first session through settings and secrets, with the same one-rules-file pattern running underneath.