Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Feature Request]: Global model call rate limiting across all agents [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#62255•Fetched 2026-04-08 03:07:08
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
zepooddzepoodd
Participants
zepooddzepoodd

Fix Action

Fix / Workaround

\n## Problem Description\n\nUsers with tiered API pricing plans (e.g., MiniMax Starter: 600 calls / 5 hours) need a way to limit the overall model call rate across all active agents to avoid triggering rate limits.\n\nCurrently, OpenClaw provides:\n- cron.maxConcurrentRuns: Limits concurrent cron job runs\n- retry.backoffMs: Passive retry delay after rate limit errors \n- Provider-level configurations\n\nHowever, there is no configurable global rate limiter that enforces a maximum number of model API calls per minute across all agents (main, subagents, cron jobs, etc.).\n\n## Use Case\n\nA user with a 600 calls / 5 hours plan (≈ 2 calls/minute) wants to ensure that:\n- All 3 scheduled cron jobs (02:00, 09:00, 18:00)\n- All interactive sessions\n- All subagent executions\n\n...collectively do not exceed 2 model calls per minute.\n\n## Expected Behavior\n\nA configuration option like:\n\njson\n{\n \"models\": {\n \"globalRateLimit\": {\n \"maxCallsPerMinute\": 2\n }\n }\n}\n\n\nOr alternatively at the provider level:\n\njson\n{\n \"providers\": {\n \"minimax\": {\n \"rateLimit\": {\n \"maxCallsPerMinute\": 2\n }\n }\n }\n}\n\n\nWhen the limit is reached, subsequent calls should queue or wait until the next minute window.\n\n## Workaround (Insufficient)\n\nCurrently users must:\n1. Manually stagger task schedules to avoid overlapping\n2. Rely on fallback chains to handle rate limit errors reactively\n3. Use external rate limiting (e.g., a proxy or wrapper)\n\nNone of these provide true global rate control across all agents and sessions.\n\n## Environment\n\n- OpenClaw version: 2026.4.2 (latest available at time of report: 2026.4.5)\n- Node.js: v22.22.2\n- OS: Linux\n- Model provider: MiniMax (also applicable to other tiered providers)\n\n---\n\nWould appreciate a feature addition or guidance on how to achieve this with existing configuration options.\n

RAW_BUFFERClick to expand / collapse

\n## Problem Description\n\nUsers with tiered API pricing plans (e.g., MiniMax Starter: 600 calls / 5 hours) need a way to limit the overall model call rate across all active agents to avoid triggering rate limits.\n\nCurrently, OpenClaw provides:\n- cron.maxConcurrentRuns: Limits concurrent cron job runs\n- retry.backoffMs: Passive retry delay after rate limit errors \n- Provider-level configurations\n\nHowever, there is no configurable global rate limiter that enforces a maximum number of model API calls per minute across all agents (main, subagents, cron jobs, etc.).\n\n## Use Case\n\nA user with a 600 calls / 5 hours plan (≈ 2 calls/minute) wants to ensure that:\n- All 3 scheduled cron jobs (02:00, 09:00, 18:00)\n- All interactive sessions\n- All subagent executions\n\n...collectively do not exceed 2 model calls per minute.\n\n## Expected Behavior\n\nA configuration option like:\n\njson\n{\n \"models\": {\n \"globalRateLimit\": {\n \"maxCallsPerMinute\": 2\n }\n }\n}\n\n\nOr alternatively at the provider level:\n\njson\n{\n \"providers\": {\n \"minimax\": {\n \"rateLimit\": {\n \"maxCallsPerMinute\": 2\n }\n }\n }\n}\n\n\nWhen the limit is reached, subsequent calls should queue or wait until the next minute window.\n\n## Workaround (Insufficient)\n\nCurrently users must:\n1. Manually stagger task schedules to avoid overlapping\n2. Rely on fallback chains to handle rate limit errors reactively\n3. Use external rate limiting (e.g., a proxy or wrapper)\n\nNone of these provide true global rate control across all agents and sessions.\n\n## Environment\n\n- OpenClaw version: 2026.4.2 (latest available at time of report: 2026.4.5)\n- Node.js: v22.22.2\n- OS: Linux\n- Model provider: MiniMax (also applicable to other tiered providers)\n\n---\n\nWould appreciate a feature addition or guidance on how to achieve this with existing configuration options.\n

extent analysis

TL;DR

Implement a global rate limiter configuration option to limit model API calls per minute across all agents.

Guidance

  • Introduce a new configuration option, such as models.globalRateLimit.maxCallsPerMinute, to set a global rate limit for model API calls.
  • Consider implementing a queueing mechanism to handle requests that exceed the rate limit, allowing them to wait until the next minute window.
  • Evaluate the feasibility of integrating an external rate limiting solution, such as a proxy or wrapper, as a temporary workaround.
  • Review the current cron.maxConcurrentRuns and retry.backoffMs configurations to ensure they are optimized for the desired rate limiting behavior.

Example

{
  "models": {
    "globalRateLimit": {
      "maxCallsPerMinute": 2
    }
  }
}

This example illustrates a potential configuration option for setting a global rate limit.

Notes

The implementation of a global rate limiter may require significant changes to the existing OpenClaw architecture. The proposed configuration options are based on the expected behavior described in the issue.

Recommendation

Apply a workaround by integrating an external rate limiting solution, such as a proxy or wrapper, until a native global rate limiter feature is available. This will provide a temporary solution to mitigate rate limit errors.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#agent execution#GPU compatibility#latency issue#model loading

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING