The squeeze on free models: new OpenCode/OpenWork Zen limits from October 23, 2026
On October 26, 2026, two fresh OpenWork sessions stopped at the same message:
The free starter model is busy right now. Retrying... To keep working now, connect your own model provider.
It looked like temporary overload — and, above all, unfair: no free model had been used that day. The engine log said otherwise:
level=ERROR message="stream error" providerID=opencode modelID=deepseek-v4.1-flash-free
error.error="AI_APICallError: Free usage limit reached. Free models work in OpenCode
(https://opencode.ai); subscribe to OpenCode Go to keep going: https://opencode.ai/go"
Two HTTP 429 (FreeUsageLimitError) responses disguised as a "busy model". But the disguise is not the point: since October 23, 2026, the Zen free regime has changed — and the change came with no announcement, no new number in the docs and no counter in the UI.
1. Four errors that look like the same error
Before talking about quota, it helps to separate the messages that arrive with similar wording and completely different causes:
| What you see | Real cause | What fixes it |
|---|---|---|
The free starter model is busy right now. Retrying... |
429 FreeUsageLimitError: the IP's free quota is exhausted for the UTC day |
Wait for the bucket to roll over; use a paid model |
403 FreeTierError · "OpenCode's free tier can only be used from within OpenCode" |
A free-tier call coming from outside the OpenCode client (proxy, gateway, curl) |
Don't insist: the gate requires the client |
The opencode provider disappears from the UI and every *-free returns 403 |
The app version (from 0.18.60 on) injects a provider block |
Roll the version back — full analysis in the other article |
OpenWork Connect: Needs attention — provider/model not found |
A false positive from the health probe while signed in to Cloud | Ignore it; unrelated to quota |
Only the first row is about quota. The other three still exist, and they are why so many people rotate keys, reinstall the app, and conclude that "nothing works" when the problem is something else.
2. The daily bucket does not roll over at your local midnight
The Zen free quota is a bucket per IP and per UTC day, keyed ip:<ip>:<YYYY-MM-DD>. The UTC day starts at midnight UTC; in Brasília (UTC−3) that is 9 pm the evening before. If you are in another timezone, convert: the reset is always 00:00 UTC.
The practical consequence applies to any user, in any timezone: usage after the local hour when the UTC day turns already belongs to the next bucket. Using the free tier at 10 pm on a Tuesday spends Wednesday's quota. And opening the app the next morning to "quota exhausted" does not mean you used anything that local day.
One concrete case, for scale: on October 25, three agent sessions ran in parallel between 22:20 and 22:42 and burned 167 free calls, 166 of them completed. The first refusal came at 22:42. At 00:02 and 00:03 on October 26 — already the next local day — beam-free and nemotron-3.5-super-vl-free returned the same 429. At 18:44 on October 26, still before 9 pm, two new sessions were born blocked. To the local calendar, "I used nothing today"; to the counter, the day had started at 9 pm the evening before.
That is why "the quota never came back" is almost always a timezone reading, not a defect.
3. How the mechanism works inside
The gateway code (handler.ts, ipRateLimiter.ts and trialLimiter.ts) completes the picture:
- Who picks the bucket: models marked
allowAnonymous— every free one is — use theipRateLimiter. Models with their ownrateLimitswap the date for a per-model bucket (the first 2 characters of the id instead of the full day). That is why two free models can answer differently in the same second. - Double quota for a new IP: while that IP's lifetime counter is below
7 × daily limit, the daily limit is doubled. - A refusal does not count:
check()runs before the provider call and throws there;track()only increments after the response. Retrying from the banner is a no-op — it consumes no quota, but it does not unblock anything either. - The second ceiling does not produce a 429: models served by trial providers consume a lifetime token budget per IP (
promoTokens). Once exhausted, the model stops preferring that provider and continues through another one. It does not raiseFreeUsageLimitError— so it does not explain minute-long windows. - There is no counter: neither OpenWork nor the Console's Usage tab shows "how much is left". The Console activity log records the refusal as
errorCode: inference_failed, without saying it is quota.
The number is not a published rule
The Go FAQ documents 200 requests/day for free models. What we measured, however, varies:
| Date | First refusal of the UTC day |
|---|---|
| Oct 22 | ~900 completed requests (refusal only at the end of the day) |
| Oct 23 | 939 completed |
| Oct 25 | on the 215th request |
| Oct 26 | on the 168th request |
Maintainers answer publicly that the free quota is dynamic — "we are always shifting based off what capacity we have vs demand" (#28055, #55816) — and that the limit applies "to your account or network as a whole, not to each model" (#56523). In other words: 200 is a snapshot, not a contract. And in the October 26 case, the refusal at the 168th position may be a lower server config or traffic from another client on the same IP — both fit the measurement, and there is no way to separate them without a second IP to compare.
4. The timeline of the cut
The squeeze was not a single announcement; it was a shift that can be dated by the flood of reports.
Oct 17 — the catalog shrinks by product decision. muse-spark-1.3-contributor-free is retired on purpose. Issues #56541 and #56580 get the answer that the model was "a free model offered for a limited time" and was removed (PR #56301). The free catalog rotates by design: today it is DeepSeek V4.1 Flash Free, Nemotron 3 Ultra/3.5, Beam Free, GLM-5.3 Flash Free, MiMo and Big Pickle.
Oct 22–23 — the bucket was still large. On one IP monitored for this article, 903 and 939 deepseek-v4.1-flash-free requests were completed in a day, with the refusal only at the end. In other words: until October 23, the old level still held for at least part of the user base.
Oct 23 — the flood begins. This is the day of the first wave of public reports of quota refused with no usage: issue #58284 describes thirteen attempts on October 22, all refused, with zero usage in the Console. Within 48 hours, #58842, #58859, #58900, #58902 and #58919 join in, all with the same shape: a 429 that does not come back after the displayed time, or that comes back with zero usage.
Oct 25 — the new ceiling shows up in the measurement. The first refusal came on the 215th free request of the UTC day. It is the first day the ~200 level can be measured — two days after the bucket still accepted ~900.
Oct 26 — the new ceiling is confirmed. The refusal came on the 168th request, and two new sessions, with no usage in the local day, were born blocked. Issue #59176 gathers the same symptom across more accounts; the triage bot acknowledges that "other people have reported the same symptom recently, which suggests it isn't specific to your account".
The most likely date for the cut is October 23: it is when the mass reports begin and when the behavior stops being "a high quota nobody reaches" and becomes "a refusal with little or no usage". The rollout did not reach everyone on the same day — the IP behind this measurement only felt the new ceiling on October 25 — but the date of the squeeze is the date of the flood, not that of an isolated measurement.
And there is an ambiguity the design imposes: the same message covers quota legitimately spent and quota stuck by an accounting defect. Here the arithmetic checked out (167 calls before the refusal), so it was exhaustion; for a good share of the October 23–26 reports, it does not.
Closed siege: why there is no local workaround
Zen's free tier stopped being a predictable reserve. It is a promotion: models are swapped, dropped from the catalog and have their ceiling lowered without a changelog — and now they can refuse for spent quota or for stuck accounting, with the same message and no counter to tell them apart.
What does not change the quota, despite looking like it might: a new key (the bucket belongs to the IP), reconnecting the account, re-enabling Auto, resetting the model picker or switching free models — the last one buys minutes from a bucket with room, not an exit. On the app side there is no switch either: the only real lever is commercial, a paid model or a subscription.
Unlike the app-version block, which had a documented rollback in the other article, this squeeze has no exit trigger on the user's side. The safe path is to budget important work on a paid model and treat free as a bonus: fine for short, disposable sessions, not for anything that has to happen.
I recommend this one
The free tier has no way out; the paid one has a choice — and here the choice is direct: DeepSeek V4.1 Flash. It is the model that wrote this article: 5 hours of work, 21 conversation rounds and about US$ 1.40 by the time it closed. Each round became, on average, 14 requests to the model — 290 in total. The October 26 free bucket closed at the 168th request of the day, around round 12: the conversation would have ended before halfway.
On Zen it costs US$ 0.30 per 1M input tokens and US$ 1.20 per 1M output tokens. On the public OpenRouter ranking, the V4.1 Flash family holds the top two spots for the week (35.4T and 17.4T tokens) and the top spot for the month (123T) — it is the most used model on the platform, which also means more people testing it and more documented behaviour. Prices and rankings change; check before subscribing.
Bruno Torres
Solo digital entrepreneur. I build digital businesses from scratch with AI agents — and document the path, including what didn't work.
Comments
Discuss: LinkedIn
Share: X · Facebook · LinkedIn · WhatsApp · Telegram · E-mail ·