You've reached your token limit

The message is a decomposition error wearing a billing error's clothes.

The escalation always arrives in the same shape

The failure has a signature. One long-running session, one task that started in the morning and still hasn't closed, and then a wall: the limit, the cooldown, the message. The task itself usually isn't exotic. A migration, a refactor, a report pipeline. What's exotic is asking a single model to hold the whole thing at once.

The plan covers a day's work. What it doesn't cover is a day of one model holding an entire problem in its head. Reporting from April 29–30, 2026 on what one write-up called the "shipping wall" found heavy users exhausting Anthropic's Claude Max 5x plan in roughly an hour of concentrated work, and described Cursor's token-metered billing as making large-codebase work "dramatically more expensive" (dev.to). An hour. Anthropic itself acknowledged in late March 2026 that Claude Code users were hitting usage limits "far faster than expected." Not because the models got worse. Because of what a single session is being asked to carry.

Prices make the arithmetic unavoidable. As of the July 24, 2026 pricing sync, Opus 4.8 runs $5/$25 per million input/output tokens and Fable 5 sits at $10/$50, against Haiku 4.5 at $1/$5. Identical token volume, a 2–10x spread on the bill. Routing is not a rounding error; it is most of the invoice.

Here is the claim I'll defend: hitting the limit is not evidence you picked the wrong model. It's evidence you handed one model a task with its entire decomposition tree still inside it. Cursor's July 20, 2026 post ran the old and new swarm architectures on the same task, rebuilding SQLite in Rust from documentation, with the same models and the same time budget. The old swarm "spiraled and had to be paused before its second hour" (Cursor). Same model. Same clock. Different structure. That's the whole argument in one controlled comparison.

You didn't run out of tokens. You paid a frontier model to hold a filing cabinet open

Cursor's mechanism is worth quoting because it's mundane rather than mystical. When a single agent takes on a complete task, it has to "walk the entire tree itself, descending to each leaf while holding its ancestors, its current position, and the wider goal in context the whole time."

That sentence describes your afternoon. Each tool call, file read, and abandoned approach stays resident because the model has no way to know which branch it will need again. You are paying frontier rates to keep a filing cabinet open.

Cursor's read on why long single agents drift is that they face a forced choice: focus on the work in front of them and lose the bigger picture, or hold the picture and do worse on the piece. Anyone who has watched a session at hour three recognises both failure modes. The model that was crisp at 10am starts re-solving something it solved at 11.

The swarm's fix is a role constraint, not a bigger window. In Cursor's design, "a planner never implements, so its context never fills with low-level detail, and a worker never plans, so it can spend all its context on one narrow piece of work." Two agents, each with a clean context, doing half as much remembering.

The part most people skim is the part that matters for anyone not building a browser. Cursor writes that they suspect the ability to scale "comes from this context efficiency, more than from parallelism itself," and that because the efficiency is present at every scale, the decomposition helps "even on moderately sized tasks." If the benefit came from parallelism, this would be a story about running hundreds of agents and would be irrelevant to your Tuesday. Because it comes from context hygiene, it applies to a two-step task with one agent and one written-down decision.

Every model mix hit the same quality. The bills were not the same

Now the evidence, before the interpretation.

Cursor varied which model did which job. Some runs used one model for everything; others put a frontier model on planning and a fast, inexpensive model on execution. The result: "Every mix produced similar quality, but the costs varied enormously."

The specifics: four configurations, GPT-5.5 throughout, Grok 4.5 throughout, Opus 4.8 planning with Composer 2.5 working, and Fable 5 planning with Composer 2.5 working. By the four-hour cutoff, the new runs sat between 73% and 85%, against 11% to 77% for the old harness. The Grok 4.5 new run reached 80% in four hours. The Fable 5 hybrid passed about two-thirds of the suite inside the first hour. All four new configurations eventually passed 100%.

AlphaSignal's write-up of the same experiment headlines a roughly 15x lower cost for the swarm configuration (AlphaSignal). Hold both numbers next to each other: a 73–85% band on quality, and an order of magnitude on cost. The quality spread is narrower than the noise Cursor itself warns about, since "agents chose their own strategies" and some scored low for hours before a late spike.

Something interesting is buried in that spread. The architecture with the most expensive planner, Fable 5 at $10/$50, was fastest out of the gate, while Composer 2.5 executed underneath it at a fraction of the rate. Cursor doesn't attribute that early lead to any particular cause, and with one run per configuration I wouldn't lean on it hard. But it's at least consistent with the reading that the expensive model was never the part doing most of the work. It was the part deciding what the work was.

Budget the premium model per irreversible decision, not per task or per hour

What follows is my extrapolation, not Cursor's framing. They describe a coordination fix inside a swarm; I'm arguing it's a routing rule for a single human with a subscription. Cursor doesn't make that claim, and it's fair to hold me to it separately from anything they measured.

Stop routing by difficulty tier. "This feels hard, give it to Opus" collapses the moment a hard-feeling task turns out to be forty easy steps behind one genuinely hard call.

