Parallel tool calls

We’re switching from packaging knowledge to saving time. Here’s the smallest version of doing things at once.

When Claude has several steps that don’t depend on each other, it can fire them all at once instead of waiting for each one to finish.

Every time Claude reads a file or runs a command — every tool call — it’s a round trip: send, wait, get the result back. Do four of those one after another and you wait four separate times.

But if reading file B doesn’t need anything from file A, why wait? Claude can ask for all four at once, in a single move, and they come back together. One wait instead of four.

It’s breakfast. You don’t toast the bread, then after it pops start the coffee, then after that crack the eggs. You start all three at once, because none of them is waiting on another.

The catch — “independent”

This only works when the steps genuinely don’t depend on each other.

• Read four unrelated files — independent. Do them all at once.
• Read the config to find the database name, then connect to that database — not independent. The second step needs the first one’s result, so they have to go in order.

The rule Claude follows: batch what’s independent, sequence what’s dependent.

You mostly just benefit

You don’t have to ask for this — Claude does it whenever it makes sense. But knowing it happens explains something you’ll notice: sometimes Claude does five things in what feels like a single beat.

It also tells you how to help. If the things you ask for don’t secretly depend on each other, they can run together. If every request quietly hinges on the last one, everything is forced back into a line.

What’s next

Same idea, bigger unit. If independent steps can run together, so can independent subagents — each grinding on its own job at the same time.