Kimi K3.1 Pro कोटा रीसेट: 25% वापसी और API बिलिंग

घोषित Kimi K3.1 Pro कोटा रीसेट से आपकी सदस्यता के मासिक कोटे में अधिकतम 25 प्रतिशत अंक वापस मिलते हैं; इसमें हर रेट लिमिट हटाने का वादा नहीं है। पहले मासिक उपयोग का मीटर देखें, फिर कोडिंग अनुरोध विफल होने पर Kimi Code की अलग उपयोग अवधि की सीमा जाँचें। यदि काम इंतज़ार नहीं कर सकता, तो उपयोग के हिसाब से भुगतान वाला API विकल्प अपनाया जा सकता है, जिसकी कुंजी, एंडपॉइंट, बैलेंस, सीमाएँ और बिलिंग अलग हैं।

Moonshot ने 25 अक्टूबर की घोषणा में K3.1 Pro सदस्यता प्लान पर रेट लिमिट और अनावश्यक कोटा खपत की ज़िम्मेदारी स्वीकार की। कंपनी ने सभी प्लान के ग्राहकों को कोटा लौटाने और अनावश्यक सबएजेंट कॉल तथा आउटपुट की लंबाई घटाने के लिए बदलावों की घोषणा की।

नीचे दिए गए नियम उस घोषणा और 2026-10-26 तक जाँचे गए आधिकारिक दस्तावेज़ों पर आधारित हैं।

25% रीसेट से कितना कोटा वापस मिलता है?

घोषणा के अनुसार, मासिक उपयोग में से 25 प्रतिशत अंक घटाए जाते हैं और इस्तेमाल का आँकड़ा शून्य से नीचे नहीं जाता। मासिक कोटा समान रहने पर, बीच में कोई नया उपयोग या बिलिंग चक्र का निर्धारित रीफ़्रेश न हुआ हो, तो गणना यह है:

used_after = max(0, used_before - 25)

इसे बचे हुए कोटे के रूप में ऐसे लिख सकते हैं:

remaining_after = min(100, remaining_before + 25)

यहाँ हर मान पूरे मासिक कोटे का प्रतिशत है।

पहले इस्तेमाल हुआ मासिक कोटा	समायोजन के बाद अपेक्षित उपयोग	अपेक्षित बचा हुआ कोटा
18%	0%	100%
25%	0%	100%
60%	35%	65%
100%	75%	25%

ये गणना के उदाहरण हैं, किसी खाते में देखे गए परिणाम नहीं। जिसने 25% से कम कोटा इस्तेमाल किया था, उसे केवल उतना इस्तेमाल हुआ हिस्सा वापस मिलता है; इस फ़ॉर्मूले से बचा हुआ कोटा 100% से अधिक नहीं होता।

प्रतिशत और प्रतिशत अंक का अंतर यहाँ ज़रूरी है। 60% उपयोग को उसी उपयोग के 25% से घटाने पर 45% उपयोग बचता। घोषित समायोजन के बाद, इसके बजाय, इस्तेमाल हुआ हिस्सा 35% रहता है।

Moonshot ने लौटाई जा रही मात्रा को एक सप्ताह के उपयोग के बराबर बताया। इससे मुआवज़े का आकार समझ में आता है; यह एक सप्ताह तक कोडिंग की गारंटी, नया साप्ताहिक रीसेट चक्र या सदस्यता के अतिरिक्त दिन नहीं देता। अपने सामान्य बिलिंग चक्र के लिए सदस्यता पेज पर दिखाया गया अगला रीफ़्रेश समय देखें।

25 अक्टूबर की घोषणा में उपयोग बार अपडेट होने की समयसीमा “end of day PST”, यानी PST के अनुसार दिन के अंत तक, दी गई थी। उस समयसीमा के बाद खाते का मीटर जाँचें; केवल घोषणा से यह साबित नहीं होता कि आपके खाते में समायोजन हो चुका है।

क्या Kimi सदस्यता, Kimi Code और API कुंजियाँ एक ही कोटा इस्तेमाल करते हैं?

Kimi सदस्यता और Kimi Code एक ही मासिक सदस्यता कोटा इस्तेमाल करते हैं, जबकि सार्वजनिक Kimi API Platform की उपयोग के हिसाब से अलग बिलिंग होती है। API कुंजी इन दोनों में से किसी भी व्यवस्था की हो सकती है। इसलिए सिर्फ़ कुंजी होने से यह पता नहीं चलता कि किस कोटे से खपत हो रही है।

