[FEATURE]:Automatically pause and resume tasks when rate limits have a known reset time #43126

Activity

1. github-actions

   assigned

   jlongster

   on Aug 17, 2026
2. github-actions commented on Aug 17, 2026

   

   github-actionsBot

   on Aug 17, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue might be a duplicate of existing issues. Please check:

   • Session retries fixed-window usage quota errors until reset #39790: Session retries fixed-window usage quota errors until reset — covers the same rate-limit reset-time scenario from a bug angle (stopping futile retries when a known reset time is provided). Your feature request is the complementary proactive side: instead of just stopping retries, automatically resume when the reset time arrives.
   • [FEATURE]:Add Suspend/Resume functionality to pause Agent and Subagent execution #27511: Add Suspend/Resume functionality to pause Agent and Subagent execution — overlaps on the pause/resume mechanism, though motivated by device-switching rather than rate limits.

   If these don't fully cover your use case, it may be worth referencing them in this issue for context.

   👍React with 👍2Reacted by Florian and Martin Vidovic
3. ECeternalcat commented on Aug 17, 2026

   

   ECeternalcat

   on Aug 17, 2026

   Author

   More actions

   This is related to #39790 and #27511, but combines the two:

   • Session retries fixed-window usage quota errors until reset #39790 handles known reset times during retry.
   • [FEATURE]:Add Suspend/Resume functionality to pause Agent and Subagent execution #27511 proposes the general suspend/resume mechanism.

   This request is specifically about connecting them for rate-limited sessions:
   persist the session, pause until the provider's reported reset time, and
   automatically resume afterwards.

   👍React with 👍3Reacted by Florian, Martin Vidovic and Arjun Pramanik
4. Israel-Kli commented on Oct 13, 2026

   

   Israel-Kli

   on Oct 13, 2026

   More actions

   I hit this with a Claude subscription: after the limit is reached the session keeps retrying against the same model, and after the reset I have to type "continue" by hand. Using the reset time from the error would fix both.

   A small shape that could work: surface the reset time on the failure, stop retrying when it is beyond the retry cap, and schedule a resume for that time using #52103 (session schedules). Could a maintainer say whether that direction is acceptable? I'm willing to build it once the design is agreed.
5. neriousy

   marked [Feature Request / Bug] Handle Rate Limit (Quota Exceeded 429) automatically with retry delay #49039 as a duplicate of this issue on Oct 20, 2026
6. opencodejr commented on Oct 28, 2026

   

   opencodejrBot

   on Oct 28, 2026

   Contributor

   More actions

   Thanks for the request, @ECeternalcat!

   To restate it: when a provider reports when a rate or usage limit resets, you'd like OpenCode to save the session, show that it is paused until that time, and then continue on its own. You would only need to resume by hand when no reliable reset time is given. Maintainers will consider it.

   Other reports have been pointed here, so this issue is where the request is being tracked. Related issues and PRs:

   • [FEATURE]: Per-Provider Quota-Aware Auto-Retry with Configurable Reset Schedule #43324: the engine side, i.e. knowing per provider when the next reset is
   • [FEATURE]: typed usage-limit signal (with reset time) for ChatGPT sign-in instead of error text #56798: asks for usage-limit errors to carry a typed reset time instead of plain error text
   • feat(core): add agent-callable session schedules #52103: a PR that adds scheduled prompts to a session, which could do the "continue at the reset time" step
   • [FEATURE]:Add Suspend/Resume functionality to pause Agent and Subagent execution #27511: general suspend/resume for agents and subagents
   • Session retries fixed-window usage quota errors until reset #39790: stopping retries that can't succeed on fixed-window quotas (closed, not planned)
   • [FEATURE]:Add retry logic for subagents on TPM/RPM rate limits #59533: retrying subagents on rate limits

   In the meantime, a plugin can do part of this. The session.retry hook lets a plugin change how long a session waits before retrying. A user on #43324 says they built a local plugin this way that works for them.
7. Gusser93 commented on Oct 28, 2026

   

   Gusser93

   on Oct 28, 2026

   More actions

   I would love to see this implemented.
   To my knowledge, the session.retry hook doesn't expose the response headers like retry-after. In case you also get a message back that includes the time to wait or the next time you are allowed to send a request, you can try this plugin I wrote for my case. It tries to parse the error message (which I got by writing it to a file to check the content to write the regex), if this does not work, it falls back to a 5-minute timer, which is the default waiting time before tokens get reset in my case. If the information can only be found in the response header, to my knowledge, you would need to use the http.response hook, which should trigger with each answer, not only errors. Hope this helps until it gets implemented.

   👍React with 👍1Reacted by monbooo090
8. monbooo090 commented on Oct 29, 2026

   

   monbooo090

   on Oct 29, 2026

   More actions

   Thank you!
   The plugin created by @Gusser93 is working very well in my environment.
9. neriousy

   marked [FEATURE]: Per-Provider Quota-Aware Auto-Retry with Configurable Reset Schedule #43324 as a duplicate of this issue on Nov 13, 2026
10. trin4ik commented on Nov 14, 2026

    

    trin4ik

    on Nov 14, 2026

    More actions

    We wrote up a general session pause for V2: #63875 (soft / hard / kill, nothing wakes the session until resume, everything else gets queued).

    "Pause until the limit resets" would be just a soft pause plus a timed resume on top of it, so a plugin like the one here could do it reliably.