# Parallel AI Agents: Which Resource Limits Still Apply? > Source: > Published: 2026-09-12 00:00:00+00:00 Parallel agents still compete for the API account, machine, files and review capacity behind their work. Adding workers helps only while the task can use spare capacity. Once a shared resource is full, additional agents can produce more waiting and retries instead of more accepted output. This proposed reference separates sixteen resource checks into four scopes. It was reviewed September 12, 2026. The rows are an original design aid, not a measurement of provider limits or a claim that every application has every bottleneck. 1. 01Find the shared scope.A fresh worker may still use the same account quota and physical host. 2. 02Separate the kinds of limit.Requests per minute, concurrent jobs and spending caps constrain different things. 3. 03Measure the queue that matters.Track completed work and waiting at each resource before adding more workers. ## 01 — Practical decisionA worker count is not a capacity promise Concurrency means work happening at the same time. A rate limit controls how much work may enter over a period. A spending cap controls expenditure. An application can have free worker slots while its model account has exhausted its input-token allowance; it can also have API capacity while every local test runner is busy. [Anthropic’s rate-limit documentation](https://platform.claude.com/docs/en/api/rate-limits) provides a concrete example: organization-wide limits continue to apply even when workspace limits add up to more. Requests, input tokens and output tokens have distinct limiters. Its documentation also warns that short bursts can hit a limit despite an apparently acceptable minute average. The general lesson is to identify where usage is counted. Do not assume that another API key, child agent or repository directory creates an independent resource pool. Check the account configuration. This reference complements the [large-run orchestration story](/blog/openai-navier-stokes-10000-agent-run-orchestration-lessons) by describing the capacity questions behind any worker count. ## 02 — Practical decisionMap sixteen checks to their shared resource For each row, name the resource owner and the observation that would show contention. Keep configured capacity separate from available capacity: a stated maximum is not a reservation for your task. An unknown value is a reason to inspect configuration or run a bounded probe, not a reason to assume unlimited headroom. The table is deliberately broader than model quotas. It includes resources consumed after the model answers, such as database transactions and review. The chart counts the table’s categories only. Equal-sized groups are an editorial organization choice, not evidence that the four scopes cause equal amounts of delay. | Digital Applied proposed resource-scope reference, as of September 12, 2026. Sixteen design checks; no observed capacity values or vendor ranking. | | | |---|---|---| | Resource | Scope | What to check | |---|---|---| | Request rate | Provider | Count all calls sharing the account or limiter. | | Input tokens | Provider | Include repeated context and actual cache accounting. | | Output tokens | Provider | Include generated output from every active run. | | Spend allowance | Provider | Check aggregate spending and stop conditions. | | Worker slots | Runtime | Measure admitted and queued jobs in this runtime. | | CPU | Runtime | Inspect host contention and configured allocations. | | Memory | Runtime | Check combined peak usage and termination events. | | Disk and I/O | Runtime | Include artifacts, temporary files and write pressure. | | Working files | Shared state | Assign writers and identify overlapping paths. | | Repository refs | Shared state | Check shared branch and integration operations. | | Database connections | Shared state | Include pools opened by every worker process. | | External record writes | Shared state | Serialize or reconcile competing updates. | | Browser sessions | Coordination | Count sessions and avoid shared UI-state collisions. | | Tool admission | Coordination | Respect the downstream service’s own quota. | | Result collection | Coordination | Bound pending results and parent context growth. | | Human review | Coordination | Measure the queue of outputs awaiting acceptance. | ## 03 — Practical decisionSeparate files without promising separate machines The [Git worktree manual](https://git-scm.com/docs/git-worktree) describes separate working trees, indexes and HEAD state with shared repository resources. Worktrees can reduce accidental edits to the same checked-out files. They do not allocate separate processors, separate model quotas or independent databases. [Docker’s resource documentation](https://docs.docker.com/engine/containers/resource_constraints/) says containers have no resource constraints by default and describes explicit CPU and memory controls. A container boundary therefore does not, by itself, reserve capacity. Several isolated workers can still exhaust one host. For a parallel coding task, give each worker bounded file ownership and a known base revision. Then name the shared test or integration step. Separate branches can each pass their own checks while their combined change fails. Our [combined-changes guide](/blog/ai-coding-agent-combined-changes) covers that later acceptance boundary. ## 04 — Practical decisionUse a simple ceiling before a load test Imagine a fictional service allowing 120 model requests per minute, and a workflow using exactly three requests per task. Ignoring every other constraint, the arithmetic ceiling is 40 tasks per minute: 120 divided by three. Launching 80 workers does not turn that ceiling into 80 completed tasks per minute. This calculation is illustrative, not a capacity estimate for any provider. Real tasks consume different numbers of calls and tokens. Some wait on tools, some retry, and bursts may be constrained over shorter windows. Use the calculation to reject impossible expectations, then measure the actual workload. A proposed measurement record should include admitted tasks, finished tasks, outstanding tasks and time spent waiting for each constrained resource. Separate first attempts from retries. If retries consume the same scarce capacity, an aggressive retry loop can make the original queue harder to drain. ## 05 — Practical decisionAdmit work where capacity becomes available Use admission control: start a unit of work only when the relevant resource can accept it. This need not mean one global queue. Model calls, browser sessions and database writes can have separate limits, while the parent task retains an overall budget and deadline. When a service asks clients to wait, honor its documented retry behavior and apply bounded retry logic. A permanent spending stop is different from a temporary burst limit. For example, Anthropic documents a spend-cap response for which waiting a few seconds and retrying cannot restore access. Inspect the actual error instead of treating every 429 alike. Reserve space for cleanup and result collection in the application’s own scheduling policy. If every available worker starts fresh work, the system may have no practical capacity to reconcile outcomes or finish a parent task. The [time-limit reference](/blog/ai-agent-time-limits-reference) explains the deadlines that should bound these queues. ## 06 — Practical decisionIncrease parallelism only while accepted output improves Begin with representative tasks at a modest concurrency, then change one relevant limit at a time. Keep the workload and acceptance test stable enough to interpret the result. Record changes in completion rate, tail waiting time, failed work and total cost; a busier dashboard is not evidence of greater capacity. If a shared artifact needs a single writer, retain that constraint rather than repeatedly resolving avoidable collisions. If human review is the bottleneck, improve the evidence package or reduce low-value output before increasing generation. Different limits need different fixes. Use the blank worksheet to record a measured value, its unit, scope, evidence and checked date. Mark a row not applicable only with a reason. For [AI transformation work](/services/ai-transformation), the useful deliverable is a capacity model that explains where the next task will wait. [Download the blank worksheet](/blog-data/parallel-ai-agent-resource-limit-reference.csv). It contains the same sixteen reference rows. Observed status, evidence, unit or value, checked date and notes are blank so you can record actual findings. Use pass, fail, unknown or not applicable only after the relevant check. Evidence and scope - As-of date - September 12, 2026: sources retrieved and reviewed. September 12 is the editorial allocation. Verified event dates are stated separately. - Sources and method - Sixteen original inspection rows in four groups of four. Sources: Anthropic rate limits, Docker resource constraints and Git worktrees. - Limits - Chart counts derive from the Scope column. No load test, vendor quota survey or throughput measurement; configured values must be collected for the actual environment. ## 07 — Next stepFind the resource that the next agent would share ### Find the resource that the next agent would share Increase parallelism when there is evidence of spare capacity and independent work. If throughput stops improving, locate the constrained resource before adding more agents. A clear scope, a meaningful unit and an observed queue are more useful than a larger worker count.