सदस्यता उपयोग नियम बताते हैं कि सदस्यता की सुविधाएँ एक ही क्रेडिट पूल से खर्च करती हैं, जिसकी खपत टोकन के आधार पर मापी जाती है। Kimi Code इस मासिक कोटे के अलावा छोटी उपयोग अवधियों की सीमाएँ भी लागू करता है।

मौजूदा Kimi Code सदस्यता गाइड नए और पुराने प्लान में यह अंतर बताती है:

Kimi Code उपलब्ध कराने वाले प्लान	पाँच घंटे की रोलिंग सीमा	साप्ताहिक सीमा	साझा मासिक कोटा
नए Plus, Pro, Max और Ultra	लागू	लागू नहीं	लागू
पुराने Andante, Moderato, Allegretto और Allegro	लागू	लागू	लागू

पुराने प्लान का साप्ताहिक कोटा सदस्यता की तारीख से हर सात दिन में रीफ़्रेश होता है। दोनों समूहों के अनुरोध मासिक कुल कोटा खत्म होने पर भी रुक सकते हैं। Go में Kimi Code शामिल नहीं है; K3.1 Pro के लिए नया Plus या उससे ऊपर का प्लान, अथवा पुराना Moderato या उससे ऊपर का प्लान चाहिए।

इसलिए यह कहना कि Kimi में कोई साप्ताहिक सीमा नहीं है, अधूरा है। यह बात कोडिंग सुविधा वाले नए प्लान पर लागू होती है, हर मौजूदा सदस्यता पर नहीं। मासिक कोटा लौटने से यह भी साबित नहीं होता कि खत्म हो चुकी पाँच घंटे की सीमा या पुराने प्लान की साप्ताहिक सीमा रीसेट हो गई है।

Kimi Code के CLI, Desktop, VS Code और समर्थित थर्ड-पार्टी क्लाइंट से भेजे गए अनुरोध उसी खाते के उपलब्ध कोटे का इस्तेमाल करते हैं। नई Code API कुंजी बनाने या Claude Code से OpenCode पर जाने से नया सदस्यता कोटा नहीं मिलता। यदि Extra Usage चालू है, तो सदस्यता की इसी बिलिंग व्यवस्था के ज़रिए अतिरिक्त भुगतान करके काम जारी रखा जा सकता है।

इसके विपरीत, Moonshot के API मूल्य दस्तावेज़ सार्वजनिक API Platform को स्पष्ट रूप से उपयोग के हिसाब से भुगतान वाली सेवा बताते हैं, जो सदस्यता और Kimi Code से अलग है। रीसेट की घोषणा उस अलग API खाते में रिफंड, बैलेंस क्रेडिट या रेट लिमिट रीसेट की पुष्टि नहीं करती।

इन उपयोग अवधियों का विस्तार Kimi Code की सीमाएँ: पाँच घंटे, पुराने प्लान का साप्ताहिक कोटा, मासिक कोटा और 429 त्रुटियाँ में दिया गया है। उस लेख में कोटा संबंधी त्रुटियों के स्टेटस कोड मौजूदा आधिकारिक संदर्भ से अलग हैं; अनुरोध की समस्या जाँचते समय नीचे दिए गए वर्तमान कोड इस्तेमाल करें।

बदलाव के बाद भी कोटा कहाँ खर्च होता है?

मॉडल का उपयोगी काम अब भी टोकन खर्च करता है, जिसमें सबएजेंट का काम भी शामिल है। Moonshot की घोषणा अनावश्यक कॉल और आउटपुट की लंबाई कम करने की बात करती है; सबएजेंट को काम सौंपना या लंबे जवाब लेना मुफ़्त नहीं हो जाता।

Kimi के सबएजेंट दस्तावेज़ के अनुसार, हर सबएजेंट अपने स्वतंत्र संदर्भ में काम करता है और अलग से मॉडल टोकन खर्च करता है। इसलिए काम बाँटने से अतिरिक्त इनपुट और आउटपुट जुड़ सकते हैं, खासकर जब कई एजेंट एक ही सामग्री के हिस्से पढ़ते हों। छोटे काम को मुख्य एजेंट कम कॉल में पूरा कर सकता है।

खपत जाँचते समय सीमित दायरे वाला काम चुनें। उदाहरण के लिए, रिपॉज़िटरी खुले होने पर कोडिंग क्लाइंट में यह प्रॉम्प्ट डालें:

Read this repository's README and test configuration.
Identify the command for running its existing tests.
Work in the main agent without spawning subagents.
Do not modify files or run tests.
Answer in at most 100 words, citing the files that establish the command.
If no test command is documented, say so.

इससे ऐसा नतीजा मिलता है जिसे आप जाँच सकते हैं: रिपॉज़िटरी के टेस्ट चलाने की कमांड और उसे साबित करने वाली फ़ाइलों के स्थान। पूरे प्रोजेक्ट की समीक्षा जैसे व्यापक अनुरोध के मुकाबले, इस सीमित काम में अनावश्यक रूप से सबएजेंट इस्तेमाल किए जाने को पहचानना भी आसान होता है।

यह प्रॉम्प्ट निर्देश देता है, खर्च की कठोर सीमा लागू नहीं करता। क्लाइंट की गतिविधि में देखें कि उसने सबएजेंट को काम सौंपा या नहीं, और दर्ज खपत के आधार पर परिणाम का मूल्यांकन करें। केवल स्क्रीन पर छोटा जवाब दिखने से कुल उपयोग कम होने का प्रमाण नहीं मिलता।

अलग-अलग रन की तुलना करते समय मॉडल और रीज़निंग सेटिंग समान रखें। मॉडल कॉन्फ़िगरेशन गाइड के अनुसार, मॉडल या रीज़निंग का स्तर बदलने से संदर्भ का कैश अमान्य हो सकता है और खपत बढ़ सकती है। इसमें यह भी दर्ज है कि k3.1-pro-highspeed, सामान्य k3.1-pro के मुकाबले लगभग दोगुना कोटा इस्तेमाल करता है। इसलिए खपत की तुलना के लिए सामान्य मॉडल चुनें, जब तक गति आपकी मुख्य ज़रूरत न हो।

रीज़निंग (Thinking) चालू रखें: K3.1 Pro इसे बंद करने वाले अनुरोध अस्वीकार करता है। अंतिम जवाब की लंबाई घटाना और रीज़निंग बंद करना अलग नियंत्रण हैं।

रीसेट और कम खपत की जाँच कैसे करें?

कोटा वापसी और नए काम की खपत अलग-अलग जाँचें। दोनों को एक ही बार मापने से तस्वीर अस्पष्ट हो सकती है: लौटाया गया क्रेडिट मीटर घटाता है, जबकि उसी समय चल रहा दूसरा एजेंट उसे बढ़ाता है।

1. सही मीटर दर्ज करें। Kimi के वेब इंटरफ़ेस में अपना अवतार → Settings → Subscription खोलें। प्लान, दिखाया गया प्रतिशत इस्तेमाल हुए या बचे हुए कोटे में से किसका है, अगला रीफ़्रेश समय और रिकॉर्ड की तारीख व समय, समय क्षेत्र के साथ, लिखें। Kimi Code में /usage भी चलाएँ और Console में छोटी उपयोग अवधियों की स्थिति देखें।

2. बाकी गतिविधि रोककर समायोजन की तुलना करें। जाँच के दौरान सदस्यता कोटा खर्च करने वाले दूसरे सत्र रोकें। यदि आपके पास समायोजन से पहले का रिकॉर्ड है, तो अपडेट दिखने के बाद ऊपर दिए फ़ॉर्मूले से उसकी तुलना करें। बीच में हुए काम या सामान्य मासिक रीफ़्रेश का हिसाब रखें; पुराने रिकॉर्ड के बिना केवल मौजूदा बार से लौटाए गए क्रेडिट की सटीक मात्रा नहीं निकाली जा सकती।

3. समायोजन पूरा दिखने के बाद एक छोटा काम मापें। सीमित दायरे वाला रिपॉज़िटरी प्रॉम्प्ट भेजने से ठीक पहले उपयोग दर्ज करें, फिर काम पूरा होने पर उसके उपयोग रिकॉर्ड को देखें। Kimi के उपयोग संबंधी सवाल-जवाब में खपत रिकॉर्ड की जानकारी है और यह भी बताया गया है कि डिस्प्ले अपडेट होने में थोड़ा समय लग सकता है।

4. एक जैसे काम की तुलना करें। रिपॉज़िटरी, मॉडल, रीज़निंग सेटिंग, उपलब्ध टूल और काम का लक्ष्य समान रखें। दो रन की कैश स्थिति एक जैसी मानने के बजाय, उपलब्ध होने पर कैश की जानकारी दर्ज करें। इस्तेमाल हुए कोटे के साथ यह भी देखें कि जवाब ने काम वास्तव में पूरा किया या नहीं।

