Cursor Ultra की limits: usage pools, on-demand और spend cap

आप Cursor Ultra के लिए हर महीने $200 देते हैं, फिर भी limit के पास पहुँचने का warning दिख सकता है। सबसे महँगी गलती यह मान लेना है कि हर percentage एक ही allowance दिखाता है और तुरंत Spending को No Limit कर देना है। पहले पता करें कि कौन-सा counter बढ़ रहा है, फिर तय करें कि काम जारी रखने की कीमत extra usage से अधिक है या नहीं, और उसके बाद ही अपनी सीमा के भीतर monthly cap सेट करें।

सबसे जरूरी बात: Ultra में एक universal usage meter नहीं है

27 सितंबर 2026 तक Cursor के अनुसार Pro, Pro Plus और Ultra में दो अलग usage pools शामिल हैं, और दोनों monthly billing cycle के साथ reset होते हैं: Cursor Models और Other Models। Ultra की listed कीमत $200 प्रति माह है और इसमें दोनों pools शामिल हैं, लेकिन selected model के हिसाब से included usage अलग गति से खत्म होता है।

• Cursor Models में अभी Grok 4.7, Grok 4.6, Grok 4.5 और Composer 2.5 शामिल हैं। Cursor इस pool में significantly more included usage बताता है।
• Other Models उन third-party models के लिए है जिन्हें आप सीधे चुनते हैं; usage उस model की API price के अनुसार गिना जाता है।

इसलिए “मेरा Ultra 80% इस्तेमाल हो चुका है” पर्याप्त diagnosis नहीं है। आपको देखना होगा कि Cursor Models कम हो रहा है, Other Models कम हो रहा है, या किसी अलग feature की weekly allowance warning दे रही है।

उदाहरण के लिए, X पर एक user-posted screenshot में Cursor Models का monthly usage 72% और Grok Bot की weekly allowance 90% एक साथ दिखी। ये अलग counters हैं। Grok Bot का weekly warning अपने-आप यह साबित नहीं करता कि Ultra का कोई monthly model pool खत्म हो गया है।

Plan या billing बदलने से पहले सही counter पहचानें

Tokens का अनुमान लगाने के बजाय warning की जगह, selected model और billing line को आपस में मिलाना सबसे भरोसेमंद तरीका है।

आपको क्या दिख रहा है	इसका सामान्य अर्थ	अगला कदम
Cursor Models percentage बढ़ रहा है	Grok या Composer, Cursor Models pool से usage ले रहा है	देखें Other Models में जगह है या नहीं और model switch task के लिए उचित है या नहीं
Other Models percentage बढ़ रहा है	चुना हुआ third-party model अपनी API rate पर usage ले रहा है	महँगे models, long context और frequent Agent work जाँचें
Grok Bot का weekly warning	उस Bot feature की weekly allowance reset के पास है	Weekly reset का इंतजार करें या उस feature का usage घटाएँ; इसे monthly Ultra exhaustion न मानें
Included Usage और On-Demand Usage अलग दिखते हैं	Subscription usage और extra metered usage अलग billing items हैं	On-demand status और spend limit जाँचें

तीन मिनट का ऐसा diagnostic जिसे आप verify कर सकें

1. Cursor editor settings या usage dashboard खोलें। Cursor Models और Other Models दोनों का percentage तथा monthly reset date लिख लें। Cursor के अनुसार दोनों pools वहीं दिखाई देते हैं।
2. हाल की heavy task पर वापस जाएँ और देखें कि वास्तव में कौन-सा model चुना गया था। Models की cost अलग होती है, इसलिए सिर्फ request count से खर्च नहीं समझा जा सकता।
3. Billing & Invoices में Included Usage और On-Demand Usage की तुलना करें। दूसरी line में amount दिख रहा है तो subscription के included usage से बाहर charges बन रहे हैं।
4. Spending खोलें और जाँचें कि on-demand enabled है या नहीं, current monthly limit क्या है और कहीं No Limit तो नहीं चुना गया।
5. एक छोटा, साफ boundary वाला काम चलाएँ—जैसे एक file का refactor—और फिर देखें कि कौन-सा pool या billing line बदला।

Warning अस्पष्ट हो तो अपने dashboard के दो pools और billing lines को प्राथमिकता दें। Screenshot, chat reply या single banner आपके account के live data की जगह नहीं लेता।

On-demand usage कब सही फैसला है

