# Cursor vs Claude Code for vibe coding: a real head-to-head

> Source: <https://okaneland.com/proof/cursor-vs-claude-code/>
> Published: 2026-08-09 00:00:00+00:00

The Proof · AI tool

# Cursor vs Claude Code for vibe coding: a real head-to-head

- Who it's for
- Anyone choosing one $20 coding agent. Across two unlike builds they tied on capability, so choose on temperament: Cursor if you want the fastest path and will live with a ledger that says "auto"; Claude Code if you want legible builds, exact accounting, and clean automation. Either way, know what a race condition is, because on the build that had one, neither tool guarded it.
- Real cost
- Both tested on their $20/month tier, across two builds. Cursor Pro ran entirely inside its included allowance, $0 on-demand. Claude Code (Max tier on this machine, disclosed) self-reported its tokens per phase with no overage. The second build was a one-shot CLI that cost a fraction of the first. We spent nothing beyond the two subscriptions already held.

We gave each $20 agent the same founder pitch and the same pass-or-fail gates, frozen before either run started, then did it again with a completely different product to break the tie. Round one: 11/12 each, same failure. Round two: 12/12 each. Two builds, two ties. Here is what still separates them, receipts and repos included.

What's good

- Both agents shipped a working three-room studio booking app from one founder-style prompt, with zero operator nudges used out of the twelve available.
- Both nailed the two hardest correctness traps: a recurring 20:00 booking stayed 20:00 local across the October DST change, and a New-York-timezone calendar event imported to the correct Paris time.
- Both reported all four seeded defects in a messy calendar file rather than silently dropping them, and both priced four fixture bookings to the exact cent including off-peak and member-code stacking.
- Cursor was fastest to a running build and kept everything inside the $20 plan; Claude Code exited cleanly on every phase and produced a zero-dependency, single-file app that installs with nothing.
- A second, deliberately different build, a command-line log analyzer, produced 12/12 from both agents, including the hard gate: streaming a 304MB file at about 12MB of memory rather than loading it whole.
- Every claim here is checkable: both repositories for both builds, all eight transcripts, the frozen gates, and the meter screenshots ship with the piece.

Where it breaks

- Both agents double-booked the same slot under two simultaneous requests. Neither guards the race unprompted, and this is the one failure a solo founder ships to production without noticing.
- Cursor logs every run in its usage ledger as model "auto", so you cannot audit which model did your work, a repeat of what we found in the July Cursor review.
- Cursor's headless CLI hung after finishing on the build that spawned a dev server, twice, the worst over an hour, because print mode could not exit while the child held the pipe. On the second build, which spawns nothing, it exited cleanly every time.
- This is one build on one afternoon. A different pitch, or a web-app versus a data pipeline, could separate them where this one tied. Do not read a single tie as a permanent verdict.

## How we tested

We did not read spec sheets and call it a comparison. We handed each agent the same founder-style pitch, at nine at night, and asked for a whole product: a booking system for a three-room rehearsal studio in Paris, runnable tonight. Then we threw two identical curveballs at each, a data one and a money one, and ran a cold ship check at the end. Every claim either agent made was gated by tests and probes we ran ourselves, from a fresh clone, outside the tool.

Both agents run on a $20 subscription and were driven the way a subscriber drives them: through the CLI, on default settings, with a scripted operator who could send the pitch, the two curveballs, and pasted error text, and nothing else. Three nudges per phase were available; neither agent needed one. The models each tool silently chose are part of what we are comparing, not a footnote.

**The build was hard on purpose.** A booking app sounds like a to-do list, so we loaded it with four things agents reliably fumble, each reducible to a yes-or-no check. Time and daylight saving: a weekly 20:00 booking has to stay at 20:00 local when the Paris clocks change on October 25. A nasty real file: the data curveball is a calendar export in ICS format, with recurrence rules, a foreign time zone, and four seeded defects, not a tidy CSV. Concurrency: two people requesting the same slot at once must yield one booking, not two. And money that has to be exact: off-peak discounts and a member code that stack, judged to the cent against totals we precomputed.

**The gates were frozen before either agent started.** Twelve binary checks, written and locked while the fixtures were built, then run identically against both finished apps from a cold clone. No moving goalposts, no scoring by impression.

**One disclosure, because it matters here more than usual.** The operator is the same model family as one of the contestants. That is handled structurally rather than by trust: the operator’s messages were scripted and frozen in advance, the gates were pre-registered, the checks are external code, and both repositories and all four transcripts are published with this piece so anyone can re-run them. We also disclose that on this machine Claude Code ran on a Max-tier subscription, not the $20 Pro tier, so read its meter as consumption rather than as a like-for-like price.

