Gemini Enterprise کے agent پر خرچ رکے گا—مگر کام بھی عارضی طور پر رکے گا
Google Cloud نے 26 اگست 2026 کو Gemini Enterprise کے agent workloads کے لیے ماہانہ spend caps، Flexible Savings Plans اور ادائیگی کے نئے طریقے پیش کیے۔ Google Cloud کی تفصیلی وضاحت کے مطابق project کی مقررہ AI spend limit پوری ہونے پر agent کی API calls عارضی طور پر رکتی ہیں، جبکہ باقی production infrastructure چلتا رہتا ہے۔
اسی 26 اگست کو Axios کی آزاد رپورٹ نے monthly cap کے بعد agent calls رکنے، ایک اور تین سالہ discounts، pay-as-you-go option اور آئندہ deferred pricing کی تصدیق کی۔ خریدار کے لیے مرکزی trade-off یہ ہے کہ hard cap اضافی استعمال روک کر بل کو قابو میں رکھتا ہے، مگر مسلسل چلنے والے agent کو اس کے بدلے بلا تعطل capacity نہیں ملتی۔
ماہانہ cap پورا ہو تو اصل میں کیا رکتا ہے؟
Spend cap محض budget alert نہیں بلکہ استعمال روکنے والا control ہے۔ مقررہ حد پوری ہونے پر agent کی نئی API-dependent سرگرمی pause ہو سکتی ہے؛ اس کا مطلب یہ نہیں کہ project کے تمام resources حذف، بند یا ناقابلِ واپسی ہو جاتے ہیں۔ مالی اجازت بحال ہونے، cap ہٹنے یا اگلا billing cycle شروع ہونے کے بعد محدود feature دوبارہ دستیاب ہو سکتا ہے۔
یہ حد Gemini Enterprise app، Agent Platform اور اسی project کے متعلقہ AI developer tools کے خرچ پر اثرانداز ہو سکتی ہے۔ البتہ استعمال روکنے کے عمل میں چند منٹ لگ سکتے ہیں، اس لیے cap کو ہر حالت میں آخری پیسے پر بل روک دینے والی ضمانت سمجھنا درست نہیں۔
Administrator دو مختلف فیصلے کر سکتا ہے۔ cap trigger ہونے کے بعد console سے کام دوبارہ شروع کیا جا سکتا ہے، یا پہلے ہی overages فعال کیے جا سکتے ہیں تاکہ شامل quota ختم ہونے پر اضافی استعمال pay-as-you-go rates پر چلے۔ پہلے انتخاب میں مالی حد مضبوط رہتی ہے مگر agent رک سکتا ہے؛ دوسرے میں availability بہتر رہتی ہے مگر cap آخری مالی رکاوٹ نہیں رہتا۔
Flexible Savings Plans کی رعایت کے ساتھ مستقل ذمہ داری بھی ہے
Gemini Enterprise Flexible Savings Plan ایک spend-based commitment ہے: eligible SKUs پر ایک سال کے لیے 10٪ اور تین سال کے لیے 20٪ discount ملتا ہے۔ Google کی اعلان کردہ پیش کش میں پہلے سے مقرر کوئی عمومی کم یا زیادہ plan size نہیں، مگر خریدار کو اپنی مخصوص ماہانہ commitment منتخب کرنا اور پوری مدت اس کی ادائیگی کرنا ہوتی ہے۔
Flexible Savings Plans کی دستاویزات واضح کرتی ہیں کہ خریدی گئی commitment عام طور پر منسوخ یا تبدیل نہیں کی جا سکتی، کم استعمال کی صورت میں بھی مکمل ماہانہ رقم واجب رہتی ہے اور غیر استعمال شدہ حصہ اگلے مہینے منتقل نہیں ہوتا۔ discount صرف eligible استعمال اور commitment کی حد تک ہے؛ اس حد سے زیادہ ماہانہ استعمال standard on-demand rate پر bill ہوتا ہے۔
یہ نکتہ اعلان کے مختصر جملے سے زیادہ محدود تصویر پیش کرتا ہے۔ Overage اگر FSP میں بچی ہوئی commitment کے اندر draw ہو تو discounted rate سے فائدہ مل سکتا ہے، لیکن commitment مکمل خرچ ہونے کے بعد ہر اضافی unit پر 10٪ یا 20٪ رعایت برقرار نہیں رہتی۔
- متغیر یا ابتدائی demand: pay-as-you-go میں upfront commitment اور base subscription fee نہیں، مگر compute اور tokens standard model API rates پر bill ہوتے ہیں۔
- نسبتاً مستقل demand: ایک سالہ FSP کم مدت کی ذمہ داری کے ساتھ 10٪ discount دیتا ہے۔
- طویل مدتی قابلِ پیش گوئی demand: تین سالہ FSP کا discount 20٪ ہے، مگر کم استعمال کے باوجود طے شدہ ماہانہ commitment ادا کرنا ہوگی۔
- سخت مالی حد: spend cap اضافی استعمال روکتا ہے، مگر customer-facing agent کی عارضی عدم دستیابی قبول کرنا پڑ سکتی ہے۔
Pay-as-you-go، seat quota اور overage الگ controls ہیں
موجودہ per-user subscription میں مقررہ ماہانہ fee کے ساتھ daily quota pools پورے project میں مشترک ہوتے ہیں۔ نئی pay-as-you-go consumption edition میں خالی seats کے بجائے استعمال شدہ compute اور tokens کا بل بنتا ہے۔ اعلان کے وقت یہ edition منتخب customers کے لیے دستیاب تھی اور وسیع rollout جلد متوقع تھا؛ اسے پاکستان کے ہر billing account میں فوری طور پر دستیاب سمجھنا درست نہیں۔
Pooled quota پہلے استعمال ہوتا ہے۔ اس کے ختم ہونے پر administrator نے overages کی اجازت دی ہو تو اضافی traffic pay-as-you-go rates پر منتقل ہو سکتا ہے؛ اجازت نہ ہو تو متعلقہ feature رک جاتا ہے۔ اسی لیے pay-as-you-go کی billing شرط کو seat subscription، quota اور spend cap سے الگ سمجھنا ضروری ہے۔
Pay-as-you-go edition میں pooled quota limit نہیں ہوتی کیونکہ تمام استعمال consumption basis پر bill ہوتا ہے۔ اس کے برعکس subscription editions میں overage شامل quota سے آگے جانے کا mechanism ہے، جبکہ monthly spend cap اسی اضافی خرچ کے لیے آخری project-level boundary بن سکتا ہے۔
Production agent میں budget اور availability کا ٹکراؤ
ایک واضح مشروط مثال میں customer-support agent مہینہ ختم ہونے سے پہلے cap تک پہنچ جاتا ہے۔ overage بند ہو تو نئی API calls رک سکتی ہیں: finance ٹیم اضافی consumption روکتی ہے، مگر support workflow کی دستیابی متاثر ہوتی ہے۔ overage فعال ہو تو agent کام جاری رکھ سکتا ہے، لیکن مزید استعمال consumption billing میں شامل ہوگا۔
FSP اس فیصلے کا تیسرا حصہ ہے، cap کا متبادل نہیں۔ اگر متعلقہ eligible استعمال ابھی ماہانہ commitment کے اندر ہو تو رعایت مل سکتی ہے؛ commitment ختم ہونے کے بعد overage standard on-demand rate پر جاتا ہے۔ یوں plan unit cost کم کر سکتا ہے، جبکہ cap یہ طے کرتا ہے کہ استعمال کہاں رکے، اور overage policy یہ طے کرتی ہے کہ quota یا حد کے بعد کام جاری رہ سکے گا یا نہیں۔
Google نے cap trigger ہونے پر رکے ہوئے workload کو خودکار طور پر deferred queue میں بھیجنے کی سہولت بیان نہیں کی۔ اس لیے production agent کے لیے hard cap لگانا لازماً یہ انتخاب بھی ہے کہ budget exhaustion کی صورت میں فوری کام عارضی طور پر دستیاب نہ رہے۔
Deferred execution ابھی مستقبل کا الگ option ہے
Deferred execution ان eligible agent workloads کے لیے مجوزہ pricing option ہے جنہیں فوری مکمل کرنا ضروری نہیں۔ Google کے مطابق نشان زد workload کو Gemini Enterprise Agent Platform کا scheduler off-peak capacity window میں چلائے گا، standard quota limits سے الگ execution دے گا اور inference cost میں 50٪ تک کمی ممکن ہوگی۔
26 اگست کے اعلان میں اس کا status coming soon تھا اور دستیابی صرف منتخب workloads کے لیے بتائی گئی۔ مکمل eligibility list، عام دستیابی کی حتمی تاریخ اور پاکستان کے لیے الگ PKR pricing شائع نہیں کی گئی، اس لیے اسے موجودہ spend cap سے رکے agent کا دستیاب یا خودکار fallback نہیں سمجھا جا سکتا۔
موجودہ صورتِ حال میں Flexible Savings Plans self-serve اور Enterprise Agreement customers کے لیے دستیاب بتائے گئے ہیں، pay-as-you-go edition منتخب customers سے وسیع rollout کی طرف جا رہی ہے، اور deferred execution ابھی آئندہ سہولت ہے۔ اس خبر کا عملی نتیجہ یہی ہے: monthly cap agent کا خرچ روک سکتا ہے، مگر اسی لمحے اس کا API-dependent کام بھی رک سکتا ہے؛ بلا تعطل operation کے لیے overage قبول کرنا ہوگا، جبکہ کم قیمت deferred capacity کی حقیقی دستیابی ابھی باقی ہے۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