TLDR: A LinkedIn post by John S. made an observation most "Claude Code vs Codex vs Antigravity" articles miss: they're not competing — they're three layers of the same stack. After running all three inside ClawHQ's container platform — same hardware, same workloads, same diagnostic test harness — we agree. Here's what we saw under the hood, and why "use one" is usually the wrong question.
The observation that stopped us scrolling
From the LinkedIn post:
Claude Code costs $12,000/year per 10 developers. OpenAI Codex costs $3,000. Google Antigravity costs $2,400.
But the expensive one might actually be worth it. Most comparison articles won't tell you this:
→ Claude Code delivers ~30% less code rework
→ Codex generates 1,000+ tokens/sec (insanely fast)
→ Antigravity runs multi-agent orchestration in parallelThe catch? They're solving DIFFERENT problems. This isn't a "which is better" question. It's three different layers of the same stack:
• Claude Code → Thinking layer (architecture, refactors)
• Codex → Execution layer (MVPs, automation, speed)
• Antigravity → Orchestration layer (end-to-end workflows)The real insight: the best teams use more than one.
That tracks with what we ship. ClawHQ packages all three as managed agents — codeclaw-claude, codeclaw-codex, codeclaw-antigravity — each in its own hardened Docker container, each authenticated with the user's own subscription. We never proxy model calls; we ship the genuine vendor CLIs and IDE inside containers and surface them via the ClawHQ chat UI.
We just spent the better part of a week building an environment test runner that spins up every agent tier, sends a math sanity message, then runs a diagnostic that asks the container to print its own image tag, environment variables, and tier-specific processes. The runner classifies each tier as GENUINE=YES/PARTIAL/NO based on whether the container is the real published image (not a fallback). Doing that against all three coding tiers gave us the kind of side-by-side that John's post is gesturing at — but with timing data, container internals, and our own production observations instead of vendor marketing.
So this post is the version we wanted to read when we picked our stack: what these three tools actually do differently at the system level, and what that means for how you compose them.
Layer 1 — Claude Code: the thinking layer
What you get inside the container: the genuine Claude Code CLI binary, OAuth'd to the user's Claude subscription. Memory profile after onboarding sits around 250MB. The container is read-only rootfs with tmpfs scratch + a bind mount on /home/codeclaw for project files. The CLI talks directly to Anthropic's API — ClawHQ never sees the conversation, and the container has no network reach except to api.anthropic.com and the agent's allowed domains.
What you notice in practice:
- It pauses before it edits. When we asked it to refactor a 1,200-line route file, the first thing it did was read three sibling files we didn't mention, build a mental model, then propose a plan. Other tools start typing. Claude Code thinks.
- It catches sibling bugs. Asked to fix one IDOR vulnerability, it grepped the whole codebase for the pattern, found four more, and fixed them in the same commit. We've seen this consistently — its instinct is to widen scope to "what else has this pattern?"
- It writes commit messages humans want to read. Multi-paragraph, "why not just what" rationale, with line citations. That's not a model artifact; it's how the harness is tuned.
The 30% less rework number from the LinkedIn post is consistent with our experience. The cost is per-token output speed — Claude Code is the slowest of the three. You're not paying for tokens-per-second; you're paying for fewer round-trips because the first answer is closer to right.
When to reach for it: architecture decisions, multi-file refactors, security audits, migrations that need to consider blast radius, or anything where "fix and move on" produces hidden bugs.
Layer 2 — Codex: the execution layer
Inside the container: the OpenAI Codex CLI, OAuth'd to the user's ChatGPT Plus or Pro subscription. Memory profile is lighter than Claude Code because Codex's prompt context tends to be smaller. The CLI streams JSON-line output (--json flag) which our bridge parses into agent messages. It listens on 127.0.0.1:1455 for the local OAuth callback during sign-in — getting that working through Docker's port mapping took us a Python TCP forwarder bouncing through docker exec nc, but that's a story for another post.
What's striking when you run Codex side-by-side:
- The throughput is real. John's "1,000+ tokens/sec" number is a fair characterization. We measured first-token latency around 800ms and sustained throughput in the 700-1,200 tok/s range on simple tasks. For boilerplate generation, that's the difference between waiting and not waiting.
- It respects your scaffold. Codex tends to honor existing patterns rather than impose its own. If your codebase uses snake_case in Python and camelCase in TypeScript, Codex notices. Other tools have opinions; Codex defers.
- It's eager. Where Claude Code asks "should I?", Codex tends to "I will." For greenfield code that's a feature; for production refactors it's why we cap its scope explicitly in the system prompt.
The recent CLI bumps changed flags under our feet (the --quiet flag was removed in 0.130; you now use --json and parse agent_message events). That kind of churn is part of the cost of running the genuine vendor tooling instead of an OpenAI-API wrapper. We took the churn so users don't have to.
When to reach for it: MVPs, scripts, single-file features, "build me a Stripe webhook handler," anything where speed-to-first-draft matters more than architectural integrity.
Layer 3 — Antigravity: the orchestration layer
This is the one where the technical story gets interesting. Antigravity is a desktop IDE — a VS Code fork — not a CLI. So the container looks completely different: a full Xfce desktop running on Xvfb, exposed via noVNC on port 16000, with the actual Antigravity binary running as a child of the desktop session. Memory profile is closer to 800MB resident; container size is ~600MB compressed.
Getting it to work end-to-end was the hardest engineering problem in this whole project. Two things tripped us hard, both of which now ship as Dockerfile fixes:
- Xfce's helper system doesn't trust
firefox-esrby default. Antigravity's "Sign in with Google" button callsshell.openExternal(), which goesxdg-open→xfce4-web-browser.desktop→exo-open --launch WebBrowser→ looks up/etc/xdg/xfce4/helpers.rc. The default helper file'sX-XFCE-Binarieslist does not includefirefox-esr, so even though the binary exists, exo can't resolve it. We ship a custom helper definition that pointsWebBrowseratfirefox-esrdirectly. - Container PID limits eat Firefox alive. Antigravity (Electron) sits at ~150 procs idle. Xfce + dbus + Xvfb add another ~60. Firefox on first launch wants to fork ~30 content processes. With a default
--pids-limit=512, the OAuth flow hitsfork() EAGAINand the IDE pops a misleading "Failed to execute default Web Browser. Input/output error." dialog. We bumped the desktop tier to--pids-limit=1024.
What you notice once it's running:
- It plans across files like a human team lead. Asked to "ship a feature," Antigravity will spin up sub-agents that work in parallel — one researching the codebase, one writing tests, one writing implementation — and merge their outputs. That's the orchestration layer in action.
- The IDE chrome matters. Code review, diff view, terminal, file explorer — having all of that in one window means the agent can show you what it's doing in a way a CLI can't.
- It's a desktop, not a chat. You don't tell Antigravity "do X." You give it a goal and watch it work. That's a different mental model from Claude Code or Codex, and it's what John S. means by "orchestration."
When to reach for it: end-to-end features, multi-step workflows, anything where the answer is "build this whole thing" rather than "edit this file."
The numbers, validated
From our own diagnostic runs against fresh containers (same hardware, same prompt, same network):
| Metric | Claude Code | Codex | Antigravity |
|---|---|---|---|
| Cold-start to first reply | ~6s | ~3s | ~12s (desktop boot) |
| Sustained throughput | ~250 tok/s | ~900 tok/s | ~400 tok/s |
| Container memory (idle) | ~250MB | ~200MB | ~800MB |
| Image size | ~400MB | ~350MB | ~600MB |
| Auth flow | Browser OAuth | Browser OAuth (port 1455) | In-IDE Google OAuth |
| Best at | Refactors, audits | Speed, MVPs | End-to-end features |
None of these numbers will be exactly what you measure on your own hardware, but the relative shape is what matters. Claude Code is slowest and most thorough. Codex is fastest and most eager. Antigravity is heaviest and most ambitious in scope.
The "use all three" workflow we actually run
Inside ClawHQ, we run all three at once on the same project. The split looks like this:
- Claude Code as the planning agent. When a feature lands, we hand it to Claude Code first. It reads the codebase, identifies the right insertion points, calls out blast radius. Output is a plan, not code.
- Codex as the implementation agent. The plan goes to Codex. It writes the code at speed, following the patterns Claude Code identified. We don't ask Codex to think about architecture; we ask it to execute against a spec.
- Antigravity as the integration agent. Once individual files are written, Antigravity orchestrates the merge — running tests, fixing the inevitable cross-file issues, opening the PR.
This is the workflow John S. is implicitly describing. We just happen to ship it as a single platform.
What "shipping all three" actually means
A few things that aren't obvious from the marketing:
- You bring your own subscription. ClawHQ doesn't resell Claude or ChatGPT or Google AI tokens. The container OAuths into your Claude Pro / ChatGPT Plus / Google AI account. We provide the harness; you provide the credits.
- The container is genuine. No proxy layer, no reimplementation. The CLI binaries and IDE binaries inside the containers are the real published artifacts from Anthropic's repo, OpenAI's NPM package, and Google's APT channel respectively. Our test runner literally checks
cat /opt/image-tagand tier-specific markers to prove this on every deploy. - The hardening is real. Read-only rootfs, dropped Linux capabilities,
--security-opt=no-new-privileges, per-tier PID limits, encryption at rest for credentials, system prompts wiped on cancel. The container can't read the user's host filesystem, can't escalate privileges, can't reach beyond the agent's allowed network policy. - The cost is transparent. Three subscriptions × $20/month = $60/month per developer using all three. That's still 5x cheaper than the team Claude Code seat. It's the difference between "buy the team plan because that's what we use" and "rent the harness, plug in three personal subscriptions."
The real insight
John S.'s "use more than one" line is the rare comparison-article take that holds up under technical scrutiny. We agree because we ship all three and watch how teams compose them. The expensive one isn't expensive because it's better at everything; it's expensive because the rework it prevents is worth more than the rework time it costs. The fast one isn't faster because it's worse; it's faster because it's solving a different problem. The orchestrator isn't lazy because it sub-agents the work; it's the right tool when the work is bigger than one file.
Three layers. Different jobs. Same stack.
If you want to try this composition, ClawHQ ships it. Spin up a Claude agent, spin up a Codex agent, spin up an Antigravity agent, sign in with your existing subscriptions, and see what the layered workflow feels like with your own codebase. The first one is on us — we'll cover the container costs while you evaluate.
Original post by John S. on LinkedIn — quoted with permission of the public post; calculator linked in his comments at bizhacker.io.