On-demand तभी उपयोगी है जब काम रुकने से बचने का मूल्य उस extra amount से अधिक हो जिसे आप देना स्वीकार करते हैं। Cursor की usage-based charges documentation के अनुसार individual users को on-demand साफ तौर पर enable करना पड़ता है; included usage के बाद requests API rates पर bill होती हैं और subscription से अलग दिखाई देती हैं।

आमतौर पर यह तब उचित है जब ये तीनों बातें सही हों:

• Release, fix या migration की स्पष्ट deadline है और delay का नुकसान समझ में आता है।
• बचा हुआ काम bounded है—जैसे दो code reviews या एक defined module—न कि open-ended Agent loop।
• आप हर heavy task के बाद usage देखेंगे और budget पहुँचने पर रुक सकते हैं।

इन स्थितियों में फिलहाल इसे बंद रखना बेहतर है:

• अभी यह नहीं पता कि कौन-सा pool consume हो रहा है।
• कई Agents, automations या long-context jobs parallel चल रहे हैं और खर्च का अनुमान कठिन है।
• आपका personal budget hard limit है या काम अगली billing cycle तक रुक सकता है।
• दूसरे included pool में अभी पर्याप्त जगह और task के लिए उपयुक्त model मौजूद है।

On-demand enable करना “unlimited model usage” वापस नहीं लाता। इसका अर्थ है included usage के बाद metered billing जारी रखने की अनुमति। यह continuity देता है, cost control नहीं।

Spend cap बिना guess किए कैसे तय करें

सबसे सुरक्षित cap कोई platform-recommended number नहीं, बल्कि current billing cycle में आपका maximum acceptable extra spend है। On-demand enable होने के बाद dashboard के Spending tab में individual monthly limit सेट की जा सकती है। Cursor की spend-limit documentation के अनुसार No Limit चुनने से cap हट जाती है।

पहली cap तय करने के लिए यह तरीका अपनाएँ:

1. Billing cycle में बची heavy development sessions गिनें, सिर्फ calendar days नहीं।
2. Total extra amount तय करें जिसे आप स्वीकार कर सकते हैं।
3. उस amount को remaining heavy sessions से divide करके review threshold बनाएँ।
4. Cursor में total monthly cap सेट करें और हर session के बाद actual usage को threshold से मिलाएँ।

मान लें आप अधिकतम $40 extra दे सकते हैं और reset से पहले दस heavy Agent sessions बाकी हैं। तब $4 प्रति session को manual review threshold मानें। यह Cursor की per-session limit या cost guarantee नहीं है; यह unusually expensive task जल्दी पकड़ने का तरीका है।

Spend limit के दो महत्वपूर्ण व्यवहार

पहला, limit change तुरंत लागू होता है, लेकिन enforcement instant नहीं है। Cursor के अनुसार system के limit पहचानने से पहले usage थोड़ी देर cap से ऊपर जा सकता है। यह limited pre-enforcement overage temporary spend-limit credit के रूप में record होता है और billing current limit तक रहती है।

दूसरा, अगर आप उसी cycle में limit बढ़ाते हैं तो Cursor पहले credit किए गए amount का कुछ या पूरा हिस्सा, नई limit तक, bill कर सकता है। Credit बनाए रखने के लिए limit न बढ़ाएँ या on-demand बंद कर दें।

Solo developer के लिए finite cap आम तौर पर No Limit से अधिक सुरक्षित है। Cap तभी हटाएँ जब आप बाकी cycle में इस control के बिना extra spend स्वीकार करते हों और bill को सक्रिय रूप से monitor करेंगे।

Extra भुगतान करें या coding workflow बदलें?

सही उत्तर इस पर निर्भर है कि कौन-सा pool कम हो रहा है, task कितना urgent है और यह spike एक बार का है या हर महीने दोहरता है।

मौजूदा स्थिति	पहले क्या करें	क्यों
Cursor Models लगभग खत्म, Other Models में जगह	केवल suitable difficult tasks third-party model पर भेजें; routine work Cursor Models में रखें	दूसरा pool इस्तेमाल होगा, लेकिन third-party model अपनी API rate पर consume करेगा
Other Models लगभग खत्म, Cursor Models में जगह	Routine coding, rewrites और exploration Grok या Composer पर ले जाएँ	Remaining included pool इस्तेमाल होगा और costly model कठिन काम के लिए बचेगा
दोनों pools limit के पास, एक short deadline बाकी	Finite monthly cap के साथ on-demand enable करें	Continuity का value साफ है और downside bounded है
हर महीने pools जल्दी खत्म, parallel Agents या automation लगातार चलती है	Concurrency घटाएँ, context छोटा करें और tasks batch करें	Recurring workflow issue सिर्फ cap बढ़ाने से हल नहीं होता
ज्यादातर काम completion, mechanical edits या local changes है	Tab और smaller scoped tasks को प्राथमिकता दें	Ultra में unlimited Tab completions शामिल हैं; Agent को complex decisions के लिए बचाया जा सकता है

