Claude Code hit the usage limit mid-task. Don’t start over

At 00:42 on October 4, Claude Code stopped three of my multi-agent runs at once. These were tasks from my job: two agents per run, one to build and one to check. Five of the six agents failed with the same message. The five-hour session limit was reached and would reset at 01:10.

At 01:18 I asked the agent to pick everything up. Three minutes later it reported where each run stood: one fix committed and waiting for its check, one task four-fifths done, one new stage mostly written. Each run continued from the edits its agents had left in their folders, most of them not yet committed. Nothing restarted from zero.

I knew to look because of September. When a multi-agent run dies, from a usage limit, credits running out or a service failure, its result can say nothing was built. The working folder often holds most of the work.

What “nothing was built” looked like

On September 23 a run of three agents kept stalling. An attempt counts as stalled after three minutes with no progress. Each agent got six attempts, 18 in all, and every one of them stalled. That took 4.4 hours and 1.16 million tokens. The result was three empty slots: {"built":[null,null,null]}. Right after the run, other requests to the service were timing out too. Most likely the service was failing, not the task.

Then I looked at the folder. Each attempt starts over in the same folder, and each one had written something before it stalled. Together they had left 1,354 new lines in seven files. No function was defined twice, the new rules were actually called, and all 666 tests passed. Only new tests, a measurement and the report were missing. The check took about a minute and a half.

A restart from zero would have thrown that away and spent the same tokens again. Instead a “finish” job ran on top of the folder: six agents, 81 minutes, 1.49 million tokens. Its measurement on real data showed that the three new rules left in the folder were far too strict: they threw out 187 records. After the fix, they flag 9. Found work still needs every check a finished job gets.

Check the folder before you restart

After any failed run, my agent goes through this list:

1. What changed, and how much. git status and git diff --stat in the run’s folder. Is there anything to save?
2. Duplicates. Several attempts can each write the same function. A name defined twice means they collided.
3. Wiring. Is the new code called, or only declared? A rule nobody calls does nothing, and the tests still pass.
4. If it’s whole, finish it. Rerun the task with one paragraph added: “The code in the folder is your predecessor’s. Add tests that fail first, measure, report.”
5. If it’s a mess, save it, then roll back. Save the changes as a patch outside the folder first. Never delete them: the patch may be the only copy.

Restart only what failed

Claude Code can resume a stopped run. Finished agents return their saved results, and the rest run again. The catch is the order. As Anthropic’s docs explain, a failed agent runs again, and so does every agent that started after it, finished or not.

On September 25 a limit stopped a run of ten agents: five did the work, five checked it. Two checks failed. I resumed, and all five work agents came back from the cache. But a failed check stood first in line, so three checks that had already finished ran again, close to 200 thousand tokens each. That was close to 600 thousand of the roughly one million tokens the resume used. I saw the finished checks running and asked the agent whether it had restarted correctly. It hadn’t.

The rule now: if failed agents sit before finished ones, don’t resume. Run a small separate job for the failed agents only, and take the finished results from the run’s log.

When the failure is at the end, a resume is the right tool. On September 28 the usage credits ran out at 00:26, in the middle of a long run. Nine agents had finished. The tenth was building a design prototype with about 120 screen states. The result said the prototype didn’t build, but in the folder it was almost done: four screens had a single word alone on a line at phone width, and the last checks hadn’t run. I changed only that agent’s prompt to “This is a continuation: here are the files and the log, finish it”, plus my newest design notes. It was last in line, so all nine finished agents came from the cache.

The same night another agent died without committing anything. Its edits were still in its folder, so we saved them as a patch of 151 lines, and the new run applied it as its first step. Since then every agent that writes code commits after each logical step. The rerun of that job ended with ten commits.

All five failures, side by side:

Make the next failure cheap

• Commit after every logical step. A crash then costs one step, not the whole job.
• Name the number of agents and a token estimate before launch. For happymonday.ua, a Ukrainian career platform, I estimated a research run of 9 agents at 1.2–1.4 million tokens and 30–40 minutes. It used 2.29 million tokens and about 70 minutes. Now I budget 250–300 thousand tokens per agent.

• Know which limit is close. The five-hour window and the weekly limit are separate: plenty of the week can be left while the window is gone. Settings › Usage shows both. On September 30, twelve minutes after I launched one review run, it had started ten agents and used about 1.2 million tokens. At that pace the five-hour window would not have lasted the run. I stopped it and worked in a single thread until the window reset.

Newer versions of Claude Code can pause a run at a usage limit and continue after the reset. The session has to stay open, and the reset has to come within 24 hours. A weekly limit can be further away, and a service failure is not a limit at all. So the folder check stays.

How many agents a task deserves is a separate question. I wrote about it in When 50 subagents is the wrong answer.