If I open 10 threads and hit my account's daily cap, will the work already running in those 10 threads get interrupted or lose data?
No data loss. Per official documentation, a thread paused due to hitting the allowance enters a waiting state — it isn't terminated or cleared. Its files, tool state, and conversation history are all preserved, and once the allowance is restored (whether from the next day's reset or you adjusting your plan), the thread automatically resumes right where it paused, with no need to start it over.
That means hitting the 200 cap actually causes a time delay, not a loss of work output. What's more practically relevant to you is the time gap — a result you expected to get today now has to wait until the allowance resets to continue. If your task has a genuine time pressure attached (a deliverable that absolutely has to ship today, say), that delay itself is a risk worth factoring into your planning — don't assume everything's fine just because nothing gets lost.
Why is review-burden complexity "close to quadratic" rather than simply scaling linearly with thread count?
If every thread were completely independent, with no relationship to each other, review burden really would be linear — however long it takes to review the first diff, the second takes roughly the same, and total time is just that per-diff time multiplied by thread count. But that's usually not how it actually works: if several threads are subtasks split off from the same larger goal, they likely have implicit relationships to each other — two threads might both touch the same shared logic, or one thread's underlying assumption might get invalidated by what another thread changed.
In that situation, you can't just review each diff independently and call it done — you also need to spend extra time cross-checking whether these changes, taken together, actually conflict with each other. That cross-checking workload, in principle, needs to happen once for every pair of threads — and as thread count grows, the number of pairwise combinations grows faster than the thread count itself. That's exactly why complexity ends up close to quadratic rather than simply linear.
If my subscription plan has enough allowance and I'm nowhere near the 200 cap, does that mean I can safely open a lot of threads at once?
Not entirely — having enough allowance only means you technically can run many threads simultaneously; it doesn't mean doing so is the best choice for your actual workflow. Allowance is a relatively objective, quantifiable limit, but review burden is a limit along a different dimension, and the two don't cancel each other out: even with more allowance than you could ever use, the number of diffs you can actually review carefully is still bounded by how much time and focus you personally have to spend on review each day.
The more practical way to judge this is treating "do I have enough allowance" and "can I actually review all of this" as two separate questions, each needing its own answer — only worth opening a larger number of threads at once when both answers are yes. If allowance is sufficient but review can't keep pace, the usual result is several sets of changes piling up unreviewed, which actually increases the risk of a real problem getting merged into the main line without anyone noticing — a risk that doesn't automatically disappear just because your allowance happens to be generous.
In practice, is there a concrete way to decide whether a task is actually suited to splitting into multiple parallel threads?
A fairly practical criterion is checking first whether the task itself can be split into subtasks that are genuinely independent of each other, with non-overlapping scopes of change. Anthropic's own example — retiring the same deprecated endpoint across three separate repositories: API, web, and mobile — is a good fit for splitting, because the three repositories are inherently independent; threads naturally don't interfere with each other, and reviewing just means confirming each repository's change is correct on its own, with no need to cross-check for conflicts between them.
Conversely, if the task is something like "try several different optimization approaches on the same core piece of logic within the same repository," this can superficially be split into multiple threads too, but because the scope of change overlaps heavily, review actually takes more effort — comparing which version is better, checking for contradictions between them. This kind of task is usually better handled sequentially, one thread at a time, rather than fanning it all out in parallel at once — blindly chasing "more threads means faster" can actually slow overall progress down.
Since Claude Code Projects relaunched in its redesigned form, Anthropic set a clear hard ceiling: up to 200 new threads per account per day, across all of your projects combined. Plenty of coverage mentions this number, but usually just in passing, without further discussion — what this cap actually means in practice, and under what circumstances you'll hit a different bottleneck before ever hitting this number itself.
This cap is calculated per account, per day, summed across all projects — not "200 per project individually." If you have several projects running at once, thread count draws from the same shared allowance. That means if you have three projects all using threads heavily at the same time, your allowance runs out faster than if you were running just one project, and you have to make tradeoffs across multiple projects yourself, rather than each project getting its own separate 200 slots.
Per official documentation, a thread that pauses due to hitting a usage limit doesn't fail or disappear outright — it waits, and resumes automatically afterward. That means what this 200 figure actually causes is delay, not lost work. In practice, if your usage pattern is opening a lot of threads intensively within a single day, you're more likely to hit this cap first. If your usage is spread across several days, opening a few each day, you're unlikely to actually run into this line.
200 is a hard account-level ceiling, but in practice most people hit a different limit earlier — the usage allowance built into your own Pro or Max plan. Because every thread is a full Claude Code cloud session, it consumes allowance at the same rate as opening a single session normally would; it isn't cheaper just because it happens to be a thread under a project. That means opening 10 threads at once to run in parallel consumes roughly the same allowance as opening 10 independent sessions simultaneously. For most subscription plans, this consumption rate makes itself felt well before the 200 cap does — 200 is more of a theoretical ceiling than the first wall most people actually run into.
A bottleneck even easier to underestimate than allowance is the human cost of the review process itself. Previously, you only had to look at one thread's result. Now, if you've opened 5 or 10 parallel threads at once, what you need to review is 5 or 10 independent diffs, each with its own execution logic and its own potential problems. And because each thread works independently based on its own assumptions, if a task wasn't split clearly enough, you might end up with several results built on overlapping or conflicting assumptions — review complexity doesn't scale linearly with thread count, it's closer to quadratic, because you also have to cross-check whether these several results actually contradict each other.
The more practical way to judge this isn't checking how much allowance you have left, or how far you are from the 200 cap — it's asking yourself first: if all these threads report back results at the same time, do I actually have the time and energy to carefully review each one, one by one? If the answer is no, then even with plenty of allowance and nowhere near the 200 cap, opening too many parallel threads simply creates a backlog of review work you can't keep up with — and the actual net benefit ends up worse than opening fewer threads and genuinely reviewing each one carefully.