▶ YouTube Summaries

← All summaries
ForrestKnight#▶ Watch

Opus 4.6 vs Codex 5.3 hands-on comparison

2026-02-10 Tue ⏱ 22 min forrestknight

Hands-on first impressions of Claude Opus 4.6 and GPT-5.3 Codex, released within about 30 minutes of each other. Instead of benchmarks, Forrest runs both models head-to-head on the same real-world tasks across a TypeScript codebase (his Jetty link platform), the multi-million-line Rust codebase of the Zed editor, and Java projects, using each model's native harness (Claude Code and Codex CLI) inside Zed via the Agent Client Protocol. Verdict: both are good incremental upgrades; Opus 4.6 produced better, more correct code in most tests, while Codex 5.3 was consistently faster and much cheaper.

Setup and announcements

  • Both vendors claimed the Terminal-Bench 2.0 agentic-coding lead; Codex 5.3 overtook Opus 4.6's score 27 minutes after its release. Forrest distrusts benchmarks ("they can be played") and prefers real-codebase tests.
  • Opus 4.6 highlights: more careful planning, longer sustained agentic tasks, 1M-token context window (up from 200K), better self-review/debugging, and new agent teams — coordinated Claude Code instances with shared tasks, inter-agent messaging, and centralized management (not tested here, but close to a pair-programming-agents idea he had tweeted a day earlier).
  • GPT-5.3 Codex: merges GPT-5.2 Codex's coding with GPT-5.2's reasoning, ~25% faster; OpenAI's first model instrumental in creating itself.
  • Test rig: Zed (sponsor) with ACP, so each model runs through its own vendor-optimized harness; Zed's "follow agent" mode shows edits inline in the buffer, and diff review is done in Zed.

Test 1: TypeScript bug (Jetty, issue 21)

  • Bug Opus 4.5 could never fix: decorative bubbles spawned in a background tab freeze and pile up in the DOM until the tab regains focus.
  • Opus fixed it, Codex didn't. Ironically Codex's code looked cleaner — textbook reactive React with state-driven useEffect — but it relied on onanimationend for cleanup, and browsers freeze CSS animations in background tabs, so the callback never fires.
  • Opus went imperative: one useEffect, one closure, setTimeout (throttled but still firing in background) to manage element lifetimes. A hack by React standards, but the option that works. Root difference: one closure that sees everything vs two useEffects that can only communicate through a render cycle that never happens while the tab is hidden.

Test 2: TypeScript feature (password-protected links)

  • Broad prompt; both got the full flow right: bcrypt hash on create, hash stripped from API responses (frontend only sees a hasPassword boolean), rate-limited verification endpoint, click tracking after unlock, Cloudflare worker falls through to TanStack to render the password UI.
  • Codex over-engineered verification: bcrypt + SHA-256 + plaintext fallback with constant-time comparison, in a brand-new codebase where every password is bcrypt. Not wrong, but defends against hash formats that don't exist. It did, however, refactor duplicated link-resolution logic into a shared helper — good code hygiene Opus skipped.
  • Opus: one-line bcrypt.compare, slightly more polished UI, and an optimistic update of hasPassword so the UI doesn't wait for a re-fetch.
  • Called a near tie: Opus simpler, Codex better organized.

Test 3: Rust bug (Zed, issue 46178 — Git panel indentation)

  • Git panel indent hardcoded at 16 while project panel indent is configurable. Both models, in plan mode, converged on the same approach: have the Git panel respect the project panel's indent setting.
  • Implementation diverged: Codex used a clone/double-=unwrap= pattern that panics on a missing value — directly violating the repo's agents.md guideline "avoid functions that panic like unwrap" — while Opus used unwrap_or with a default.
  • Codex was much faster but its build errored (fixed after feeding the error back); Opus compiled clean first try. Codex also made an unrelated, out-of-scope change to selections_collection.rs.
  • Both solutions "work as intended" per the letter of the issue, though the visual result isn't quite what one would hope. Net: Opus slower, but better code, first-try compile, and no guideline violations.

Test 4: Rust feature (configurable letter spacing in Zed)

  • Three parallel implementations on separate worktrees: Codex CLI, Claude Code CLI, Claude Code in Zed. All three worked, including negative spacing.
  • Codex created wrapper methods around existing shaping functions: no existing call sites touched, clean non-breaking PR (a recurring Codex 5.3 trait), but now two versions of every method exist and every future caller must choose.
  • Opus added the parameter directly: more churn in the PR, cleaner after merge since every caller is explicit. Opus also handled line wrapping as spacing grows; Codex missed that but had better surrounding polish (tests, docs). Forrest prefers the Opus solution as more complete.

Java and overall verdict

  • Java tests (one small, one large private codebase) showed the same pattern; Opus 4.6 produced better Java code, while Codex 5.3 actually fixed a TypeScript issue that Opus 4.5 had repeatedly failed on.
  • Opus 4.6: better code in most/all tests; noticeably fewer back-and-forth rounds (tasks that took 2-3 exchanges now one-shot); but slower than both 4.5 and Codex 5.3, and less personable — "like talking to that really good developer who isn't very social," where 4.5 felt like a sociable senior.
  • Codex 5.3: consistently faster, very strong on TypeScript, obsessed with clean non-breaking PRs, and far cheaper — he never hits limits on the $20 ChatGPT Plus plan, vs the $100 Claude Max plan for Opus.
  • Takeaway: both are incremental improvements, nothing revolutionary — and that's fine; there's little the previous generation couldn't solve, the new models just solve it with less back-and-forth. Pick by the kind of development you do.