Skip to content

OpenCode Zen free quota stuck for two days — request for investigation #59176

New issue
New issue
Closed as not planned
Closed as not planned
OpenCode Zen free quota stuck for two days — request for investigation#59176
Labels
pending closetriaging

Description

@roro1335-tech
roro1335-tech
opened on Oct 26, 2026

Hello OpenCode Support,

I am experiencing a persistent free-usage issue with OpenCode Zen.

The application reports that my free usage has been exceeded and asks me to subscribe to Go. It displays a long retry countdown of approximately 17,000 seconds, but the number does not change, and the issue has persisted for about two days.

The free models remain visible, but I cannot use them. I would prefer to continue using the free models without purchasing a subscription.

Could you please investigate whether my account is affected by the free-quota reset issue reported in GitHub issues #58859 and #58842, verify my quota and reset status, and restore free access if the quota system is stuck?

I would appreciate clarification on whether this is an account-specific restriction or a service-side issue.

Thank you.

Activity

  1. opencode-agent commented on Oct 26, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 26, 2026 – with OpenCode Agent
    Contributor

    Thanks for reporting this, and sorry about the trouble. Being blocked from the free models for two days by a countdown that never changes is frustrating.

    The free-usage allowance and when it resets are tracked and enforced for each account by the OpenCode Zen service, not by the app on your computer. Only the team can check your account, so billing and account support isn't handled in GitHub issues. Please email help@anoma.ly with:

    • roughly when the problem started
    • the exact error message
    • the countdown values you've seen

    If you've already emailed, the team will get to it, especially now that we've seen it here. Please keep your email address, account details and any payment information out of this public issue and put them only in the email.

    For reference, other people have reported the same symptom recently, which suggests it isn't specific to your account:

    The bot will close this issue in 1 day, since it will be handled by email.

  2. opencode-agent
    added
    pending close
    triaging
    on Oct 26, 2026

  3. roro1335-tech commented on Oct 26, 2026

    @roro1335-tech
    roro1335-tech
    on Oct 26, 2026 via email
    Author

  4. k-rithik04 commented on Oct 26, 2026

    @k-rithik04
    k-rithik04
    on Oct 26, 2026

    Persistent Free Quota Reset Failure — Locked out of OpenCode Zen free models for 3 days (Ref: Issues #59176, #58859, #58842)

    Hello OpenCode Team,

    I am writing to report a persistent cloud-side quota issue that has completely locked me out of using the OpenCode Zen free models for the past three days.

    Issue Summary:

    Symptoms: The CLI and Desktop application report: You've used today's free messages. They reset at 5:29 AM · 10/26/2026. Upgrade to OpenCode Go → /connect · Switch model → /models

    Observed Behavior: The reset time (5:29 AM) passes, but the daily message allowance never resets. Consecutive attempts to query free models (beam-free, deepseek-v4.1-flash-free, etc.) return immediate HTTP 429 / FreeUsageLimitError (provider.free-limit).

    Duration: This has persisted across October 24, October 25, and October 26, 2026.

    Related Issues: This directly matches the server-side accounting bug reported in GitHub Issues #59176, #58859, and #58842.

    Log Snippet:

    event.type = provider.free-limit
    message = "Free usage limit reached. Connect a provider or subscribe to OpenCode Go to keep going, or switch models."
    Reset Target: 5:29 AM
    Status: Persists past scheduled reset window.

  5. roro1335-tech commented on Oct 26, 2026

    @roro1335-tech
    roro1335-tech
    on Oct 26, 2026 via email
    Author

  6. no1ce commented on Oct 26, 2026

    @no1ce
    no1ce
    on Oct 26, 2026

    Same pattern here, and I can add a data point that narrows it down: the block ended without any local change, so the state that was stuck really did live on the service side.

    Environment

    • OpenCode Desktop 2.1.4 (opencode-cli 2.1.4-x64), Windows 11 Home build 26300
    • second machine: CachyOS, same account, blocked at the same time
    • provider opencode, model opencode/big-pickle, free plan, no credits, no Go subscription

    Timeline

    From ~/.local/share/opencode/log/opencode.log (UTC):

    2026-10-23T08:48:03Z  Free usage limit reached  (agent=build, small=false)
2026-10-23T08:48:10Z  Free usage limit reached  (agent=title, small=true)
2026-10-23T16:00:57Z  Free usage limit reached
2026-10-23T19:08:28Z  Free usage limit reached
2026-10-25T19:41:27Z  Free usage limit reached. Free models work in OpenCode (https://opencode.ai) ...
2026-10-26T05:09:58Z  Free usage limit reached
2026-10-26T05:12:04Z  Free usage limit reached      <- last failure
2026-10-26T05:17Z     requests succeed again

    No successful request in between. The allowance was reported as exhausted the whole time, including the automatic title-generation request.

    Three details that might help

    1. The earliest request I have in that window already failed. There is no successful request before the first error, so nothing was actually consumed in that period.
    2. Failures continued at 05:09Z and 05:12Z on 2026-10-26 — more than five hours after a 00:00 UTC reset, with zero usage in that window. A fixed daily allowance reset at 00:00 UTC does not explain that, it looks like a stale or rolling counter.
    3. ~/.local/share/opencode/auth.json was last written at 2026-10-25T19:35Z and did not change between the last failure (05:12Z) and the first successful request (~05:17Z). So the recovery was purely server-side: no new key, no reset of local state. A full reinstall of the app, which I tried first, changed nothing either.

    Questions

    • Is the free allowance a fixed daily window or a rolling one? If it is daily, what explains point 2?
    • Is there any way for a user to see the remaining allowance and the reset time? Right now there is no reset or retry information in the log, in /status or in the UI, which makes "stuck" and "legitimately exhausted" look identical.
    • If the allowance is also counted per network, how are users behind CGNAT / shared public IPs supposed to read their own consumption?

    Related: #59027 reports the same for 2.1.4 specifically, while 1.19.4 was served fine on the same account/key/IP. That points at the accounting depending on the client, not just on the account, which is worth checking before this gets filed as an account issue.

  7. no1ce commented on Oct 26, 2026

    @no1ce
    no1ce
    on Oct 26, 2026

    Correction to my comment above — I found one detail afterwards that changes the conclusion.

    Those failures were not on 2.1.4. Until 2026-10-26T05:12Z this machine ran 1.19.4 (v1): the log reports version=1.19.4 for the failing session, and the first cli starting version=2.1.4 entry only appears at 05:17:14Z.

    What actually happened (same account, same key, same IP, five minutes apart):

    2026-10-26T05:12:04Z  v1 1.19.4  -> 429  "Free usage limit reached"
2026-10-26T05:17:14Z  v2 2.1.4   -> cli starting, DB migration
                                    "20260805200742_import_legacy_credentials"
2026-10-26T05:17:1xZ  v2 2.1.4   -> request succeeds

    The credential v2 imported is byte-identical to the one in auth.json (same SHA-256), so this was not a new key, not a new account and not a different network. The same credential was rejected by 1.19.4 at 05:12 and accepted by 2.1.4 at 05:17.

    So my "full reinstall" was actually a v1 -> v2 upgrade, and that upgrade is what ended the block after about three days of failures. My earlier claim that the recovery was "purely server-side with no local change" was wrong, and the auth.json timestamp argument does not hold in v2 because credentials live in the SQLite DB there.

    What still stands:

    • Between 2026-10-23 and 2026-10-26 nothing was consumed in that window — the earliest request already failed.
    • The block outlasted a 00:00 UTC reset (failures at 05:09Z and 05:12Z on 10-26), so a plain daily allowance does not explain it.
    • Reinstalling v2 itself would not have helped; switching the client major version is what did.

    This points at version-dependent accounting on the client side rather than a stuck account quota, and it is the mirror image of #59027 (which reports v1 working and v2 blocked). Together the two reports suggest the free-tier decision depends on which client/version path the request takes, not only on the account.

    Worth checking: is 1.19.4 still rejected for this credential while 2.1.4 succeeds, and does the request from v1 differ in endpoint, headers or a client-version field?

  8. k-rithik04 commented on Oct 26, 2026

    @k-rithik04
    k-rithik04
    on Oct 26, 2026

    Working Fix / Workaround for Stuck Quota Loop

    For anyone stuck on the persistent "You've used today's free messages. They reset at 5:29 AM..." loop even after the reset time has passed:

    I was completely locked out for 3 days with the reset timer never clearing. What finally fixed it and restored access to the free models was doing a complete clean uninstall via the terminal to purge the cached quota lock state, and then reinstalling cleanly via Bun.

    Here are the exact terminal steps:

    1. Terminate any running OpenCode background daemons
      bash
      pkill -9 -f "opencode" || true
    2. Remove the old CLI package
      bash

    If installed via Bun:

    bun remove -g @opencode/cli

    Or if installed via npm:

    npm rm -g @opencode/cli
    3. Wipe the stale session database and cached quota locks

    (Note: If you have custom provider API keys in ~/.config/opencode/opencode.json, back that file up first):

    bash
    rm -rf ~/.local/share/opencode ~/.local/state/opencode ~/.cache/opencode /tmp/opencode

    Why this matters: OpenCode caches the failed session state and rate-limit locks in ~/.local/state/opencode (model.json) and ~/.local/share/opencode (opencode.db). Simply restarting the app keeps loading the stale locked state.

    1. Reinstall the latest version cleanly using Bun
      bash
      bun add -g @opencode/cli@latest
    2. Start OpenCode
      bash
      opencode

    After doing this clean wipe and reinstall via Bun, OpenCode generated a fresh session state and the free models immediately started working again without the countdown lock. Hope this helps anyone else stuck!

  9. opencode-agent
    closed this as not plannedon Oct 27, 2026

  10. opencode-agent commented on Oct 27, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 27, 2026 – with OpenCode Agent
    Contributor

    Hi @roro1335-tech, I'm closing this now because free-usage and account problems are handled by email rather than in GitHub issues. Sorry again that you've been locked out of the free models.

    If you're still blocked, please email help@anoma.ly with when it started, the error message and the countdown you're seeing. Please keep your account details only in the email, not here. Thanks for your patience!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    pending closetriaging

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions