[ApexMene]

Issue for this PR

Closes #39790

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

SessionRetry.delay() returns whatever the provider puts in retry-after, capped only by RETRY_MAX_DELAY (~24.8 days). policy() then schedules the next attempt that far out, so an exhausted quota window parks the session on one pending attempt that can be a full day away. Nothing is logged after the first stream error, no session.error is published, and the session never reaches idle.

zen is one concrete source: getRetryAfterDay() in packages/console/app/src/routes/zen/util/ipRateLimiter.ts sets retry-after to the seconds left until the next daily reset, so an exhausted free tier can answer with up to 86400.

The change stops the schedule when the requested wait is longer than RETRY_MAX_WAIT (5 minutes). The retry status is published first, so the free tier and Go limit dialogs fire exactly as they do today, then Cause.done lets the error reach halt in the processor and the session goes idle. Waits inside the ceiling are untouched, so normal 429 and 5xx backoff behaves as before.

How this relates to the other open PRs on the issue, since the duplicate bot flagged them:

• fix(session): stop retrying free and Go usage quotas #47339 stops on the free_tier_limit and account_rate_limit reasons, which are derived from zen specific markers in the response body. That covers zen, but a provider that just answers with a long retry-after and no recognizable body still hangs the same way. This PR gates on the wait itself, so it covers that case too. The two are not exclusive, they compose fine if you want both.
• fix(cli): stop run from sleeping through an exhausted quota #42340 fixes the reporting side in run and is independent of this.

I hit this through a subagent, which is where it hurts most: the retry status is published on the child session ID, and both the TUI and the app ignore session.status for sessions other than the routed one, so the parent turn shows a spinning task tool and no dialog at all. Two of my sessions sat like that for 9h26m and 8h52m before I noticed.

How did you verify your code works?

Free tier actually exhausted, isolated XDG_DATA_HOME, same command both times:

bun dev run -m opencode/muse-spark-1.3-contributor-free "say pong"

• without the change: no output at all, killed by timeout 120
• with the change: Error: Rate limit exceeded. Please try again later., exit 1, 3.8s

Two new tests in packages/opencode/test/session/retry.test.ts, one per side of the ceiling. The first one fails on dev and passes with the change. bun test test/session/ gives 415 pass and bun typecheck is clean, both run from packages/opencode.

Screenshots / recordings

Not a UI change.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Found 2 potentially related PRs:

1. fix(session): stop retrying free and Go usage quotas #47339: fix(session): stop retrying free and Go usage quotas

   • fix(session): stop retrying free and Go usage quotas #47339
   • Related: Addresses stopping retries for free tier and Go usage exhaustion scenarios

2. fix: restore Go signup prompts and stop free-tier retries #46994: fix: restore Go signup prompts and stop free-tier retries

   • fix: restore Go signup prompts and stop free-tier retries #46994
   • Related: Also tackles free-tier retry handling and related dialogs

3. fix(cli): stop run from sleeping through an exhausted quota #42340: fix(cli): stop run from sleeping through an exhausted quota

   • fix(cli): stop run from sleeping through an exhausted quota #42340
   • Related: Similar issue with sessions sleeping/waiting when quota is exhausted

These PRs appear to address related concerns around stopping long waits during rate limiting and quota exhaustion scenarios. PR #47339 in particular seems closely aligned with the current PR's goals around free tier and Go limit handling.

[github-actions]

Thanks for updating your PR! It now meets our contributing guidelines. 👍

[xam1986]

test

[ApexMene]

Thanks for the thorough review!

Applied both non-blocking notes in f258440:

• Clamped published next to wait > RETRY_MAX_WAIT ? now : now + wait so the status never advertises an attempt that won't be scheduled.
• Clarified RETRY_MAX_WAIT comment to distinguish it from RETRY_MAX_DELAY and point to policy().

Verified with bun test test/session/ (415 pass) and bun typecheck (clean) from packages/opencode.

[ApexMene]

Hi! The test, nix-eval, and typecheck workflow runs expired while waiting for approval, so no jobs were executed. Could a maintainer approve and rerun them on the latest head (da39ccd)? Thanks!

[github-actions]

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.

[ApexMene]

I am still actively working on this contribution and would appreciate reopening PR #47641. The review feedback was addressed in commit f258440; the latest test, nix-eval, and typecheck runs report “No jobs were run,” so they have not evaluated the change. Could a maintainer reopen the PR and approve/rerun these workflows? Thanks.