OpenCode Free Limit Reached: इंतज़ार करें या काम जारी रखें
OpenCode के Free limit reached और free 429 के लिए एक व्यावहारिक निर्णय-पथ: सक्रिय provider और model पहचानें, reset समय का अनुमान न लगाएँ, फिर इंतज़ार, उपलब्ध model या स्वतंत्र provider चुनकर छोटे अनुरोध से परिणाम जाँचें।
विषय-सूची

OpenCode में Free limit reached या HTTP 429 दिखने का अर्थ यह नहीं है कि हर free model एक तय दैनिक समय पर reset होता है। पहले मूल error सुरक्षित रखें, सक्रिय provider और model की पुष्टि करें, और केवल वही reset संकेत मानें जो मौजूदा response या account में वास्तव में दिखाई देता है।
विश्वसनीय reset समय न मिले तो तीन व्यावहारिक विकल्प हैं: इंतज़ार करना, /models में अभी उपलब्ध दूसरा model चुनना, या स्पष्ट रूप से अलग billing वाले provider पर जाना। लंबा coding task दोबारा शुरू करने से पहले एक छोटा, non-destructive request भेजें और response, चुना हुआ provider/model, तथा provider-side usage जाँचें।
Error देखकर सही branch चुनें
| क्या दिखाई देता है | संभावित कारण | पहला कदम |
|---|---|---|
Free limit reached या body में FreeUsageLimitError, लेकिन countdown नहीं | Free-tier limit | तय cycle न मानें; समय दर्ज करें, इंतज़ार करें या /models में अभी उपलब्ध models देखें |
Go limit reached और वास्तविक countdown | OpenCode Go का paid-usage window | उसी account पर दिखे समय को मानें; उसे free models पर लागू न करें |
सामान्य 429, Too Many Requests या Provider is overloaded | Provider rate limit, capacity या अस्थायी failure | Raw response रखें, provider/model जाँचें, बाद में retry करें और provider status देखें |
401, 404 या Model not available | Authentication, Base URL या Model ID समस्या | reset का इंतज़ार न करें; credential, endpoint या model config ठीक करें |
एक ही HTTP status के कई कारण हो सकते हैं। केवल 429 देखकर यह तय नहीं किया जा सकता कि free quota खत्म हो गया है; यह provider throttling या temporary overload भी हो सकता है।
बदलने से पहले चार चीजें सुरक्षित रखें
- पूरा error text, केवल “429” नहीं।
- चुना हुआ
providerऔरmodel, बेहतर हैproviderId/modelIdरूप में। - उपलब्ध response body, error type, headers और
retry-after, यदि client सचमुच दिखाता है। - Failure का समय और time zone, project directory, और यह कि आप free Zen, Go या custom provider पर थे।
OpenCode Zen documentation के अनुसार TUI में /models चलाकर चुनी हुई entry और अभी सूचीबद्ध models देखें। Terminal में opencode models भी चला सकते हैं। किसी पुराने screenshot या guide से यह न मानें कि कोई free model आज भी उपलब्ध है; model list बदल सकती है।
Config precedence भी जाँचें। OpenCode configuration documentation के अनुसार OpenCode कई configuration sources को merge करता है, और project-level opencode.json global setting को override कर सकता है। Global config में model A होना यह सिद्ध नहीं करता कि मौजूदा repository भी model A इस्तेमाल कर रही है। Current project, /models selection और resolved config को आधार बनाएँ।
केवल वास्तविक reset समय पर भरोसा करें
यदि वर्तमान error में भरोसेमंद countdown या absolute time नहीं है, तो “कुछ घंटे बाद”, “कल” या “अगले सप्ताह” जैसा अनुमान न लगाएँ।
इस guide के लिए 2026-10-10 को खोले और जाँचे गए OpenCode dev branch के retry.ts snapshot में FreeUsageLimitError static free-limit message branch में जाता है, जबकि GoUsageLimitError retry-after response header पढ़कर countdown बनाता है। यह source-code snapshot की जाँच है, आपके installed version या account का runtime test नहीं।
Public feature requests #53252 और #52894 में exact reset time के उदाहरण दिए गए हैं, लेकिन वे प्रस्ताव समझाने वाले sample हैं, वास्तविक free-tier schedule नहीं। किसी issue का closed होना भी यह सिद्ध नहीं करता कि change आपके client version तक पहुँच गया है।
2026-10-10 को खोली गई OpenCode Go documentation paid usage के लिए 5-hour, weekly और monthly windows अलग से बताता है। इन Go windows को free model reset का प्रमाण नहीं माना जा सकता।
यह नियम अपनाएँ:
- Countdown या exact time दिखता है: पूरा text, time zone और provider सुरक्षित रखें, फिर उसी समय के आसपास एक retry करें।
- Reset time नहीं दिखता: समय को unknown मानें, तेज़ लगातार retry न करें, और किसी दूसरे plan का window न लगाएँ।
- केवल सामान्य 429 दिखता है: पहले provider throttling या overload की जाँच करें, जब तक evidence free-tier limit न बताए।
विकल्प 1: वही free model चाहिए तो इंतज़ार करें
जब task urgent न हो, अलग API खर्च न चाहिए, और error स्पष्ट रूप से free-tier cap बताए, तब इंतज़ार सबसे सरल विकल्प है।
- Last failure time और raw error लिखें।
- लगातार retry रोकें, ताकि quota और transient throttling एक साथ न मिलें।
- विश्वसनीय timer हो तो उसी के आसपास retry करें। Timer न हो तो अपने लिए स्वीकार्य interval पर जाँचें, लेकिन fixed cycle का दावा न करें।
- बहुत सारी files पढ़ने या बदलने वाला task शुरू करने से पहले छोटा request चलाएँ।
Success का अर्थ केवल “OpenCode खुल गया” या process का exit code 0 नहीं है। चुने हुए model से वास्तविक response आना चाहिए और मूल error तुरंत दोहरना नहीं चाहिए।
विकल्प 2: /models में अभी उपलब्ध दूसरा model चुनें
यदि काम जारी रखना है लेकिन वही model आवश्यक नहीं है, तो वह दूसरी entry चुनें जो आपके account में अभी दिखाई देती हो और अपेक्षित provider से accessible हो।
Switch करने से पहले जाँचें:
- model current list में है, केवल पुराने tutorial में नहीं;
- entry अपेक्षित
providerकी है, ताकि model बदलना चुपचाप account या billing बदलना न बन जाए; - model task के लिए ठीक है—repository edits की अनुमति देने से पहले छोटे tool-use या code-understanding request से जाँचें।
Model switch सफलता की guarantee नहीं है। दूसरे free model का अपना limit, regional restriction, temporary removal या capacity issue हो सकता है। सही सलाह है “अभी उपलब्ध model चुनकर verify करें,” न कि “कोई भी free model बदलते ही काम चल जाएगा।”
विकल्प 3: अलग billing वाला provider स्पष्ट रूप से चुनें
Deadline हो, अलग API usage स्वीकार्य हो, और आगे के requests को Zen free allowance से अलग करना हो तो custom provider चुनें। यह free quota का reset नहीं है; बाद के calls अलग account, API Key और usage record से जाते हैं।
OpenCode provider documentation custom OpenAI-compatible provider को support करती है। Minimum flow:
/connectचलाएँ,Otherचुनें, unique provider ID दें और credential prompt में API Key सुरक्षित करें।opencode.jsonमें वही provider ID, सही Base URL और वास्तविक Model ID configure करके file save करें।- नई configuration जाँचने से पहले OpenCode को पूरी तरह बंद करके उसी project में फिर शुरू करें; पहले से खुली TUI नए provider को hot-reload कर लेगी, ऐसा न मानें। पुराने task context की जरूरत हो तो project directory और वापस जाने वाले task या session को नोट करें, फिर restart के बाद अपने environment में उपलब्ध सुरक्षित workflow से उसी context पर लौटें।
- Restart के बाद
/modelsचलाएँ, नई entry दिखने से config load होना confirm करें, फिर display name के बजाय exactproviderId/modelIdचुनें। - Files न बदलने का स्पष्ट निर्देश वाला छोटा request भेजें और वास्तविक नया model response मिलने की पुष्टि करें।
- Target provider के request log, usage record या balance change में उसी request की entry देखकर पुष्टि करें कि वही provider इस्तेमाल हुआ। Corresponding evidence न मिले तो switch को verified न कहें।
BetterToken इस independent route का एक विकल्प है। 2026-10-10 को खोली गई इसकी OpenCode setup documentation Base URL https://www.bettertoken.ai/v1 और bettertoken/YOUR_MODEL_ID जैसा model reference बताती है। Base URL में /chat/completions न जोड़ें, और top-level model को models में घोषित वास्तविक ID से बिल्कुल मिलाएँ।
Boundary स्पष्ट है: BetterToken Zen free allowance नहीं देता और OpenCode/Zen limit reset नहीं करता। यह हर 429 से बचने की guarantee नहीं है, और समान usage comparison के बिना इसे अपने-आप सस्ता नहीं कहा जा सकता। यह केवल एक स्पष्ट, अलग API route है।
एक छोटे request से recovery सत्यापित करें
इंतज़ार, model change या provider change—हर स्थिति में एक ही acceptance test करें:
- Interface में चुना हुआ
provider/modelफिर देखें। - ऐसा request भेजें जो केवल
READYशब्द लौटाने को कहे और files न बदलने की स्पष्ट हिदायत दे। - Response और समय सुरक्षित रखें; यह नया model response हो, केवल config acceptance या cached output नहीं।
- Independent provider होने पर उसके usage record, request log या balance में छोटा corresponding change देखें। Provider ऐसा evidence न दिखाए तो billing verified होने का दावा न करें।
- मूल error दोबारा न आए तो असली task पर लौटें और पहले उसका सबसे छोटा meaningful step चलाएँ।
Valid PASS में तीन बातें एक साथ चाहिए: वास्तविक response, अपेक्षित provider/model, और provider-side usage evidence। Config parse होना, client launch होना या clean exit code अकेले पर्याप्त नहीं है।
छोटा request भी fail हो तो
नई error branch के अनुसार चलें; सारे fixes बार-बार न दोहराएँ:
- वही
Free limit reached: allowance अभी वापस नहीं आया हो सकता है, या selection वास्तव में नहीं बदला।/modelsऔर project config फिर जाँचें। 401: उस provider के credential की पुष्टि करें।opencode auth listचलाएँ और ज़रूरत हो तो/connectदोहराएँ।404याModel not available: Base URL, Model ID औरproviderId/modelIdजाँचें, फिरopencode modelsसे current access देखें।- सामान्य
429या overload: इसे provider throttling मानकर retry frequency घटाएँ और provider status देखें; इसे Zen free-limit समस्या न मानें। - Error अधूरा है: OpenCode troubleshooting guide से logs देखें और timestamp, provider, model, status तथा redacted response body के साथ report करें।
API Key को issue, screenshot या chat में paste न करें। Useful error details रखें, लेकिन authorization headers, tokens और अन्य credentials हटाएँ।
सामान्य प्रश्न
क्या OpenCode free allowance रोज़ एक तय समय पर reset होता है?
ऐसा कोई भरोसेमंद first-party आधार नहीं है कि सभी free models एक ही daily, weekly या monthly cycle साझा करते हैं। Current request में दिखा समय ही मानें; समय न दिखे तो उसे unknown मानें।
क्या हर 429 free allowance खत्म होने का संकेत है?
नहीं। यह सामान्य provider rate limit, concurrency limit या overload भी हो सकता है। provider, model, response body और error type साथ देखकर निर्णय लें।
क्या OpenCode Go subscribe करना ही एकमात्र रास्ता है?
नहीं। आप इंतज़ार कर सकते हैं, अभी उपलब्ध दूसरा model चुन सकते हैं, या independent provider इस्तेमाल कर सकते हैं। Go अलग paid plan है और उसके windows free-model reset का evidence नहीं हैं।
BetterToken चुनने से free limit clear हो जाएगा?
नहीं। यह अपने API Key, Base URL, Model ID और usage accounting वाला independent provider route है। Zen free allowance की स्थिति नहीं बदलती।
निष्कर्ष
Free limit reached का समाधान reset cycle का अनुमान लगाना नहीं है। वास्तविक provider/model पहचानें, केवल दिखे reset संकेत पर भरोसा करें, और urgency के अनुसार इंतज़ार, /models में अभी उपलब्ध model, या अलग billing वाला provider चुनें। मूल task पर लौटने से पहले छोटे response और provider-side usage से recovery सिद्ध करें।