No configuration option exists for rate-limiting LLM API calls

[Devendraxp]

I read the complete documentation and there is no option available for limit per minute model call. As I use it with free providers like groq cloud or even with openai, my agent hit per minute limit and with a error 429, it stops working.

[seratch]

Thanks for sharing the idea! We do not have immediate plans to add a built-in rate limiter or customization options like that. We generally recommend defining an upper limit on your app's agent runs within a given time window. This is usually easier to manage outside of this SDK. Either way, even if this SDK provided a feature to detect bursty model traffic, you would still need to monitor overall traffic trends on your side (e.g., storing the data in your database and share the data across your app servers).

Usage data already provides relevant signals (e.g., number of model calls and token usage) that you can use for your rate-limiting logic, so you can leverage those metrics to control the pace of processing. If this SDK should (and can) provide more granular information to support this, we are happy to enhance it for that purpose.

[Devendraxp]

When we run result = await run(agent, 'xyzxyz..');, we lose all control over our agent. It hits the LLM with back-to-back API requests until it reaches its rate limit, at which point it stops working. Even after waiting 1–2 minutes, it will not restart automatically.

Somewhere in the documentation, I read that it should wait incrementally 1s, 2s, 4s, 8s, etc. but in my case, it doesn’t. I asked my teammates and my local WhatsApp community, but no one had any idea why.

Additionally, any custom limits applied externally seem to be useless.

If I’m missing something, please let me know,it would help many developers.

[seratch]

Enabling to retry the same model call in an exponential-backoff fashion could be indeed useful for the use case while it may not save all the errors if your budget for the model provider is not sufficient. As a workaround, utilizing ai-sdk's auto-retry or signal handler may be helpful: #894 (comment) In the long run, this SDK may introduce a built-in retry mechanism, but I cannot tell when it may be avaialble.

[Devendraxp]

Thanks for the context. However, the team should make the run() function more configurable. Once invoked, we lose all control, everything is handed over to the agent. If it hits a rate limit, it simply crashes instead of pausing and retrying after a minute.
This makes the Agent SDK impractical for even moderately complex tasks like browser automation, where multiple steps and API calls are inevitable. A built-in retry mechanism or rate-limiting configuration isn't a "nice-to-have", it's essential for production use.

[wsk-builds]

I took another pass against current upstream/main, and I think this issue now has two separate concerns that are worth splitting:

1. Retrying transient model failures such as 429s
2. Proactively rate-limiting / pacing model calls before a provider limit is hit

For (1), current main now has opt-in model retry support:

• modelSettings.retry.maxRetries, backoff, and policy
• retryPolicies.providerSuggested(), retryPolicies.retryAfter(), retryPolicies.httpStatus([429]), etc.
• docs in docs/src/content/docs/guides/models.mdx under "Model retries"
• examples in examples/basic/retry.ts and examples/ai-sdk/retry.ts

That should cover the "if a model request receives a retryable 429 / retry-after / provider-suggested transient error, wait and retry the same model attempt" part, assuming the app opts in with a retry policy.

For (2), I think the original title still describes a different feature: an SDK-owned rate limiter that controls throughput before calls are made. That is more than retry/backoff. It would need a clear design for where limits live (Runner vs Agent vs model provider), whether limits are per process or shared across app servers, whether the budget is request-based or token-based, and how it interacts with long-running multi-turn agents. Since Usage already exposes request and token counts, apps can currently build external pacing around those signals, but the SDK does not appear to provide a global queue/budget manager.

Suggested next step: can a maintainer confirm the intended scope here? I think this could either be:

• closed/narrowed if model retries are sufficient for the reported 429 failure mode, or
• retitled to something like "Add SDK-level model request rate limiter" if the desired feature is proactive request pacing, or
• converted into a docs/example follow-up showing how to combine modelSettings.retry with an application-level limiter.