Route by irreversibility instead. Count the decisions in the task that are expensive to unwind: the schema, an interface boundary, error semantics, a dependency choice, the name of the thing everything else will import. Those are the frontier tokens. Filling in the shape, writing the tests, wiring the handlers, all of that is worker tokens, and the model tier barely moves the outcome.

This maps onto the runbook I've been using with Anthropic's lineup, and it generalises to OpenAI, Google, and open-weight models unchanged:

• If I control the unknowns and the context, Opus. I know what the decision is and I know what the model needs to see; I'm paying for judgment on a bounded question.

• If there are no unknowns and the context is settled, Sonnet. This is execution against a decided design. Paying Opus rates to type out something already decided is a donation.

• If there are only unknowns, when I can't yet name the decision let alone the options, Fable. This is the expensive part of the day, and it should be short.

The critical addition, and the thing Cursor's post makes concrete: the decision has to be written down where downstream execution can reference it. Cursor hit a failure they call split-brain design, where "two planners, unaware of each other, implement the same concept in different ways in different parts of the codebase." Their fix was that planners "make design decisions themselves rather than delegating them," plus shared design docs where "code that depends on a decision carries a compile-checked reference back to its doc."

That compile-checked reference is the load-bearing piece. It isn't the model tier that stops your cheap worker from inventing a second version of your architecture; it's the artifact the worker is forced to point at. Skip it and down-tier routing produces exactly the mess people expect.

There's a reason this shape recurs. Cursor invokes Coase: coordination costs grow faster than the work, so organisations settle into tiers of bounded units rather than letting everyone talk to everyone. A planner tier exists in the swarm for the same reason a design authority exists on your team. And because the swarm's shape "grows to cover the problem's contours" rather than imposing a fixed topology, this isn't purely a SQLite trick. Cursor reports the same design generalising to browser-building, math problems, GPU kernel optimisation, vulnerability-finding, and raising test coverage on their own codebase.

SQLite came with an oracle. Your accounts-receivable rewrite does not

Here's where I think the strongest objection lands, and it's a good one.

Rebuilding SQLite from its documentation is close to the ideal case for this result. The spec was frozen and complete: 835 pages, no ambiguity to negotiate with a stakeholder. And the grading came from sqllogictest, a suite of millions of queries with known correct answers, withheld from the swarm entirely. Every worker agent had a cheap, machine-checkable oracle. Under those conditions a weak model's errors surface within minutes. Of course model choice stops predicting quality: the verifier is doing the discriminating that the model tier would otherwise have to do.

Most line-of-business work has no such oracle. Cheap-model errors surface much later, as behaviour nobody specified, in a report someone finally read.

The infrastructure caveat is just as real. Cursor had to build a version control system from scratch because Git's coarse locks are "unworkable" at swarm volume: the browser swarm peaked at roughly 1,000 commits per hour on Git, and the new system peaks at around 1,000 commits per second. They also had to install a neutral third-party merge-resolver agent, precisely because worker agents "are bad at" absorbing each other's context and "either overwrite the other change or abandon their own." That's not a footnote. That's an admission that cheap workers cannot reconcile competing realities, and Cursor solved it with machinery you do not have. A Hacker News thread on the post (item 48982535) raises a dissenting architectural point along these lines.

And Cursor is honest that the earlier browser swarm "succeeded as a proof of concept, but fell far short of polished software." Eighty percent of a test suite is not shipped software.

The fair reading, which I'll take: decision-budgeting is real, but in this one case the savings look inseparable from the verifier, and SQLite is the only test we have. Absent a verifier, my guess is that routing down-tier doesn't reduce cost so much as move the invoice from your token budget to your own attention, which is the more expensive currency and the one with no overage option. I'd like to be shown wrong on that, but I haven't seen the run that does it.

Build the oracle first, then route

The order of operations inverts what most people try.

Notice which of Cursor's own internal applications they name: vulnerability-finding, raising test coverage, synthetic data generation. All three have a cheap automated check. I don't think that's a coincidence in their deployment choices.

The rule I'd give, including the negative case: if a task has no automated verifier and fewer than a handful of genuinely irreversible decisions, don't decompose it. The review time costs more than the tokens you save. Give it to one good model, accept the bill, and move on.

If it does have real decisions, spend frontier tokens only there, write the decision into a document the executing agent must reference, and let the cheap model do the volume. And if you can't yet write the decision down clearly enough for a worker to follow it, you haven't made it, which is why you're on hour four.

The open question is one nobody has answered, Cursor included. Each published swarm result (SQLite, the browser, GPU kernels, math) has an automated oracle. What happens to the cost curve when correctness is a judgment call is unknown, and that is where most business automation actually lives. Cursor's per-decision frontier spend isn't in the post either; the cost breakdown sits behind a footnote. If anyone has published a swarm result on a task without a machine-checkable answer, I haven't seen it.

Which leaves you one thing to check this week: in the task that blew your limit yesterday, how many decisions were actually irreversible? If the answer is two, you spent an hour of Fable-rate compute on the other thirty-eight steps, and no plan upgrade fixes that.