यदि पहले का तुलनीय रन उपलब्ध नहीं है, तो यह आगे की तुलना के लिए शुरुआती रिकॉर्ड बनाता है; इससे यह साबित नहीं होता कि बैकएंड के बदलाव ने कितना कोटा बचाया। यदि प्रतिशत मीटर इतना बारीक नहीं है कि छोटे अनुरोध का असर दिख सके, तो बार-बार परीक्षण करके और कोटा खर्च करने से पहले विस्तृत रिकॉर्ड देखें।

अनुरोध अब भी विफल हों तो पूरा त्रुटि संदेश पढ़ें। 2026-10-26 के अनुसार, आधिकारिक Kimi Code त्रुटि संदर्भ इन कोटा संबंधी स्थितियों को HTTP 429 के अंतर्गत रखता है:

Kimi Code का पहचानने योग्य संदेश	क्या जाँचें
You've reached your 5-hour usage limit	Console में पाँच घंटे की सीमा का रीसेट समय देखें।
You've reached your weekly (7-day) usage limit	पुराने प्लान की साप्ताहिक उपयोग अवधि देखें।
You've reached your monthly usage limit for this billing cycle	साझा मासिक मीटर और समायोजन देखें।

बार-बार अनुरोध भेजने से खत्म हुआ कोटा वापस नहीं आता। सर्वर पर अधिक लोड होना अलग स्थिति है, इसलिए मासिक क्रेडिट लौटने के बाद भी अनुरोध विफल हो सकता है।

यदि बताई गई समयसीमा बीत गई है, डिस्प्ले भी अपडेट हो चुका है और वादा किया गया समायोजन अब तक नहीं दिखता, तो Kimi सदस्यता सपोर्ट से संपर्क करें। प्लान, रिकॉर्ड की तारीख व समय और संवेदनशील जानकारी हटाए गए पहले तथा बाद के उपयोग प्रमाण दें।

अलग बिलिंग वाले API पर कब जाना चाहिए?

उपयोग के हिसाब से भुगतान वाला विकल्प तब चुनें जब काम के लिए अलग से भुगतान करना उचित हो और सदस्यता की अगली उपयोग अवधि का इंतज़ार उसे रोक रहा हो। यदि मौजूदा Kimi सत्र जारी रखना अधिक ज़रूरी है, तो पहले देखें कि आपके खाते में Extra Usage उपलब्ध है या नहीं। यह भुगतान वाला वॉलेट Kimi और Kimi Code के बीच साझा है; आगे काम जारी रखने के लिए उस पर निर्भर होने से पहले मासिक खर्च सीमा चालू करें।

बिलिंग का विकल्प चुनें और खर्च का अनुमान लगाएँ

एंडपॉइंट, मॉडल ID और API कुंजी का स्रोत एक ही सेवा से मेल खाने चाहिए। नीचे अंतरराष्ट्रीय सेवा के OpenAI-compatible बेस URL दिए गए हैं; टूल के लिए Anthropic कॉन्फ़िगरेशन में अलग बेस पाथ इस्तेमाल होते हैं।

विकल्प	बेस URL	सामान्य K3.1 Pro का मॉडल ID	बिलिंग व्यवस्था
Kimi Code	https://api.kimi.ai/coding/v1	k3.1-pro	सदस्यता का उपलब्ध कोटा; पात्र खाते में आगे के उपयोग की बिलिंग Extra Usage से हो सकती है
Kimi API Platform	https://api.moonshot.ai/v1	kimi-k3.1-pro	उपयोग के हिसाब से भुगतान वाला अलग API खाता
BetterToken	https://www.bettertoken.ai/v1	kimi-k3.1-pro	अलग BetterToken API बैलेंस

BetterToken की मौजूदा मॉडल सूची में 2026-10-26 को kimi-k3.1-pro के लिए Chat Completions और Anthropic Messages उपलब्ध बताए गए थे। उसकी मॉडल गाइड स्पष्ट करती है कि इस मॉडल के लिए Responses चालू नहीं है। यह स्वतंत्र API एक्सेस है, Kimi सदस्यता का कोटा नहीं।

खर्च का अंदाज़ा लगाने के लिए, Moonshot की मौजूदा वैश्विक API दरों में सामान्य kimi-k3.1-pro की कीमत लागू करों से पहले सामान्य इनपुट टोकन के लिए $2 प्रति मिलियन और आउटपुट टोकन के लिए $10 प्रति मिलियन है। मान लें कि किसी अनुरोध में $2 की दर पर 100,000 इनपुट टोकन और कुल 10,000 बिल किए जाने वाले आउटपुट टोकन इस्तेमाल होते हैं। उसकी अनुमानित लागत होगी:

(100,000 / 1,000,000 × $2) + (10,000 / 1,000,000 × $10) = $0.30

इस अनुमान में भुगतान वाले टूल कॉल, कैश हिट या एक घंटे के कैश राइट शामिल नहीं हैं। सामान्य पाँच मिनट के कैश राइट की दर भी $2 प्रति मिलियन टोकन है; कैश राइट की श्रेणी में बिल किया गया टोकन दोबारा सामान्य इनपुट के रूप में चार्ज नहीं होता। स्क्रीन पर दिख रहे जवाब की लंबाई के बजाय बिल किए गए टोकन की संख्या इस्तेमाल करें।

BetterToken की अपनी मौजूदा कीमतें हैं। सदस्यता के उपयोग प्रतिशत से यह तय नहीं होता कि कौन-सा विकल्प सस्ता है, और एजेंट का एक काम अंतिम जवाब देने से पहले कई अनुरोध कर सकता है।

एजेंट का कनेक्शन बदलने से पहले एक अनुरोध जाँचें

BetterToken विकल्प के लिए कंसोल में अपनी API कुंजी चुनें, मॉडल एक्सेस और इस्तेमाल योग्य बैलेंस की पुष्टि करें, फिर एक छोटा अनुरोध भेजें। नीचे का उदाहरण दस्तावेज़ में दिए अनुरोध प्रारूप का पालन करता है; इस लेख के लिए इसे किसी भुगतान वाले इन्फ़रेंस खाते पर चलाया नहीं गया था।

Bash इस्तेमाल करें और curl तथा jq इंस्टॉल रखें। जब read इनपुट का इंतज़ार करे, अपनी कुंजी पेस्ट करके Enter दबाएँ; टाइप किया गया इनपुट छिपा रहेगा।

set -o pipefail
read -rs BETTERTOKEN_API_KEY && export BETTERTOKEN_API_KEY

curl --silent --show-error --fail-with-body \
  https://www.bettertoken.ai/v1/chat/completions \
  --header "Authorization: Bearer ${BETTERTOKEN_API_KEY:?API key is required}" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "kimi-k3.1-pro",
    "stream": false,
    "messages": [
      {"role": "user", "content": "Reply with exactly: API_OK"}
    ]
  }' |
jq '{
  model,
  answer: .choices[0].message.content,
  finish_reason: .choices[0].finish_reason,
  usage,
  error
}'

रिस्पॉन्स बॉडी ही परिणाम है; यह अनुरोध स्ट्रीमिंग इस्तेमाल नहीं करता, इसलिए किसी जॉब की स्थिति बार-बार पूछने की ज़रूरत नहीं है। देखें कि माँगा गया API_OK जवाब, पूरा हुआ रिस्पॉन्स और उपयोग की जानकारी मिले हैं। बड़े काम पर जाने से पहले BetterToken डैशबोर्ड में इस अनुरोध का मॉडल, स्टेटस, टोकन उपयोग और शुल्क मिलाएँ।

Cline में जारी रखने के लिए Use your own API key खोलें, OpenAI Compatible चुनें और तालिका वाला BetterToken बेस URL, अपनी BetterToken कुंजी तथा kimi-k3.1-pro दर्ज करें। सेव करें, एक्सटेंशन री-लोड करें और उसी छोटे रिपॉज़िटरी काम से शुरुआत करें। OpenCode के लिए उसके कस्टम Chat Completions प्रोवाइडर की कॉन्फ़िगरेशन का पालन करें।

Claude Code की BetterToken कॉन्फ़िगरेशन में Anthropic-compatible बेस https://bettertoken.ai इस्तेमाल होता है, जिसमें /v1 नहीं जोड़ा जाता। Chat Completions का बेस कॉपी करने के बजाय उस टूल के प्रमाणीकरण निर्देशों का पालन करें।

यदि छोटे जाँच अनुरोध पर 401 मिले, तो BetterToken कुंजी दोबारा जाँचें। 404 या मॉडल खोजने की त्रुटि पर सटीक एंडपॉइंट और मॉडल ID देखें। रेट लिमिट या बैलेंस की त्रुटि मिले तो दोबारा प्रयास करने से पहले उस API खाते का अपना रिस्पॉन्स और डैशबोर्ड देखें; सदस्यता का रीसेट अलग बिलिंग वाले विकल्प की स्थिति नहीं बताता।