Free-tier BigPickle quota is exhausted almost instantly (1–5 min / ~5 messages), forcing a 24-hour cooldown #60990

Activity

1. opencodejr commented on Nov 1, 2026

   

   opencodejrBot

   on Nov 1, 2026

   More actions

   Thanks for the report! I think this is a duplicate of #59387, the main thread for free-tier usage limits. Maintainers are collecting all free-tier quota reports there so they're in one place.

   Related issues, ordered from most to least likely to match:

   • Free tier issues: read this first, then post your report here #59387: main thread for free-tier problems (Free usage exceeded, You've used today's free messages. They reset at ..., limits that seem wrong). Please add your report there.
   • [FEATURE]: Warn users before free tier quota exhaustion instead of silent 429 #42765: request to warn users before the free-tier quota runs out, which matches your live usage and low-quota warning asks.
   • [FEATURE]: Document free-tier accounting for free models (idle time, pool scope, remaining allowance) #57540: request to explain how free-tier usage is counted and how much allowance is left.
   • You've used today's free messages. They reset at #60771: another report of the "You've used today's free messages" limit.

   Before commenting on #59387, please check that you're on the latest OpenCode v2 (opencode --version). Most free-tier problems come from v1 (1.x) builds. Then include:

   • your version and whether you use Desktop, TUI or CLI
   • the free model you used
   • the exact error message (a screenshot is fine)
   • the reset time you were shown

   Please don't post email addresses or account details publicly. For account-specific questions, email help@anoma.ly.

   The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
2. opencodejr

   added

   pending close

   triaging

   on Nov 1, 2026
