Your Agent's Bottleneck Is the Rate Limit, Not the Model

§1The failure nobody puts in the demo

Every agent demo shows the agent succeeding. It reads the files, makes the change, reports back, and everyone claps. What no demo shows is the agent forty minutes into a long job, hitting the usage cap, and stopping. For anyone running agents unattended, on a cron, overnight, across a fleet, that is the failure mode that actually costs you. Not a wrong answer you can catch and correct. A stopped one, half-finished, at 3am, with nobody watching the terminal.

We run eight agents on one small server. Several of them sit on flat-rate subscription seats, which means they share a usage window, and when a big job runs into the reset boundary the process simply ends. The work is not wrong. It is just not done, and no human is awake to notice or restart it. So when the Claude Code changelog rolled past this month, the releases we actually cared about were not the ones about the model getting cleverer. They were the plumbing.

§2Auto-continue on the usage limit

The one that matters most is a single line in v2.1.234: Claude Code now continues your session automatically when a claude.ai usage limit resets; turn it off in /config. In plain English: instead of the run dying when you hit the cap, it waits for the window to reset and picks up where it left off.

If you only ever use an agent by sitting in front of it, this reads as a minor convenience. You would have come back and retyped anyway. But the value is not in the supervised case, it is in the unsupervised one. For an unattended job, hitting the cap is terminal: the process exits, the task is stranded, and the cost is a morning spent working out how far it got before you can even restart. Auto-continue turns a hard stop into a pause. The job survives its own rate limit.

The honest limit: it does not make anything faster. "Continue when the limit resets" can mean waiting hours for the next window, so this buys you completion, not speed. And it is tied to the claude.ai subscription cadence, not something you tune. But for overnight work, finishing slowly beats stopping dead every time.

§3Forking, so context stops being expensive to copy

The second thread is forking. /fork landed back in v2.1.212 and copies your current conversation into a new background session. The newer part, on by default from v2.1.232 and sharpened in v2.1.235, is that a subagent_type: "fork" child inherits the full conversation and the prompt cache.

The cache line is the whole point. Normally, spinning up a helper agent means paying to rebuild its context from nothing: re-reading the same files, re-establishing the same state, re-explaining the task. A fork that inherits the cache starts warm. You do not pay again to re-read what the parent already read. That changes the economics of branching: you can spin off a throwaway to try a risky edit, run a quick experiment, or hand a reviewer the exact state you are in, without the context tax that used to make people avoid it. Cheap branching is what makes "try it three ways and keep the best" a default rather than a luxury.

§4Agents that can reach each other, across machines

The third thread is coordination. Cross-session SendMessage shipped in v2.1.224: sessions can message each other, on any of your machines. v2.1.232 added @-mentions, so one session can name another and reach it directly.

This is the difference between a pile of agents and a fleet. Before, if two agents needed to coordinate, you built the channel yourself: a queue, a broker, a shared table, some glue you now own and maintain. A message primitive that spans machines makes that a built-in rather than a project. Ours run across a VPS and a couple of remote boxes, so "reach another agent wherever it lives" is exactly the wire we had been hand-rolling. It is still name-addressed and point-to-point, not a real message bus, so delivery guarantees are on you. But the primitive existing at all removes a standing pile of plumbing.

§5Plumbing beats intelligence for unattended work

Step back and look at the same fortnight's headlines. A frontier model previewing inference at fourteen times the speed. An open 27B that codes near the frontier on a laptop. Both real, both genuinely useful. Neither one fixes the thing that actually kills our jobs, which is the job stopping. A cleverer model that dies at the rate limit is still a dead job.

That is the pattern worth taking away, and it is not specific to Claude Code. For unattended, long-horizon agent work, the bottleneck is almost never the model's intelligence. It is continuity: surviving the rate limit, carrying context to a helper without paying to rebuild it, reaching another agent without writing a broker. When you evaluate agent tooling for a fleet, score it on those, not on a benchmark. Can a job survive its own usage cap? Can you branch context without rebuilding it? Can two agents talk without you writing a queue? Those three decide whether a fleet runs while you sleep. A higher benchmark score does not.

Our own position is almost funny: we are on 2.1.228, which means we already have the older halves (/fork, cross-session SendMessage) and are exactly one upgrade short of the good halves (auto-continue, cache-inheriting forks, @-mentions). So the action this Note produced is not a grand rebuild. It is a version bump. The least glamorous release of the month is the one we actually needed.