Cursor shipped two things this week that look unrelated and are not. Composer 2.5 dropped the Standard token rate to $0.50 per million input and $2.50 per million output. Cursor 3.5 added multi-repo automations: one developer, agents running across several codebases at the same time. Read together they are a single move, and the move is about the meter.
Two releases, one direction
The argument in the honest token bill was that the cost of running agents is real, it is rising, and most vendors price as though it were flat. Multi-repo automations are the clearest case yet of why the flat assumption snaps. A single developer used to be a single agent’s worth of throughput — one session, one repo, one stream of tokens that a human bottleneck naturally capped. Cursor 3.5 removes the cap. The same person now fans work out across three or five repositories, and each of those streams bills independently. The cheaper Standard rate is the other half of the move: it makes each individual call feel like nothing, right at the moment the product is encouraging you to make many more of them.
Single-agent ergonomics versus many-agent ergonomics
A single agent rewards a particular discipline. You think about the prompt, because the turnaround costs you attention and you are going to read the result. The economics and the ergonomics agree: be deliberate. Many-agent ergonomics rewards the opposite. The marginal cost of starting one more automation is a click, the marginal cost of a sloppy prompt is hidden inside a run you are not watching, and the interface is built to make spawning frictionless. The thing the tool makes easy is no longer “write a good instruction” — it is “start another one.” I notice this in my own behavior within a day of getting a parallel surface: I stop pruning what I ask for, because asking is cheap and I am not the one waiting.
Each developer is now a small team
That is the real shift, and it is worth saying plainly. A developer with multi-repo automations is not a person using a tool; they are a person operating a small team of workers whose output they are nominally responsible for reviewing. The meter understands this perfectly — it is counting every worker. The org’s mental model usually does not. Headcount says one engineer. Spend says five. The gap between those two numbers is exactly the subsidy that the honest token bill warned was being quietly absorbed somewhere, and parallel automations widen it on purpose, because the cheaper per-call rate is what makes the fan-out feel responsible when it is merely cheap.
The steelman, which is real
There is a genuine case for this, and it is not the marketing one. Some changes are cross-cutting by nature: a rename that touches four services, a dependency bump that has to land coherently across a fleet of repos, a migration that only makes sense applied everywhere at once. Doing that work serially is its own kind of waste — context lost between repos, partial states that compile in isolation and break together. An agent that holds the whole change in view and applies it across repositories in parallel is real leverage, and I have used it exactly that way and been glad of it. The condition attached to that praise is the entire argument: leverage only counts if you read every diff it produces. The moment the output exceeds what you actually review, you have not multiplied your throughput. You have multiplied your exposure and called it throughput.
The line that matters
So the distinction I draw is between parallel-for-leverage and parallel-for-coverage. Parallel-for-leverage is one change, expressed once, applied across the repos it legitimately touches, reviewed as one coherent diff. Parallel-for-coverage is five loosely related tasks fired off because the surface lets you, on the theory that you will sort out the results later. The first is the case the feature was built for. The second is the case the pricing quietly encourages, and it is the one that turns a developer into a rubber stamp with a higher token bill. The tell is whether you can describe, before you start, the single review you are going to do at the end. If you can, it is leverage. If the answer is “I’ll see what comes back,” it is coverage, and coverage is where both the spend and the unreviewed risk live.
What I changed
In my own setup the rule is boring and categorical, which is the only kind of rule that survives contact with a tempting interface. Multi-repo automations are reserved for changes I can state as one sentence and review as one diff. Anything I cannot describe as a single coherent change does not get fanned out, no matter how convenient the surface makes it. And I watch the per-run cost, not the per-token rate, because the per-token rate is designed to look small and the per-run cost is the number that actually leaves my account. The cheaper Standard tier did not make agents cheaper for me; it made it easier to run more of them, which is not the same thing and is sometimes the opposite. The footprint is the first half of the story this week. The second half is what that expanded footprint is standing on — the configuration files that hold the keys to every one of those parallel agents, which it turns out have been leaking those keys into public repositories the whole time. For the release details, see Cursor ships Composer 2.5 and multi-repo agents; for where this race started, the coding agent race gets crowded.