**And we caught ourselves three times.** Our own harness was wrong before either app was: it silently followed one app’s redirects and misread a rejection as a pass, it demanded a defect be reported by internal ID when the app sensibly reported it by name, and one pricing fixture collided with an imported booking, where one app correctly refused to quote an occupied slot and our check called that a failure. All three were our errors, fixed before scoring, and we mention them because a comparison that never catches its own mistakes has not been checked hard enough.

## What both got right

Start with the tie, because it is the headline. We ran this twice, on two unlike products, and both times the two agents finished level. Round one was a rehearsal-studio booking app, and there **both scored eleven of twelve, and it is the same eleven.**

Both took one paragraph of founder-speak and produced a running app: three rooms, non-overlapping bookings, a day view, cancellation with a late flag, persistence across a restart. Both did it in roughly a quarter of an hour of real work, with no operator help.

Then both cleared the traps that were supposed to hurt. The recurring Thursday-night booking held its 20:00 local time on both sides of the October daylight-saving change, which means each agent understood that a wall-clock time and an absolute instant are different things, and stored the right one. The calendar import is the sharper tell: a rehearsal written in New York time imported to the correct Paris slot, 20:00 not 14:00, on both. Get that wrong and every touring band shows up six hours off; both got it right without being told the file contained a foreign zone.

The messy-file gate asked for something most software skips, which is a straight account of what it could not use. Both agents produced one. Cursor wrote an `IMPORT_REPORT.txt`

naming each skipped event by its calendar ID and reason; Claude Code exposed a `/log`

page and a console summary naming each by title. Between them they caught the unparseable date, the event with no end time, the duplicate ID, and the booking that ran past midnight, and neither swallowed anything in silence.

And the money was exact. Four fixture bookings, priced with a 30% off-peak discount on weekday daytime hours and a further 10% member code stacking on top, came out to the cent on both: the plain one at forty-two euro, the member-discounted Saturday at 43.20, the four-hour afternoon at 55.08, the one-hour edge case at 22.95. Vibe-coded software has a reputation for money math that is almost right. This was right.

## The one they both failed

Now the gate that turns a tidy tie into the real story.

We fired two identical booking requests at the same open slot at the same moment. A correct system lets exactly one win. **Both apps created two bookings for the same room at the same time.** Cursor’s API returned two success codes; Claude Code’s database ended with two rows for one slot. Same room, same hour, double-booked, in both builds.

This is not an exotic failure. It is the single most common concurrency bug in booking software, and the reason is visible in both codebases: each checks whether the slot is free and then inserts, with nothing stopping a second request from slipping between the check and the insert. Claude Code even wrote a comment acknowledging that a slot could be “taken between quote and confirm”, and still shipped the check-then-insert pattern rather than a database constraint that would make the collision impossible.

Neither agent is worse than the other here. Both are worse than the problem. And this is exactly the class of bug a solo founder ships to production and only discovers when two bands are standing in the same room on a Friday night, because it never shows up in casual testing. It is the strongest argument in this whole piece for reading the diff, or at least knowing the words “race condition” before you point an agent at anything people will book, pay, or queue against.

## The rubber match

One tie is a coin that landed on its edge. So we ran it again, and we changed almost everything to give the tie somewhere to break.

The second build is a command-line tool, not a web app: point it at a folder of nginx access logs and print a summary. It stresses the muscles the booking app did not. There is no database and no server, so nothing to hang on. The hard input is a 304-megabyte log file that has to be read without loading it into memory. The correctness is aggregation at scale: total requests, unique visitors, the top ten pages, the error rate, requests by hour, computed from a messy folder of gzipped and plain files with eight malformed lines seeded in. And there is a `--json`

flag, because a real tool has a machine-readable mode.

Both agents scored **twelve out of twelve.**

Both parsed the folder to the exact answer key we had precomputed and verified independently: 1,585 valid requests, 43 unique visitors, the top pages in the right order, a 19.94% error rate, and the eight bad lines skipped and counted rather than swallowed. Both added a clean `--json`

mode. And both cleared the gate that was built to hurt: on a 304MB input, each tool held its peak memory to about twelve megabytes, which is the signature of reading the file line by line instead of all at once. Neither slurped.

The second build also settled the hang cleanly. With no server to spawn, Cursor’s CLI exited cleanly on all four phases, eight clean exits in a row. That narrows the earlier finding from “Cursor’s CLI hangs” to the precise and fairer “Cursor’s CLI hangs when the build it runs starts a long-lived server.” The rubber match earned Cursor that correction.

So the tie held, on a second product that shares nothing with the first but the discipline we tested it under. Twenty-three of twenty-four gates each, across a booking app and a log pipeline. At that point the fair reading is not that we failed to find a winner. It is that, at $20, on the work a solo builder actually hands an agent, there is no capability winner to find.

## Where they actually differ

If the gates tie twice, the choice comes down to temperament, and the two agents have opposite ones.

**Cursor is the fast, opaque one.** It reached a running build first, and it kept the entire job inside the $20 plan with nothing billed on demand. But its usage ledger records every single run’s model as `auto`

