Claude Code vs Cursor: What I Measured Running Both as Coding Workers

If you are searching Claude Code vs Cursor, this post will not tell you which is better, because I did not measure that. What I have is a log of bounded tasks I handed to the Cursor CLI and to Claude Code as workers, between 2026-09-30 and 2026-10-04: 9 Cursor composer rows and 20 Claude Sonnet rows. The counts, the failures and the limits of the comparison are below. A row is one dispatched task, and some rows cover several rounds or reruns.

Updated 2026-10-26. Docs quoted: Cursor CLI overview and Claude Code non-interactive mode, both fetched 2026-10-26.

What "worker" means here

A worker is an agent I dispatch with one bounded brief, and whose result I check afterwards. Cursor's CLI page says it lets you "interact with AI agents directly from your terminal to write, review, and modify code", and that print mode (-p) is for "scripts, CI pipelines, or automation". For Claude Code, the docs say to pass -p to run in non-interactive mode and that it "exits with code 0 on success and a non-zero code when the run fails". In my log the Claude rows were dispatched with claude -p or through the Agent tool. The Cursor page I fetched has nothing on usage limits or pricing, so I say nothing about either for Cursor.

The tally

In the table, "Cursor composer" means rows run through the Cursor CLI with its composer model, and "Claude Sonnet" means rows run through Claude Code on the Sonnet model. One table, from my own log. A row counts as "delivered" when I accepted its output, whether that took one round or several.

What the table does and does not say:

• The rows are not a matched comparison. The Cursor rows are code tasks: regression tests, a network retry policy, a release-flow script and its fix, and slices of a media library. The Claude rows include code, but also a written plan, browser console work and device checks. These rows do not document the same task given to both tools, so the two delivered counts are not comparable and I draw no rate from them.
• Rows can hide several rounds. Some delivered Claude rows took three rounds or four resumptions. Two delivered Claude rows needed a rerun: one run was killed at 30 minutes by the same kind of timeout, and another was cut off while waiting on a background test.
• Not every miss was the tool's. The Cursor row killed at 30 minutes hit my own Bash timeout, not a worker fault. The Claude false stall was my watchdog misreading silence, covered below.
• The date range is short. The two sets overlap on 2026-10-01 to 2026-10-03. Anything about a different week is not in this table.
• "Out of usage" is the message the Cursor CLI returned on those two rows. I did not record how much I had used, and I have no Claude row that ended that way, which says nothing without matching volume.

One older comparison, and why it is separate

On 2026-09-19 I ran a different test: composer, opencode and devin on two Python tasks with hidden grading suites. All three scored the same on the hidden tests: 16 of 16 in round one and 10 of 10 in round two, in 45 to 76 seconds. Claude Code was not in that test, so it tells you nothing about Claude Code vs Cursor. I mention it for one observation: composer's transcript showed no tool trace, because its text output arrived only when the run exited. Silence from such a run does not tell a watchdog whether it has stalled. I wrote about the watchdog side in When Your Coding Agent Hits a Rate Limit.

The Claude log has one related row. A claude -p run in text mode printed only at the end, so a watchdog flagged it as stalled after 25 minutes of quiet. The first item of the task was already committed. If you wrap either tool in a stall detector, test the detector first.

What the rows show, and no more

• Cursor composer, delivered rows: six tasks, the shortest 10 minutes and the longest 53, which was a flow script that needed one correction round.
• Claude Sonnet, delivered rows: five slices of one media library (4 to 27 minutes each), a root-cause fix that took three rounds, an Android gold-path task that took three rounds, an iOS gold-path task, an Android download task resumed four times, and an iOS background-transfer task.
• Claude Sonnet, not delivered: the hang in its own test is a code-side failure and I list it as one. The rest were a watchdog misfire, a missing login, a permission check and a cloud-device session that ran no tests.

For how I review accepted work, see Using Codex as the Read-Only Reviewer for Claude Code.

What I did not measure

No speed comparison on the same task. No token or dollar cost per row for either tool. No quality score of the code beyond "I accepted it". No comparison of the editor products. If you need a comparison, run the same bounded brief through both, log the exit code, wall time and whether you accepted the result, and count after a week, not after one demo.

Takeaway

This is a log, not a verdict. Count your own runs, write down the failure modes (usage limits, silent output, a missing login) before the run, and compare on the same task before you pick.

For a second tool's tally, see Gemini CLI vs Claude Code; for what the Claude side costs, see Claude Code pricing.