Repository navigation
[BUG] Zen balance does not remove free usage cap; paid users still hit 200-request/free usage limit #33495
Description
Description
Users with an active OpenCode Zen balance are still being limited as if they are free-tier users.
I tested this with two separate users/accounts. One account had a Zen balance of at least $20, but both accounts still hit the same free usage cap / 200 request limit and received 429 rate-limit errors. The paid/balance-enabled account did not appear to get any higher allowance or fallback to paid Zen balance.
This looks like the free usage limiter is being applied before checking whether the account has Zen balance / billing enabled.
Expected behavior:
-
Accounts without billing/balance should be limited by the free usage cap.
-
Accounts with Zen balance should either:
- use the paid Zen balance after the free cap is reached, or
- not receive the same free-tier-only limit.
-
The error should make clear whether this is a free quota limit, Go usage limit, monthly spend limit, provider limit, or Zen balance issue.
Actual behavior:
- Both free and paid/balance-enabled users hit the same limit.
- The paid account still receives HTTP 429 /
FreeUsageLimitError. - Adding $20 balance does not appear to remove or bypass the free usage cap.
Sanitized example error:
{
"statusCode": 429,
"error": {
"type": "FreeUsageLimitError",
"message": "Rate limit exceeded. Please try again later."
}
}This is confusing because Zen is documented as pay-per-request after adding balance, but the account still behaves like an unpaid/free account.
Plugins
None
OpenCode version
1.17.7 Please confirm if needed; this was observed from the client/user-agent during testing.
Steps to reproduce
- Create or use an OpenCode Zen account with at least $20 balance.
- Use a Zen/free model such as
deepseek-v4-flash-freeor another Zen free model. - Send requests until the free usage cap is reached.
- Observe that the account still receives
FreeUsageLimitError/ HTTP 429. - Repeat with another user/account without balance.
- Compare behavior: both accounts appear to receive the same 200-request/free usage cap despite one having Zen balance.
Screenshot and/or share link
No response
Operating System
Linux container
Terminal
OpenCode CLI / server environment
Activity
github-actions commentedon Jun 23, 2026
This issue might be a duplicate of existing issues. Please check:
FreeUsageLimitError/ free usage cap despite having credits added.Please consider closing this issue and continuing the discussion on #33318.
anomalic1 commentedon Jun 25, 2026
Bump issue
anomalic1 commentedon Jun 25, 2026
no its not duplicate
zuli12-dev commentedon Jun 30, 2026
same here, i would love to see that the free models upon the limit is reached, are deducted from the Zen Balance. For me it stopped a workflow. I guess this is a nice to have feature.
Many thanks!
anomalic1 commentedon Jul 1, 2026
I hope you know Openrouter. What they did was if you have 10$ balance you can make 1000 requests per day to their free models.
People were telling all across internet to add 20$ balance inside OpenCode to remove your limits of 200RPD.
I believe it was fake.
matguidi commentedon Aug 12, 2026
I started receiving FreeUsageLimitError (HTTP 429) using OpenCode Zen free models (deepseek-v4-flash-free, mimo-v2.5-free, longcat-2.0-free) yesterday evening after about 1 hour of heavy use (~200 requests). The block persists today (>27 hours from the first error at 18:07 CEST yesterday). It does NOT resolve when changing IP. All free Zen models fail simultaneously. I cannot find any documented reset policy; it's not tied to local midnight. It’s not 24 hours (it’s been lasting longer). When does the limit reset?
zzj0402 commentedon Aug 18, 2026
I am having similar issue. I kept switching between OpenCode and OpenRouter.
neriousy commentedon Oct 1, 2026
Closing as a duplicate of #33318, which tracks paid Zen balances still hitting the free usage limit. Please add your details there. For account-specific billing problems, also contact support so we can look at your workspace.