Claude Code vs Cursor vs Codex vs Antigravity: I did the math and the token numbers surprised me
Been meaning to do this properly instead of just going off gut feeling every time my usage bar turns orange. Pulled together what I could find from benchmarks and my own week of switching between tools, and a few things genuinely surprised me.
The efficiency numbers aren't close, and not in the direction I expected. One widely cited test had Claude Code completing an identical multi-file feature task using around 33,000 tokens with zero errors, while Cursor Agent burned roughly 188,000 tokens on the same task and hit several errors along the way, a 5.5x gap for the same deliverable. Separately, other community head-to-heads put Claude Code at roughly 3-4x the token use of Codex on comparable work, so depending which pair you're comparing, the "efficient" tool flips.
Zero-shot capability and token frugality don't always come from the same tool. On raw benchmark performance, Claude Opus 4.6 sits around 80.8% and GPT-5.5 powering Codex around 88.7% on the metrics one source tracked, but Claude Code holds an 88.6% SWE-bench Verified score by another measure. The benchmarks genuinely don't agree with each other depending on methodology, which is its own lesson.
Price-per-output tells a different story than raw capability. Cursor's Composer 2.5 lands in the top three on capability index while running roughly 10-60x cheaper than the leaders, so if you're optimizing purely for $/task rather than fewest tokens per task, the ranking flips entirely.
The free tier landscape just shifted under everyone. Antigravity relaunched in May as a multi-agent suite with a new CLI and Gemini 3.5 Flash as the default model, running roughly 4x faster than Opus 4.8 or GPT-5.5, worth knowing if you'd written it off as the "free but weaker" option.
What I haven't found a clean answer to: does anyone have a real methodology for tracking cost-per-solved-task rather than cost-per-token? Token counts alone feel misleading once you factor in retries, wrong turns, and the fact that a "cheap" run that needs 3 follow-up prompts to actually work isn't actually cheap. Curious what people here are actually measuring, and whether you've settled on one agent or are still task-switching between them depending on the job.
Replies
the denominator is the problem. cost per feature moves because no two features are the same size, so the number tells you about the ticket, not the tool.
the one thats actually comparable is tokens spent after the first wrong answer. same task, same prompt, the only thing varying is how many times you had to go back. retries are the waste and they are what changes when you switch tool.
on the 5.5x, id want to know whether the cheap run needed follow ups, because thats exactly where the ranking flips. did any of the tests you found report retries at all?
Token efficiency is an interesting metric, but I think the real metric is cost per outcome. A tool that uses fewer tokens but requires multiple rounds of debugging may be more expensive in terms of developer time. I’d love to see benchmarks that measure autonomy, correction cycles, and time-to-merge rather than just token consumption.
The methodology you are looking for exists, it is just annoying to run: fix the task, vary the tool, and count total tokens until the artifact passes the same acceptance test. Not tokens per run. Tokens until done.
That one change resolves both problems in this thread. Jernej is right that cost-per-feature is uncomparable because no two features are the same size, but the fix is not a better denominator, it is holding the stopping condition constant in the numerator. And "done" has to be an external check rather than the model deciding it is finished. A test suite, a diff review, anything, as long as the tool does not get to grade its own work.
The reason nobody publishes this is that it destroys the clean headline. The 5.5x stops being a number and becomes a distribution, and the interesting part is the tail: the run where the tool commits to a wrong path early and you pay for the entire detour. My hunch is that most of the real cost difference between these tools is not median efficiency at all. It is how often each one produces a confidently wrong answer that survives a first review. That is the failure that costs you three follow-ups, and it is invisible to every benchmark in your post, because benchmarks score the final answer and not the path taken to it.
So, concretely: measure tokens-to-passing-test, report the median and the p90, and treat the gap between them as the real quality signal. A tool with a tight distribution and a slightly worse median beats one with a great median and a fat tail every time on real work. Stephanie's time-to-merge is the same instinct measured in hours instead of tokens, with the advantage that it is already sitting in your git history.