Rate limits do not answer the budget question
Control request pace and monetary exposure separately, then make retry behavior respect both.
Two agents can make the same number of calls while consuming very different amounts of money. One sends a short classification request. The other sends a large context and asks for a long response. A request counter treats them equally even when the workload does not.
Rate limits and spend limits belong together because they constrain different dimensions of the work.
Count what the control measures
A request rate describes operations within a time interval. A token rate describes a volume within an interval. A budget describes a monetary allowance over a chosen window. Each needs a named scope: account, key, Agent, model, or another boundary.
HTTP 429 indicates that a client has sent too many requests under a server's rate policy. A Retry-After header may tell the client when to try again. That response does not, by itself, describe a dollar budget.
Reference: MDN: HTTP 429 Too Many Requests
Test equal pace with unequal cost
Imagine two illustrative workloads making ten calls per minute. Each call in the first workload costs one cent under the selected rates; each call in the second costs fifty cents. Both satisfy the same request limit while their one-minute usage differs by a factor of fifty.
The reverse matters too. A low-cost loop can flood a tool or service with requests while remaining below a dollar cap. Cost controls alone may therefore leave reliability and abuse risks unresolved. Choose a pace limit that protects the service as well as a spend boundary that protects the operator.
Respond to the actual refusal
When a provider asks a client to slow down, use bounded retry behavior and the provider's instructions. When a FlockTab tab is closed or its available budget cannot admit the next request, waiting a few milliseconds and retrying indefinitely does not solve the underlying decision.
FlockTab distinguishes velocity refusals from closed-tab and policy refusals. Preserve those reasons in the client and the console. An operator should be able to tell whether to wait, change the workload, review a policy, or explicitly authorize more budget.
Review the controls as a pair
For one Agent, record its typical calls per minute, distribution of request sizes, and spend per completed task. Test a fast loop and an expensive single request. Confirm which control refuses each case and that the harness does not turn either refusal into a retry storm.
Keep the settings independent in the team's operating notes. A change to model price may require a budget review without a change to request pace. A concurrency change may require a pace review even when the monetary allowance remains appropriate. Clear separation makes each adjustment easier to justify.
Sources checked 23 September 2026. Numerical scenarios are illustrative unless explicitly identified as provider data. Vendor limits and interfaces can change; consult the linked documentation for current details.