3. WinterGate-IC commented on Nov 1, 2026

   

   WinterGate-IC

   on Nov 1, 2026

   Author

   More actions

   Thanks for the pointer. I've checked the related issues mentioned, and I want to confirm this is not just a duplicate of the standard "used up your quota" complaint—it's a speed-of-consumption bug on the free tier.

   ✅ Duplicate check (done)

   Before posting, I reviewed the suggested threads:

   • [FEATURE]: Warn users before free tier quota exhaustion instead of silent 429 #42765: This asks for a low-quota warning. My issue is that the quota is gone before any warning can even be shown (1–5 minutes, ~5 messages). A warning is useless if the burn is this fast.
   • [FEATURE]: Document free-tier accounting for free models (idle time, pool scope, remaining allowance) #57540: This asks for documentation on how free-tier accounting works. That's helpful, but my problem is the actual rate of consumption, not just understanding the numbers.
   • You've used today's free messages. They reset at #60771: This is a general "you've used today's free messages" report. My issue is specifically that BigPickle consumes the entire daily allowance almost instantly, which is a different failure mode.

   So while I agree these are related, this specific fast-burn behavior with BigPickle is not covered by any of the above.

   My report (as requested)

   • Version & client: latest — using Desktop
   • Free model used: BigPickle.
   • Exact error message: <"Free usage exceeded" / "retrying in ...">.
   • Reset time shown: <e.g., "24h" or "23h 59m">.

   The actual problem

   I am a free user. I selected BigPickle, sent roughly 5 normal messages in under 5 minutes, and the entire daily free quota was exhausted. BigPickle did not get to do meaningful work before the cap was hit.

   This has happened repeatedly. It is not a one-off. The model appears to burn tokens/requests far too quickly, possibly due to agentic loops, repeated tool calls, or hidden context loading. The result is that free users cannot realistically use BigPickle at all—the daily allowance is gone in minutes, followed by a 24-hour cooldown.

   Why this is distinct

   • It is not a version issue (I am on v2 as far as I can tell—please confirm with my version above).
   • It is not just a documentation gap ([FEATURE]: Document free-tier accounting for free models (idle time, pool scope, remaining allowance) #57540).
   • It is not just a missing warning ([FEATURE]: Warn users before free tier quota exhaustion instead of silent 429 #42765)—even a perfect warning would not prevent a 5-minute burn.

   The core bug is: BigPickle's consumption rate on the free tier is so high that the daily quota is effectively unusable.

   Please keep this open as a distinct report. If you need logs (opencode stats, screenshots, or the exact timestamps of the 5 messages), I can attach them.
4. WinterGate-IC commented on Nov 1, 2026

   

   WinterGate-IC

   on Nov 1, 2026

   Author

   More actions

   BigPickle free-tier quota burns in 1–5 minutes

   TL;DR for maintainers

   The near-instant exhaustion of BigPickle’s free-tier quota is not a single bug—it is the intersection of three separate failure modes that compound each other:

   1. Free-tier quota is IP-bucketed, not account-bucketed. Shared IPs (VPNs, CGNAT, corporate egress) can arrive with the quota already exhausted by unrelated users.
   2. BigPickle enters runaway agentic loops (text narration loops, identical tool-call loops, compaction loops) that generate no useful output but consume tokens continuously.
   3. Compaction logic is broken for BigPickle’s 200k context / 160k input catalog entry, causing repeated overflow → compaction → overflow cycles where each cycle burns a full context window.

   The result: a free user sends ~5 normal messages, BigPickle loops or compacts internally, and the entire daily allowance (reported ~0.3M–0.5M tokens) is gone in under 5 minutes.

   ---

   1. Root cause: IP-bucketed quota (shared-IP exhaustion)

   Multiple independent sources confirm that OpenCode’s free-tier quota is enforced per egress IP, not per account (#9611 cited across OmniRoute resilience code and community reports)[reference:0][reference:1].

   Implications

   • If you are behind a VPN, corporate NAT, CGNAT, or cloud egress, you are sharing a quota bucket with every other OpenCode free user on that IP.
   • One user’s runaway loop can exhaust the quota for everyone on the same egress IP.
   • Community reports confirm this directly: users only resolved “Free usage exceeded” after disabling their VPN / changing IP[reference:2].

   Workaround

   • Disable any VPN or proxy and retry from a residential/dedicated IP.
   • If on a shared network, test from a mobile hotspot to confirm whether IP bucketing is the trigger.
   • Check opencode stats after switching IPs to see whether quota resets.

   ---

   2. Root cause: BigPickle agentic loops (token burn without progress)

   BigPickle has several documented loop behaviors that silently consume tokens:

   2a. Text narration loop (no tool calls)

   Issue #46030 documents BigPickle generating dozens of consecutive text turns saying “I will run X” / “Let me execute X” without ever emitting the actual tool call[reference:3]. The session inflates with no-op turns, burning tokens while appearing to “work”[reference:4].

   A related subagent case (#45442) describes an infinite loop of identical tool calls for ~50 minutes with no loop protection—described as “uncontrollable token burn”[reference:5].

   2b. Compaction loop (total=0)

   Issue #37871 documents a critical bug: when BigPickle reads large files (>10K tokens), context overflows, compaction runs, and compaction returns total=0—meaning the compacted output is empty. The agent then re-reads the same files, overflows again, and loops indefinitely[reference:6].

   Observed metrics from that report:

   • 239 loop iterations in 1+ hour
   • 104 compaction calls
   • 8 tail fallbacks, all with total=0
   • CPU pegged at 100%, ~900MB memory consumed, zero progress[reference:7].

   Each compaction call is a full model invocation. On the free tier, this alone can exhaust the daily quota in minutes.

   2c. Compaction window misconfiguration

   A separate analysis (Vasic Digital, ATM-853) found that OpenCode’s derive_limits() read only limit.context and ignored limit.input, so BigPickle’s catalog entry (200k context / 160k input) produced a compaction window above the model’s real input cap. The result: the agent loops through reject → compact → reject because compaction can never fire successfully[reference:8].

   Workarounds for loops

   • Manually cancel any request that runs longer than a few seconds without a tool call or visible progress. Do not let it run.
   • Set a hard step limit in config (agentsteps or equivalent). OpenCode’s runner has an isLastStep guard, but it may not be enforced for all agents[reference:9].
   • Use a loop-detection plugin (e.g., anti-loop plugins) or the doom_loop permission check, which pauses when the same tool call repeats[reference:10].
   • If compaction loops are the issue, use the big-pickle-context-helper plugin, which filters @file references and avoids loading the entire context at once[reference:11].

   ---

   3. Root cause: silent quota exhaustion (no warning)

   Issue #41684 documents the user-experience failure mode: the free model goes silent during congestion, then when the user switches to paid models, quota drains with no in-app warning—the first signal is sessions stopping mid-task with Insufficient balance in the logs only[reference:12].

   There is no live quota meter, no low-quota warning, and no distinction between “rate limited” and “quota exhausted” in the UI.

   Workaround

   • Run opencode stats frequently to monitor token usage manually.
   • Check the local log at %LOCALAPPDATA%\.local\share\opencode\log\opencode.log (Windows) or the equivalent path on your OS for FreeUsageLimitError / Insufficient balance entries.
   • Treat any 429 or “Free usage exceeded” as a hard stop—do not retry repeatedly, as retries may consume additional quota or extend the cooldown.

   ---

   4. Root cause: header/identity mismatches trigger false 429s

   If you are using any client other than the official OpenCode CLI/Desktop, the gateway may reject requests with 429 FreeUsageLimitError even when quota is available.

   • HermesAgent with canonical headers gets 429, while the same request with User-Agent: opencode/... and a valid X-Session-ID gets 200[reference:13].
   • The omp client (oh-my-pi) gets 403 FreeTierError unless it sends both User-Agent: opencode/1.19.0 and a valid ses_... session ID[reference:14].
   • OpenCode Desktop itself has had mass regressions where the free tier rejects valid desktop requests (Error from provider (Console): OpenCode's free tier can only be used from within OpenCode (Desktop app v1.18.31) #49588)[reference:15].

   Workaround

   • Use the official OpenCode CLI or Desktop and ensure you are on the latest v2 build.
   • If using a third-party client, mimic the exact OpenCode headers:
     • User-Agent: opencode/<version>
     • X-Session-ID: <uuid> or x-opencode-session: ses_...
     • HTTP-Referer: https://opencode.ai/
     • X-Title: opencode

   ---

   5. Proposed fixes (prioritized for maintainers)

   P0 — Stop the bleeding

   1. Add a compaction circuit breaker. If compaction returns total=0 (or total < budget * 0.1) more than twice in a row, abort the session with a clear error instead of retrying indefinitely. This alone would prevent the 239-iteration / 104-compaction loops documented in Compaction returns total=0, causing infinite loop with max-steps guard #37871.
   2. Fix derive_limits() to respect limit.input. Clamp the compaction window to min(limit.context, limit.input - safety_margin) so BigPickle’s 160k input cap is honored and compaction cannot loop above the real endpoint limit.
   3. Add a text-narration loop detector. If the model emits N consecutive assistant turns with no tool calls and no user input, inject a forced tool-choice or terminate with a summary. This addresses [big-pickle] Agente entra en loop de texto sin emitir tool calls (se atasca narrando la acción a tomar) #46030 / subagent: infinite loop of identical tool calls for ~50min with no loop protection, uncontrollable token burn #45442.

   P1 — Make quota visible

   4. Live quota meter in the UI. Show requests used / remaining (or tokens used / remaining) for the current free-tier IP bucket. Update it after every turn.

   5. Low-quota warning at 20% and 5% remaining. Do not wait for the 429 to surface silently.

   6. Distinguish error classes. Return distinct error types for:

      • quota_exhausted (daily allowance gone)
      • rate_limit_exceeded (too many concurrent requests)
      • ip_bucket_exhausted (shared IP quota gone)

      The UI should show different remediation messages for each.

   P2 — Structural improvements

   7. Account-bucketed quota (or IP+account hybrid). IP-only bucketing is hostile to VPN/CGNAT users. Consider bucketing by account ID with a per-IP concurrency cap, rather than a per-IP token cap.
   8. Separate compaction model. Allow users to run interactive BigPickle but compact with a cheaper/free model. A PR already exists (feat: Switch compaction model from session model #15525) for a dedicated compaction model selector—merging and documenting this would let users avoid BigPickle compaction burn entirely[reference:16].
   9. Enforce maxSteps at the runner level. The isLastStep guard exists but may not be enforced for all agents. Add a hard default cap (e.g., 50 steps) and surface it in config.
   10. Document the free-tier accounting model. Clarify: Is the quota requests-based or token-based? Is it per IP or per account? What is the reset window? How does compaction count toward the quota? Community reports conflict (some say ~200 requests/day, others say ~0.3M–0.5M tokens/day)[reference:18].

   ---

   6. Immediate workarounds for affected users

   Symptom	Likely cause	Workaround
   Quota gone instantly even with few messages	IP-bucketed quota on shared IP	Disable VPN/proxy; test from mobile hotspot
   Model repeats “I will do X” without acting	Text narration loop	Cancel manually; set agentsteps limit; use anti-loop plugin
   Long pause then quota gone	Compaction loop (total=0)	Use big-pickle-context-helper; reduce file context; cancel long compaction runs
   “429” / “Free usage exceeded” after few messages	Header mismatch (third-party client)	Use official OpenCode v2 client; mimic OpenCode headers
   Model stuck “thinking” for minutes	Agentic loop / congestion	Check logs for repeated Rate limit exceeded; switch to another free model (mimo-v2.5-free, nemotron-3.5-lightning-free)
   Quota never resets after 24h	Extended cooldown bug (#50091 / #50093)	Check IP; some users report switching models extends timer—do not switch during cooldown

   ---

   7. Open questions for maintainers

   1. What is the exact free-tier limit for BigPickle—requests per day, tokens per day, or both?
   2. Is the quota per egress IP, per account, or a hybrid? If IP-bucketed, how are VPN/CGNAT users expected to use the free tier?
   3. Does compaction count against the free quota? If yes, why is compaction allowed to run indefinitely without a circuit breaker?
   4. Why does derive_limits() ignore limit.input for BigPickle, and is this fixed in v2?
   5. Are the text-narration and tool-call loops specific to BigPickle, or do they affect all reasoning models on the free tier?
   6. Can the 24-hour cooldown be reduced or made partial for users who hit the limit through loops rather than genuine usage?
5. opencodejr

   closed this as duplicateon Nov 2, 2026
6. opencodejr commented on Nov 2, 2026

   

   opencodejrBot

   on Nov 2, 2026

   More actions

   We haven't heard back, so I'm closing this as a duplicate of #59387, the main thread for free-tier usage limits like the Big Pickle quota running out and the ~24-hour reset.

   If you still see this on the latest OpenCode v2 (opencode --version), please comment on #59387 with your version, the free model, the exact error message or a screenshot, and the reset time you were shown. For the warning and usage-display ideas, see #42765 and #57540. For account-specific questions, email help@anoma.ly, and keep account details out of public issues. Thanks!
7. opencodejr

   reopened this on Nov 3, 2026
8. neriousy commented on Nov 4, 2026

   

   neriousy

   on Nov 4, 2026

   Member

   More actions

   Thanks for the report, and sorry for the trouble!

   We're tracking all free-tier quota and limit problems in one place: the pinned issue #59387. Please read it first. Most of these reports are fixed by updating to the latest OpenCode v2 (Desktop v1 users can download it from https://opencode.ai/v2/docs).

   If you're on the latest v2 and still hitting this, please add your details there: OpenCode version, OS, model, and the exact error or reset time shown. Keeping everything in one thread helps us find the cause faster.

   Closing as a duplicate of #59387.
9. neriousy

   closed this as a duplicateof Free tier issues: read this first, then post your report here #59387 on Nov 4, 2026