, so after the fact you cannot tell whether your architecture was decided by a frontier model or a cheap one. We flagged this in July and it is unchanged. It also front-ran the data curveball: the calendar file was sitting in the project folder, and Cursor found it and wired up an importer before we had said a word about it, which is initiative you will sometimes want and sometimes not.

**Claude Code is the legible, tidy one.** It exited cleanly on all four phases, reported its own token use per phase in exact numbers you can audit as it works, and chose a stack with no dependencies at all: one Python file, standard library only, nothing to install. It also showed better judgment on one edge we did not gate for, refusing to price a slot that was already booked rather than quoting into a conflict. Where Cursor acts, Claude Code checks.

The sharpest operational difference is not in either app; it is in the tools, and the rubber match pinned it down. **Cursor’s headless CLI hung after it finished, twice, on the first build.** Both times the build had launched its own dev server to check itself, and the print-mode command then could not exit while that child server held the output pipe open, once for over an hour before we killed it. On the second build, which starts no server, Cursor exited cleanly all four times. So the trap is specific and real: if you script Cursor in a pipeline where the thing it builds spins up a server, expect to kill it yourself. The interactive editor sidesteps this, and Claude Code exited on its own in all eight phases across both builds.

## Real cost

Both agents were tested on their $20 tier, and neither cost a cent beyond the subscription.

Cursor Pro ran the whole build inside its included allowance: the dashboard showed 2.4 million tokens for the session and zero on-demand spend. Claude Code, on this machine, was on a Max-tier subscription rather than the $20 Pro plan, which we disclose because it makes the meter a measure of consumption and not of price; across four phases it self-reported roughly ten thousand input, seventy-five thousand output, and 4.2 million cache-read tokens, with nothing billed above the plan. The two meters are not the same unit and we do not pretend they are; each is shown as its own tool reports it.

For a solo builder the practical read is simple. On this build, both plans absorbed a full product build without overage. The Claude Code weekly cap, which we mapped in [our limits study](/study/claude-code-limits/), is the ceiling to watch if you run several of these a day; Cursor’s included-token pool is the equivalent number on its side, and its promo-free simplicity is a genuine point in its favor.

## What this cannot tell you

This is two builds on one afternoon. They were chosen to be unlike each other, a stateful web app and a one-shot data pipeline, and that widens the finding beyond a single lucky draw. But both still favor backend correctness over front-end polish, both were greenfield rather than a large existing codebase, and both were an evening’s work rather than a month’s. A third kind of brief could still separate these two where our two tied, and we would rather you knew that than oversold two rounds as the last word.

It also cannot referee the parts of each tool we did not drive. We ran both through their command-line agents, because that is the like-for-like surface and the one an automated builder uses. Cursor’s Tab completion and inline edit, and Claude Code’s interactive session, are typing-native and outside our harness, exactly as our [Cursor review](/proof/cursor/) said of that tool alone. If your day is mostly in the editor rather than firing off whole tasks, weight this accordingly.

And it is a snapshot. Both tools updated in the weeks before this test and will again; we ran both on the same afternoon on current builds to keep it fair, but a race-condition fix or a ledger change on either side could move a line on the scorecard next month. The repos and transcripts are published so you can re-run the gates against whatever ships next.

## The verdict

**Situational, and closer than the discourse.** Across two unlike builds, at $20, Cursor Pro and Claude Code are the same tool wearing different clothes: both competent enough to ship a real product from a sentence, tied at 23 of 24 gates, with no single decisive edge between them. We ran the second build specifically to crown one of them, and it refused to be crowned.

So choose on the thing that actually differs, which is character. Take Cursor if you want the shortest path to a running build and can live with a meter that will not tell you which model did the work, and you are not scripting it in a pipeline where the CLI can hang. Take Claude Code if you want builds you can read, accounting you can audit, and an agent that checks before it acts, and you have watched the weekly cap.

But the finding that outlives the matchup is the one they share. On the build that had a concurrency trap, two different frontier agents both shipped software that double-books a room. The gap that matters in vibe coding is not Cursor versus Claude Code, which two rounds could not separate. It is between what either agent hands you and what is actually safe to ship, and closing that gap is still your job.

One email, when there's something worth sending

## Get the research in your inbox.

No fixed schedule, no filler. You get an email when we've tested something, run the numbers, or found a tool worth your time.

Free. Double opt-in, unsubscribe in one click.

Running one of these on the $20 plan? [Compare notes in the forum ↗](https://community.okaneland.com)

## Sources

Every outside quote in this review was re-fetched from its source before we used it.

| Source | Link |
|---|---|
| The full test kit for both builds: all four repositories, all eight transcripts, the frozen gate scripts, the answer-key verifiers, and the timing logs with meter reads (2026-08-09). |
|