Codex and Claude Code are both tools I use heavily, costing me a massive number of tokens. Here are some notes I’ve jotted down over this period.
1. First, Codex
Product Form: I Use the Desktop App Most Often
Codex currently comes in three forms: CLI, desktop app, and cloud. Personally, I use the desktop app the most.
The advantages of the desktop app are clear:
- The left sidebar is great for multi-project parallel development — you can have several projects open at once and switch between them.
- Built-in Chrome control and Computer Use mean some simple, repetitive daily tasks can be handed off to it.
- Compared to a TUI, the GUI is more comfortable to read and less tiring for extended sessions.
Good Value, but Context Window Is a Limitation
The Codex model is still relatively good value for money. However, the latest 5.5 only has a 256K context window — a major pain point. For slightly larger projects or more complex requirements, it frequently triggers context compression.
What It Excels At, and What It Doesn’t
Not great at frontend. In frontend development, even when stacking multiple skills, Codex still performs worse than Claude. So for any UI-related tasks, I unhesitatingly hand them over to Claude — no second thought needed.
Strong at logical reasoning. Codex shines when it comes to logical reasoning work. In scenarios where business processes are well-defined and the logical chain is clear, it works both quickly and accurately. That’s where it’s most reliable.
A Few Annoying “Bad Habits”
1. It Likes to Guess
Of course, Claude has this issue too, but Codex does it more noticeably. I generally have to add a rule in AGENTS.md like “Don’t fabricate facts out of thin air,” but the effect is still limited.
So one important lesson is: you have to provide Codex with good, effective context. If the context isn’t sufficient, it will make things up.
2. It Especially Likes Writing Fallback Logic
Codex is particularly good at — and particularly fond of — writing fallback logic. When it runs into a problem it can’t solve, it won’t stop to ask you; instead, it writes a bunch of fallback code to “cover up” the issue. The result is code that looks like it works, but is stuffed with fallback branches that will never be triggered in normal flow. The code becomes unreadable.
My approach is to always add this line in the prompt:
When you encounter a problem you can’t solve, or when context is missing, stop and ask me. Don’t keep writing on your own, and don’t use fallback logic to mask the problem.
That single line saves a lot of review headache later.
3. Hard to Understand
The common complaint that “Codex’s output is hard to understand” still exists in the latest version. By the way, Claude has started showing a similar tendency recently, though not as severe.
2. Now, Claude
First Impression: Expensive, but Truly Powerful
My first impression of Claude? Expensive.
But the latest Opus 4.7 is genuinely strong, especially in two areas where it stands alone:
- Architecture design: It sees the big picture and knows how to make trade-offs.
- Frontend UI and interaction design: Currently unmatched.
For anything involving “how to structure,” “how to decompose,” or “what the interface looks like,” I basically hand it all to Claude. You can clearly feel that Claude has a broader knowledge base and worldview.
Product Form: I Use the CLI the Most
Claude also comes in three forms: cloud, app, and CLI. But personally, I use the CLI more.
Partly it’s historical — I’m used to it. I’ve tried the web version too, but honestly the web interaction experience is still average.
Another very important reason is:
Claude Code CLI Is My “Universal Agent Carrier”
Claude Code CLI is more than just an entry point to Claude for me. It’s actually a carrier for connecting various other large models — a universal agent shell.
I connect models like Kimi and Zhipu into Claude Code via environment variables. That way:
- The toolchain and workflow are unified.
- I can switch between different models flexibly depending on the task.
- I don’t need to build a separate calling environment for each model.
Just this alone makes Claude Code CLI very hard to replace in my daily work.
3. On “Handing Long-Term Goals to AI”
Finally, I want to touch on a topic that’s been discussed a lot recently: handing long-term goals to AI and letting it run all the way on its own.
When building demos, this approach looks cool. One prompt, and in minutes you get something that runs — great for a demo.
But for a production-grade project, this path isn’t reliable yet.
The reason is quite simple: when you yourself don’t clearly understand the basic implementation principles of the project, you simply cannot provide a good prompt or precise context to the AI. Then the gap between what the AI produces and what you actually want is almost inevitable — and it grows larger over time.
No matter how powerful the tool is, the precondition remains: you need to know what you want, and roughly what it should look like.
AI is an amplifier, not a replacement. If you have a clear picture in your mind, it can help you draw it fast and well. If your mind is fuzzy, it will just magnify that fuzz by ten and hand it back to you.