[FEATURE]: Add "Retry Now" button to skip rate limit retry countdown

Feature hasn't been suggested before.

I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem

When hitting rate limits, OpenCode shows a retry countdown (e.g., "Rate limited. Quick retry in 1s…").

Sometimes the rate limit has already passed, but the system is still waiting for the retry timer to complete. This wastes time when the API is actually available.

Proposed Solution

Add a "Retry Now" button or keyboard shortcut that allows users to:

Skip the retry countdown
Immediately attempt the request again

This would be useful when:

Users know the rate limit has passed
Testing if the API is available again
Saving time during long exponential backoff waits

Current Workaround

Wait for the countdown to complete
Or interrupt and manually retry (which often succeeds immediately)

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

[FEATURE]: Retry: allow user to change "exponential backoff" to "fixed interval" #8769: Requests the ability to control the exponential backoff retry strategy (fixed interval vs. exponential), motivated by the same problem — the retry wait is too long when the API is already available again. The two issues overlap significantly in goal.

Since this feature request mentions a keyboard shortcut as one of the proposed solutions, please also check our pinned keybinds documentation: #4997

@thdxr

it will be also much better if: I can set the wait time before the retry happens!
the problem is that the Opencode is scaling every time it retries, we may go from 60 seconds to 10000 seconds on the retry number #17 !
I can simply set it to 60 seconds, so it tries again every 60 seconds, that's it - even if it will retry 1000 times, just retry every 60 seconds, this is a critical needed adjustment and feature.
we're talking about any LLM provider, not just Opencode Zen.
@thdxr

@rekram1-node

@rekram1-node

I think the "Retry Now" button is more useful than the interval setting.
however the interval is set, it should be able to skip.

@Xiao4

@Xiao4 I agree. Sometimes the exponential retry jumps too far, I've had it start waiting for over an hour when the error response message states to retry in ~20 seconds.
A "Retry Now" button or just pressing Enter on an empty prompt would be useful in forcing a retry.

@Xiao4 I agree. Sometimes the exponential retry jumps too far, I've had it start waiting for over an hour when the error response message states to retry in ~20 seconds. A "Retry Now" button or just pressing Enter on an empty prompt would be useful in forcing a retry.

100%. It's simple logic. We should be able to intervene when there are issues.

vote for this, fixed interval is a good choice too.

currently we can only abort entire session and type something like "continue your work", tedious :(

@testatox1-source

@testatox1-source It sounds like you haven't experienced or understood the issue - OpenCode already auto-retries, but at increasingly large intervals. Sometimes those intervals just fall within the rate limit period, leaving users waiting unnecessarily, sometimes for hours after the upstream rate-limit truly expired.

For anyone encountered this issue, I have made a quick vibecoded plugin (just copy both files into .config/opencode/plugins or $XDG_CONFIG_HOME/opencode/plugins depends on your setup) and add "plugin": ["./plugins/manual-retry-tui to tui.json: https://gist.github.com/Trung0246/4a68066d44fba4a2eb145f804007b48e

Using it is as simple as typing /retry-now. Also works for subagents.

I am once again waiting over 2 hours for the retry on an attempt that fell minutes before my quota was restored.
So a request would work now! But nope, I have to wait 2 hours, because there's no 'Retry now' button. Ridiculous.

Again, a 10 second difference in timeout period for a subagent, rolls over to an hour. Painful in the extreme. Enough to drop OpenCode for Pi altogether. Ridiculous UX deficiency. I saw it happening and have attached the screenshots to illustrate the anguish of every user affected by this.

(Yes, I know it also looks overall 1h offset with the reported time, this is just z.ai things)

Hey guys, I'm also tired of fighting this delay, so I made a small plugin https://github.com/aleks-spv/opencode_retrypush.git

Hey guys, I'm also tired of fighting this delay, so I made a small plugin https://github.com/aleks-spv/opencode_retrypush.git

Does this work for subagents too?

Most of the time I get rate-limited inside a subagent which makes this issue even worse, because to manually trigger it again I have to cancel it and the full subagent has to start all over again

Hey guys, I'm also tired of fighting this delay, so I made a small plugin https://github.com/aleks-spv/opencode_retrypush.git

Does this work for subagents too?

Most of the time I get rate-limited inside a subagent which makes this issue even worse, because to manually trigger it again I have to cancel it and the full subagent has to start all over again

The hook is registered once when the plugin is loaded, but it works for ALL sessions - both for the main and for sub-agents.

Hey guys, I'm also tired of fighting this delay, so I made a small plugin https://github.com/aleks-spv/opencode_retrypush.git

Does this work for subagents too?

Most of the time I get rate-limited inside a subagent which makes this issue even worse, because to manually trigger it again I have to cancel it and the full subagent has to start all over again

Which of course WAIST TOKENS LOL
This is so annoying. The sad part is that this is better handled with Opencode Go where the retry backfill use the correct remaining time.

But for some reason Opencode doesnt do that for other providers

I was so annoyed with our requests being ignored and by how F$$$$% up was OpenCode 2.0 (it stopped working for me) with all the breaking changes (I developed many tools for my own workflow!!!!) I developed my own harness. YES. my own harness for my personal use!!!

I also quit OpenCode over this issue. It's ridiculous: such a relatively minor UX fix, but it highlights the maintainers inability to focus on, or accept PRs, over the things that actually matter to users. Gone.

Thanks for the suggestion! You're asking for a way to skip the rate-limit retry countdown and start the next attempt right away, for example with a "Retry Now" action or keybind (or, as someone suggested here, pressing Enter on an empty prompt).

OpenCode v2 doesn't have this either yet. The TUI shows Retrying in Ns · attempt N and waits out the whole delay, so this applies to the current version too. Maintainers will consider it.

The session.retry plugin hook in v2 can change the retry delay before the wait starts, for example to use a fixed interval or put a cap on the backoff. That covers the fixed-interval idea from the comments. It can't skip a wait that is already running, though, so "Retry Now" itself needs support in OpenCode.

[FEATURE]: Retry: allow user to change "exponential backoff" to "fixed interval" #8769: asks for control over the backoff strategy (fixed vs. exponential), with a similar motivation

Navigation Menu

Repository navigation

[FEATURE]: Add "Retry Now" button to skip rate limit retry countdown #15988

Feature hasn't been suggested before.

Describe the enhancement you want to request

Problem

Proposed Solution

Current Workaround

3 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: Add "Retry Now" button to skip rate limit retry countdown #15988

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

Problem

Proposed Solution

Current Workaround

Activity

github-actions commented on Mar 4, 2026

testatox1-source commented on Mar 31, 2026

testatox1-source commented on Mar 31, 2026

Xiao4 commented on Mar 31, 2026

noahbald commented on Apr 9, 2026

fchamieh commented on May 21, 2026

koyabr commented on Jun 2, 2026

3 remaining items

chris-hatton commented on Jun 20, 2026

Trung0246 commented on Jun 30, 2026

chris-hatton commented on Jul 9, 2026

chris-hatton commented on Jul 19, 2026

aleks-spv commented on Jul 31, 2026

Niels-Be commented on Jul 31, 2026

aleks-spv commented on Jul 31, 2026

albilu commented on Aug 2, 2026

fchamieh commented on Oct 7, 2026

chris-hatton commented on Oct 8, 2026

opencodejr commented on Oct 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions