The Coding Ladder Says the Dial Pays. Our 52 Calls Said It Didn’t. Both Numbers Are Real.

Yesterday we published a test: 52 calls to Muse Spark 1.3, seven kinds of work, every rung of the reasoning dial, everything scored against ground truth. Our result was not close. The cheapest setting never lost — and twice, extra thinking was the failure itself. We set the fleet’s operating rule on that evidence and moved on.

Then a counter-check showed up, the way we’d want one to. BenchLeader — a third-party site that republishes benchmark results from their original publishers — carries a full rung-by-rung row for Muse Spark 1.3 on CursorBench, a coding benchmark. On that ladder, the dial pays at every single rung. If both results are real, they can’t both be the whole story. So we read the ladder the way we ran our own test: numbers first, bases stated, no vibes.

The ladder’s numbers

CursorBench, Muse Spark 1.3, as published on BenchLeader (data as of November 8, 2026; the underlying results are Cursor’s, dated September 2, 2026):

No rung regresses. Every step up solves more tasks than the step below it — +5.0 points from minimal to low, +3.3 to medium, +0.8 to high, +4.1 to xhigh, +4.1 to max. Across the whole ladder that’s +17.3 points: at max, the model solves roughly 1.7 times the share of coding tasks it solves at minimal. Ranks are among 82 model configurations with a published result on that benchmark.

What is CursorBench? In BenchLeader’s words, it’s “Cursor’s internal coding-agent evaluation”: coding tasks run inside Cursor’s agent, with the reasoning level and cost per task recorded, scored as the percent of tasks solved. Two honest labels belong on it. It is published by a coding-tool vendor — BenchLeader itself flags “harness is theirs” — and BenchLeader carries it for reference only; it doesn’t count toward their composite index. It is still the only rung-by-rung coding evidence for this model that we know of, and it points the opposite way from ours.

Our numbers, on the record

Our battery was 52 API calls to the contributor tier of Muse Spark 1.3, November 6–7, 2026, identical prompts at multiple settings, mechanical scoring. The buyer-brief judgment task scored identically at every rung — minimal got it for 776 reasoning tokens and 6.5 seconds, xhigh for 6,847 tokens and 50 seconds. Verdicts at scale: 120 out of 120 at low, 120 out of 120 at xhigh. Planning: provably optimal schedules at every rung.

And the coding cell — the one this ladder speaks to directly. Our debugging task was one function with three planted bugs. Every rung found the inverted discount logic and the rounding bug; the cheapest setting found all three. One xhigh call spent its entire 8,000-token budget thinking — 7,998 reasoning tokens — and returned an empty answer. It thought so long it never spoke. Minimal answered the same task correctly with 500 reasoning tokens.

Our published conclusion: on our work, extra reasoning bought latency, not quality, and the operating rule became low by default, with xhigh and max earned only by a demonstrated failure at low.

Both numbers are real. The tasks aren’t the same.

Put the two bases side by side and the disagreement gets smaller and more specific:

• Task shape. CursorBench runs coding tasks inside an agent — sustained, multi-step work where the model plans, acts, reads errors, and recovers over many turns. Our battery was single API calls with a checkable answer. Our one coding task was a single function, solved — or stalled on — in one shot.
• Tier and harness. The ladder ran Spark 1.3 inside Cursor in September. We ran the contributor tier through the API in November.
• Measurement. The ladder reports the percent of a task set solved. We scored one sample per cell against ground truth — a limit we printed in the original piece.

Here is our reasoning, labeled as reasoning and not as either source’s claim: the reconciler is task shape. On a short, bounded task with a checkable answer, the first think is the one that does the work; rungs above it buy patience-testing latency, and occasionally a stall. On a long agent run — hold a codebase in mind, take twenty steps, survive your own mistakes — extra reasoning has something real to chew on, and the ladder pays for it. That reading fits the anomaly we flagged in our own data: the rungs behaved like task-shaped budgets, not fixed ceilings. It also fits the limit we printed: we never tested sustained work. CursorBench did — or rather, Cursor did.

What would change the verdict

Not an argument. A run. The test that settles this for our shop is our own coding work at every rung: real work-order-shaped jobs — a written spec, more than one file, a module plus a test suite with a mechanical pass/fail — at minimal, low, high and max, in one harness, more than one sample per cell, receipts published the way the first battery’s were. If low matches max on those, our rule stands for coding too, and the ladder is a story about Cursor’s harness. If max pulls away as the jobs get longer, the rule gets a carve-out: the rung follows the length of the task. Either result is publishable. We’ll run it and print what we find.

The bottom line for an operator

If your work is short, bounded calls — extraction, checking, verdicts, drafting to spec — run low. We have 52 metered calls that say the expensive rungs buy you nothing there, and our default hasn’t changed.

If your work is a coding agent chewing through real jobs, the only rung-by-rung evidence that exists says turn it up: on Cursor’s own ladder, max solves 41.6% of tasks against minimal’s 24.3%, and every rung between them earns its step. That evidence is a vendor’s, run in the vendor’s harness, on September’s model build — hold it at that weight, not more.

The mistake isn’t picking the wrong rung. It’s running one default across both shapes of work and calling it a policy. The dial is real. What it pays for depends on the length of the job in front of it — and now there are two published result sets, ours and Cursor’s, that say exactly that from opposite ends.

Sources: BenchLeader, “Muse Spark 1.3” model page and CursorBench leaderboard (data as of November 8, 2026; CursorBench results published by Cursor via the Epoch AI Benchmarking Hub, Spark 1.3 results dated September 2, 2026). Our dial test: “We Ran Muse Spark’s Reasoning Dial Through 52 Calls. The Cheapest Setting Never Lost.” (Tygart Media, November 7, 2026), method and receipts in the Tygart-OS fact-gated fleet record on GitHub.

Want this thinking applied to your own work? Book a call with Will Tygart — 30 minutes, and we start from your receipts, not a pitch deck.