As of the time of writing the best offerings are:

• Anthropic’s Claude Code (“CC”), using Opus 4.6
• OpenAI’s Codex (“Codex”), using gpt-5.3-codex with thinking level set to xhigh (i.e. extra-high)

For the sake of brevity—at the risk of slightly wrong nomenclature—if I refer to CC or Codex, I mean specificially using the model mentioned above.

AGENTS.md/CLAUDE.md

If and only if you use both Codex and CC, it may make sense to symlink CLAUDE.md to AGENTS.md and add CLAUDE.md to .gitignore so you’re not duplicating the file in the repo.

Symlink creation and addition to .gitignore will need to be done after each clone; irrespective this feels more convenient that alternatives if you want to use Claude Code (which uses CLAUDE.md) and another model (which use AGENTS.md as a kind of industry standard) in the same repo.

# Note: AGENTS.md must exist
ln -s AGENTS.md CLAUDE.md

If such a file does not exist, you can create with /init within either CC or Codex. They provide helpful context for the agent and are read automatically on load if you launch within a directory which contains one.

At the top of such file you can add:

# AGENTS.md / CLAUDE.md

`CLAUDE.md` is a symlink to `AGENTS.md`, this is intentional.

Which is best?

As the time of writing, CC is strong than Codex IMHO. Opus 4.5 (re)set the bar for comprehension, taste, and ability to handle complex implimentations on large codebases. Codex will get it done, it just seems to have a lot less flair.

In terms of speed, they feel about the same to me.

The Codex TUI feels a bit snappier to me, no doubt as a result of beign developed in Rust rather than what looks like a combo of shell scripts, Python and Typescript.

The CC agent harness seems to be regarded as leading and I have no reason to doubt this, not least as Antrophic seemed to have cracked it first.

Using in combination

I get decent results having them both in the same repo, and having CC finnish up a feature and then having Codex review it.

Usage

Quite a good idea to keep an eye on token / usage limits if you’re using subscriptions, and especially important to keep an eye on usage if you’re using an API key and paying as you go.

• /status in Codex
• /usage in Claude

For Claude, I have also used claude-monitor (https://github.com/Maciek-roboblog/Claude-Code-Usage-Monitor) and ccusage (https://github.com/ryoppippi/ccusage)

MCP servers

For getting installation instructions, https://fastmcp.me/MCP/Explore is useful e.g. to install Brave search MCP server

codex mcp add brave-search --env BRAVE_API_KEY='xyz' -- npx -y @brave/brave-search-mcp-server

where xyz is API key

Playwright MCP is very handy as it allows the agent to have control of a web browser

codex mcp add playwright npx "@playwright/mcp@latest"

With a combination of Brave web search API (good enough to pay for IMHO) MCP, and Playwright MCP, and a database to write to (can be SQLite) Codex/CC can do desktop research nicely.

Favourite prompts

• Codex seems particularly good at reviewing large codebases

  • Please thoroughly review the entire codebase or
  • Please review code this session (before a commit) seem to work well

• Updating docs

  • Please update CLAUDE.md as appropriate, including file maps

• Before a commit

  • Are we done here?

CC

You can turn on increase verbosity in CC in /settings which will provide more detailed output around what files are being edited etc.

makefile

I always add a makefile so I can easily run stuff and also as a reference to how to run things. CC/Codex can keep the makefile up to date which is very helpful

AGENTS.md

I tend to use somethign similar to the below preamble:

You have autonomy. Edit and run as needed. Do not commit. Say when done; I may ask you to run `make precommit`.

Do not use Docker unless explicitly asked. Use `make dev-local` for local development (requires PostgreSQL/Redis) or `make dev-sqlite` for standalone development (no external dependencies).

When the user doesn't specify "prod" or "production", assume they're talking about local dev.

For any new feature always implement the back-end first. The back-end api must be fully functioning. Then write and run comprehensive tests for the back-end. Only then go on to front end pages.