Claude Code Can Now Run 1,000 Agents at Once. Nobody Stops You From Getting the Bill.

Anthropic relaunched Projects in Claude Code this month, and the number everyone repeats is 1,000 agents per run. Sixty-four concurrent threads, one shared filesystem, a central controller coordinating the parallel work, and a default lifetime cap of 24 hours per run. Coverage landed October 17 via Renascence, which wrapped product framing around technical details from Anthropic’s October 9 release and an October 12 workshop.

The number that should actually change how you work is smaller and quieter. Claude writes its own orchestration program now. You don’t hand it a workflow diagram with roles to fill in. It generates the plan itself: spawning subagents, splitting work into phases, retrying whatever fails, combining results at the end. Orchestration has become inference-time computation: the model designs the workflow’s shape and then fills it in.

I’ve run enough parallel agent setups to respect that sentence and fear it a little. A system that designs its own workforce will occasionally design one you didn’t ask for.

What actually shipped

Projects in Claude Code is now a single workspace where multiple agents run concurrently with shared memory, shared goals, and shared files. A controller sits above the parallel threads and keeps them from colliding.

Three details from Anthropic’s documentation matter more than the marketing:

• Agents share a filesystem but do not message each other directly. Coordination happens through the controller and the disk, not agent-to-agent chatter.
• Runs scale to 64 concurrent threads and up to 1,000 agents total, capped at 24 hours by default.
• Claude generates the orchestration program itself, including how work gets phased and retried.

Read those together and a picture forms. This is closer to a distributed scheduler than a prompt library. The prompts are almost the easy part now.

The part Anthropic is blunt about

Anthropic’s own docs are refreshingly honest about the failure modes, and most coverage skipped them.

First: active threads can collectively exceed your nominal budget. Each thread looks reasonable on its own. Sixty-four of them, each nudging the limit, is a different arithmetic. Your budget is not a ceiling the system enforces for you; it’s a number the aggregate can quietly walk past.

Second: approval gates must be requested explicitly. They exist, which is good, but nothing in the default flow forces you to set them up before a big run. You have to want them.

Third: visibility into large runs stays limited. When you’re running dozens of threads, knowing what any single agent is doing at a given moment is genuinely hard. The docs admit this rather than pretending a dashboard fixes it.

So the three controls that decide whether multi-agent work is a productivity win or an expensive mess are budgets, approval gates, and termination conditions. Notice what’s not on that list: prompt wording. We spent three years optimizing the request. The leverage has moved to the guardrails.

When 64 threads beat one careful agent

Parallelism pays off under two conditions: the tasks are genuinely independent, and verifying an output is cheaper than producing it. A migration audit across 40 separate modules. Competing drafts of the same landing page. Running five research threads and synthesizing them. These split cleanly and check cheaply.

It fails when every step depends on the previous one, or when checking the output costs as much as generating it. Deep debugging is often serial — the next hypothesis depends on what the last test revealed. Nuanced long-form writing tends to need one consistent voice, and merging 12 thread-authors into one argument costs more than writing it straight through. And anything where a wrong early decision poisons everything downstream needs a careful single agent, or a human, holding the wheel.

The teams getting value from this aren’t the ones launching the most agents. They’re the ones who can say, in one sentence, why a task splits.

What to do now

If you’re opening Claude Code Projects this week, run it like this:

1. Start with two or three threads on a real task, not sixty-four. You learn where the seams are before the bill teaches you.
2. Set the approval gates before the first big run. Explicitly. This is the one control Anthropic tells you to ask for in advance, so ask.
3. Define a termination condition in plain language: what output, checked by whom, ends the run. “Until it’s done” is how you meet the 24-hour cap from the wrong side.
4. Budget per run, not per month. The aggregate-exceeds-nominal problem only shows up at the level you’re not watching.
5. Keep one careful single-agent pass for the final review. A lone agent reading what the fleet produced catches things the fleet never will.

For anyone building on AI, framework quality has moved into resource allocation, termination, and observability. The model handles the workflow design. What separates a good setup from a bonfire is everything around the model: the spend ceilings and the kill switch. That was true of distributed systems forever. It just became true of prompting too.

Anthropic shipped a system where one sentence launches a workforce. Spend your care on the part that decides when the workforce goes home.