उसी page पर Cursor broad guidance देता है: daily Tab users आम तौर पर included usage में रहते हैं; limited Agent users भी अक्सर वहीं रहते हैं; daily Agent users सामान्यतः $60–$100 monthly total usage बनाते हैं; और multiple Agents या automation वाले power users अक्सर $200+ total usage तक पहुँचते हैं। ये broad categories हैं, आपकी bill prediction नहीं। Actual on-demand cost model, tokens, context length और workflow पर निर्भर रहेगा।

पहले से दिए $200 नहीं, task value के आधार पर फैसला लें

Ultra subscription sunk cost है। Extra metered charges जोड़ने का यही अकेला कारण नहीं होना चाहिए। हर heavy task से पहले तीन सवाल पूछें:

1. अभी पूरा करने से कितना manual time या deadline loss बचेगा?
2. क्या दूसरे included pool का model unacceptable quality loss के बिना काम कर सकता है?
3. अगर एक और paid attempt भी काम पूरा न करे तो किस amount पर रुकूँगा?

तीनों जवाब साफ हों तो capped on-demand अचानक रुकने से अधिक तर्कसंगत हो सकता है। तीसरे सवाल का जवाब न हो तो पहले workflow बदलना सुरक्षित है।

आज अपनाने योग्य सही क्रम

Diagnosis से पहले भुगतान शुरू न हो, इसके लिए यह क्रम रखें:

1. Warning source पहचानें: Cursor Models, Other Models, Grok Bot या billing page।
2. दोनों monthly pools लिखें: percentages और reset date save करें; एक combined impression पर निर्भर न रहें।
3. Models को tasks से मिलाएँ: हाल के heavy work के selected models, parallel Agents और long contexts पहचानें।
4. Billing categories देखें: Included Usage और On-Demand Usage अलग-अलग बढ़ रहे हैं या नहीं।
5. Switch से पहले budget तय करें: cycle का maximum extra amount चुनें, फिर finite cap के साथ on-demand enable करें।
6. Bounded test करें: एक स्पष्ट task पूरा करें और pools तथा billing फिर देखें।
7. Review के बाद ही scale करें: result और consumption दोनों acceptable हों तभी task size या cap बढ़ाएँ।

Success सिर्फ warning गायब होना नहीं है। आपको पता होना चाहिए कि कौन-सा pool consume हो रहा है, extra charge क्यों बढ़ रहा है और किस amount पर काम रोकना है।

Cursor Ultra limits पर आम सवाल

Grok Bot 90% दिखाए तो क्या Ultra लगभग खत्म है?

जरूरी नहीं। Grok Bot की weekly allowance और monthly Cursor Models तथा Other Models अलग counters हैं। Ultra का included usage खत्म मानने से पहले usage dashboard के दोनों pools देखें।

क्या No Limit से Cursor unlimited हो जाता है?

नहीं। No Limit सिर्फ on-demand spending की monthly cap हटाता है। Included usage के बाद requests लागू rates पर bill होती रहती हैं। Ultra के unlimited Tab completions का अर्थ भी यह नहीं कि हर Agent या model request free और unbounded है।

Spend cap hit होने के बाद usage बढ़ सकता है?

Cursor कहता है कि enforcement instant नहीं है, इसलिए brief exceed हो सकता है। Limited overage temporary credit की तरह handle होता है और billing current limit तक रहती है। उसी cycle में limit बढ़ाने पर credit का कुछ या पूरा हिस्सा नई limit तक billable बन सकता है।

क्या used percentage से बाकी काम का अनुमान लगाया जा सकता है?

विश्वसनीय रूप से नहीं। Model API price, context length, output length और concurrency consumption बदलते हैं। Small bounded task चलाकर dashboard दोबारा देखना बेहतर estimate देता है।

याद रखने वाला निर्णय नियम

Metered usage चालू करने से पहले pool जाँचें और limit बढ़ाने से पहले budget तय करें। Heavy solo developer के लिए सबसे controllable default आम तौर पर finite cap, सही pool में high-value tasks और हर expensive task के बाद usage review है—तुरंत No Limit चुनना नहीं।