जब Claude Code बताता है कि कोटा (quota) खत्म हो गया है, तो “रीसेट का इंतज़ार करना” और “बड़ा प्लान खरीदना” ही दो विकल्प नहीं हैं।
अगर आप Claude Code के साथ Codex या OpenCode जैसे टूल्स भी इस्तेमाल करते हैं, तो कुछ और भी दिक्कतें आ सकती हैं: हर Agent की मॉडल कॉन्फ़िगरेशन अलग-अलग करनी पड़ती है, रूट खराब होने पर चलता काम बीच में अटक जाता है, और महीने के आख़िर में पता ही नहीं चलता कि किस काम ने कितने टोकन (token) खर्च किए।
यह लेख तीन सवालों के जवाब देता है: आपको जो गड़बड़ दिख रही है वह कोटा खत्म होना है, rate limiting है या configuration error; कई मॉडल को एक जगह से जोड़ने और backup रूट सेट करने के लिए API gateway को कैसे इस्तेमाल करें; और हर सेशन की खपत व अनुमानित लागत की जाँच-पड़ताल कैसे करें।
निचोड़ पहले: अगर आपके पास एक ही ऑफ़िशियल अकाउंट है और कॉल की मात्रा कम है, तो ऑफ़िशियल चैनल आम तौर पर आसान रहता है। API gateway तब सार्थक होता है जब आपको कई मॉडल को एक साथ जोड़ना हो, बिल एक जगह देखने हों, या अनुमति वाले upstream रूट्स पर failover सेट करना हो।
1. पहले पक्का करें: कोटा खत्म है, rate limit लगा है, या configuration गलत है
“request failed” दिखते ही तुरंत relay सर्विस बदल लेना अक्सर मामले को और उलझा देता है। अलग-अलग error का इलाज अलग-अलग होता है।
| आम लक्षण | संभावित कारण | पहले क्या करें |
|---|---|---|
| साफ़ लिखा हो quota, usage limit या credit exhausted | प्लान का कोटा, usage window या अकाउंट बैलेंस खत्म | रीसेट समय या बैलेंस देखें; अनुमति वाला backup रूट इस्तेमाल करें |
| HTTP 429 आए | rate limiting भी हो सकता है, कोटा खत्म भी | पूरा error message और Retry-After पढ़ें; सिर्फ़ status code से फैसला न करें |
| HTTP 401 या 403 आए | Key अमान्य, permissions कम, या लॉगिन स्थिति खराब | Key, अकाउंट permissions और endpoint URL जाँचें |
| Request timeout या connection fail | नेटवर्क, DNS, proxy या upstream में गड़बड़ | रूट बदलने से पहले कनेक्टिविटी और सर्विस स्टेटस टेस्ट करें |
| मॉडल मौजूद नहीं या parameter सपोर्ट नहीं | मॉडल का नाम, प्रोटोकॉल या parameter में बेमेल | मॉडल लिस्ट और API डॉक्युमेंटेशन से मिलान करें |
कुछ rate limits कुछ ही देर में अपने आप ठीक हो जाते हैं; बार-बार रूट बदलने से failed request और बढ़ सकते हैं। असल में काम की बात यह है कि आपको पता हो आपके पास कितने रूट उपलब्ध हैं, कब बदलना है, और बदलने के बाद मौजूदा काम पूरा हो सकेगा या नहीं।
2. API gateway क्या कर सकता है, क्या नहीं
API gateway (relay सर्विस) आपके agents और मॉडल प्रोवाइडर्स के बीच की एक interface परत है। Agents request gateway को भेजते हैं, और gateway उसे कॉन्फ़िगर किए गए upstream मॉडल तक पहुँचाता है।
आम तौर पर यह चार कामों के लिए फ़िट है:
- Unified access: सभी agents एक ही Base URL, एक मॉडल लिस्ट और एक usage रिकॉर्ड इस्तेमाल करें।
- Failover: retry शर्तें पूरी होने पर मौजूदा रूट से backup रूट पर स्विच करना।
- Model routing: priority क्रम, कोटा स्थिति या काम के प्रकार के हिसाब से मॉडल चुनना।
- Cost tracking: टोकन, cache, request संख्या और खर्च एक ही जगह देखना।
यह हवा से ऑफ़िशियल कोटा नहीं बना सकता, और जिस मॉडल में image, tool calling या लंबा context नहीं है वहाँ ये क्षमतांएँ अचानक पैदा नहीं कर सकता। output शुरू होने के बाद टूटा स्ट्रीम दूसरे मॉडल पर बिना किसी निशान के जारी भी नहीं रखा जा सकता।
कंज़्यूमर सब्सक्रिप्शन अकाउंट्स का पूल बनाना, cookie साझा करना या अनजान स्रोत की key इस्तेमाल करना अकाउंट सुरक्षा और upstream की शर्तों के हिसाब से जोखिम भरा है। सर्विस चुनने से पहले पक्का करें कि मॉडल और API एक्सेस वैध हैं और आप अनुमति वाले upstream रूट ही इस्तेमाल कर रहे हैं।
3. कई agents हों तो बार-बार configuration से कैसे बचें
Claude Code, Codex और OpenCode का configuration फ़ॉर्मैट एक जैसा नहीं है। कुछ मॉडल जुड़ते ही Base URL, API key और मॉडल नाम अलग-अलग फ़ाइलों में बिखर जाते हैं।
gateway से सब कुछ जोड़ने के बाद आप मॉडल सप्लाई को केंद्र में रखते हैं और हर agent को उसका endpoint दे देते हैं। आम प्रक्रिया:
- gateway में अपनी API key बनाएँ और usage सीमा सेट करें।
- देखें कि सर्विस असल में कौन-कौन से प्रोटोकॉल, मॉडल नाम और Base URL सपोर्ट करती है।
- Agent का configuration भरें और वापस लौटने के लिए पुरानी कॉपी रख लें।
- असली काम चालू करने से पहले एक न्यूनतम टेस्ट request भेजें।
- Usage पेज पर जाँचें कि यह request सही तरीके से रिकॉर्ड हुई या नहीं।
Anthropic environment variables सपोर्ट करने वाले clients के लिए configuration आम तौर पर ऐसा होता है:
export ANTHROPIC_BASE_URL="आपकी सर्विस जो endpoint URL असल में देती है"
export ANTHROPIC_AUTH_TOKEN="आपकी खुद की बनाई हुई API key"हर client में variable के नाम, प्रोटोकॉल और auth का तरीका अलग हो सकता है, इसलिए अपने client और gateway दोनों के मौजूदा दस्तावेज़ों को ही मानें। लोकल gateway पते को production relay endpoint समझने की ग़लती न करें, और असली key कभी screenshot, log या सार्वजनिक लेख में न चिपकाएँ।
सिर्फ़ थोड़ी देर ट्राई करना हो तो variables को एक अलग terminal session में सेट करें, permanent config फ़ाइलों में लिखने की ज़रूरत नहीं। सब काम करने की पुष्टि के बाद ही तय करें कि save रखने हैं या नहीं।
4. Failover का मतलब सिर्फ़ “ज़्यादा अकाउंट जमा करना” नहीं है
असली failover कुछ ठोस सवालों के जवाब देता है:
- कौन-कौन से error पर retry करना चाहिए, और किन्हें सीधे fail होना चाहिए?
- मौजूदा रूट बंद होने पर अगला रूट किस क्रम में चुना जाता है?
- एक ही सेशन अपना मॉडल और रूट बनाए रखता है या नहीं, ताकि context या reasoning फ़ॉर्मैट में बेमेल न हो?
- client को content भेजना शुरू करने के बाद स्ट्रीम टूट जाए तो सिस्टम क्या करता है?
- क्या retry से duplicate request या अतिरिक्त शुल्क बन सकते हैं?
आम routing तरीके:
- Primary/backup: पहले primary रूट; स्विच की शर्त पूरी होने पर backup रूट।
- Round-robin: उपलब्ध रूट्स के बीच request का घूमाकर बँटवारा।
- Least-usage: जिस रूट की मौजूदा खपत सबसे कम हो उसे पहले चुनें।
- Quota-window scheduling: बचे हुए कोटा और रीसेट समय के हिसाब से रूट की योजना।
- Task intent: जटिल कोडिंग ज़्यादा सक्षम मॉडल को, छोटे बदलाव तेज़ या सस्ते मॉडल को भेजना।
लंबे कामों के लिए ज़्यादा रूट होना स्थिरता की गारंटी नहीं है। ज़्यादा अहम है कि error handling साफ़-साफ़ परिभाषित हो, आपके प्रोटोकॉल और tool calls सपोर्ट हों, और request के traceable लॉग मौजूद हों।
5. हर काम का खर्च कैसे निकालें
Cost tracking कम से कम input token, output token, cache read, cache write और reasoning token अलग-अलग गिने, और price स्रोत व डेटा का समय भी बताए।
मान लीजिए किसी काम ने 1 मिलियन input token और 100K output token खर्च किए, input की कीमत X प्रति मिलियन token और output की कीमत Y प्रति मिलियन token है। cache और दूसरे शुल्कों को छोड़ते हुए अनुमान यह है:
cost = (100 ÷ 100) × X + (10 ÷ 100) × Yअसली बिल मिलाने के वक़्त ये बातें भी पक्की करें:
- input और output की per-unit कीमत अलग है या नहीं;
- cache read और write का बिल अलग से बनता है या नहीं;
- reasoning token output में गिने जाते हैं या नहीं;
- failed request और automatic retry का बिल कैसे बनता है;
- service fee, currency spread या मॉडल multiplier लगता है या नहीं;
- पेज पर असली charge दिख रहा है या list price के हिसाब से अनुमान।
सब्सक्रिप्शन प्लान और API का pay-as-you-go अलग-अलग हिसाब-किताब हैं। relay सर्विस जो “सेशन कॉस्ट” दिखाती है, वह ज़रूरी नहीं कि उस काम के लिए आपके बैंक से निकला असली पैसा हो। records export करके एक-एक entry मिलाने की सुविधा, सिर्फ़ कुल बैलेंस देखने से ज़्यादा काम की है।
6. Relay सर्विस चुनने से पहले ये 7 चीज़ें देखें
1. मॉडल और प्रोटोकॉल की असली compatibility. सिर्फ़ मॉडल के नाम पर मत चलें: streaming, tool calling, image, reasoning parameters और context लंबाई आपके काम के मुताबिक हैं या नहीं, पक्का करें।
2. कीमत जिसका हिसाब लग सके. पूरी price table में input, output, cache, multiplier, service fee और refund नियम हों — सिर्फ़ “सबसे तक X% छूट” नहीं।
3. पारदर्शी failure handling. कौन-कौन से error retry होते हैं, switch की सीमा कहाँ है, और maintenance इतिहास के साथ status page है या नहीं — यह सब जान लें।
4. Request और लॉग का भंडारण. prompt, response, IP, key और request लॉग में क्या-क्या सेव होता है, कितनी देर तक, और कौन पहुँच सकता है — जाँचें।
5. Key पर limits और revocation. ऐसी सर्विस चुनें जिसमें अलग key, कोटा सीमा, per-key मॉडल permissions और कभी भी revocation की सुविधा हो।
6. Usage की जाँच की सुविधा. सबसे अच्छा हो कि मॉडल, key, सेशन और request के हिसाब से रिकॉर्ड देखे जा सकें और export भी हो सके।
7. गड़बड़ी के वक़्त कोई मिले. Terms of service, संचालक संस्था, support चैनल, maintenance सूचनाएँ और refund प्रक्रिया — सब आसानी से मिलने चाहिए।
ये बातें “पूरे नेट में सबसे सस्ता”, “कभी बैन नहीं होगा”, “बिल्कुल stable” जैसे दावों से ज़्यादा अहम हैं। जिन वादों को सत्यापित नहीं किया जा सकता, वे फैसले की बुनियाद नहीं बनने चाहिए।
7. कब relay सर्विस की ज़रूरत ही नहीं
अगर आप एक agent और एक ऑफ़िशियल अकाउंट से काम चलाते हैं, कोटा बचा-खचा है, और मॉडलों के पार कॉल करने की ज़रूरत नहीं, तो सीधे ऑफ़िशियल चैनल से जाने पर बीच की एक परत हट जाती है।
अगर आपको बस कभी-कभार थोड़ी देर का rate limit दिखता है, तो रीसेट समय और सर्विस स्टेटस देखना ही मुश्किल हल कर सकता है।
API gateway की कीमत यह है कि वह कई मॉडल, कई टूल्स और कई रूट्स की मैनेजमेंट लागत घटाता है। यह सार्थक है या नहीं, यह आपकी कॉल मात्रा, स्थिरता की ज़रूरत, डेटा की संवेदनशीलता, और सेवा देने वाला अपनी कीमत और रनटाइम रिकॉर्ड कितनी साफ़-साफ़ समझा पाता है — इस पर निर्भर है।
आख़िर में जुड़ने से पहले थोड़े balance और किसी ग़ैर-संवेदनशील प्रोजेक्ट से टेस्ट करें: एक न्यूनतम request पास कराएँ, एक बिल की मिलान करें, और primary रूट डाउन होने की स्थिति एक बार simulate करें। जब तीनों बातें समझ में आ जाएँ, तब इसे असली काम में लगाने का विचार करें।