Gemini Enterprise میں pay-as-you-go، مگر بل کی نئی شرط بھی ساتھ

Google Cloud نے 26 اگست 2026 کو Gemini Enterprise app میں agent workloads کے لیے نئی Pay-as-you-go consumption edition متعارف کرائی، جو موجودہ فی صارف subscriptions کے ساتھ استعمال کی جا سکتی ہے۔ Google Cloud کے FinOps اعلان میں اسے بغیر بنیادی subscription fee یا پیشگی commitment کے compute اور tokens کے حقیقی استعمال پر بل ہونے والا اختیار بتایا گیا ہے؛ فی الحال یہ منتخب صارفین کے لیے ہے اور وسیع اجرا بعد میں ہونا ہے۔

کاروباری خریدار کے لیے اہم بات یہ ہے کہ یہ ہر فعال Google Cloud account پر فوراً دستیاب آزاد on-demand منصوبہ نہیں۔ ITPro کی اسی روز شائع ہونے والی رپورٹ نے نئے ادائیگی اختیار اور project-level خرچ کنٹرولز کی آزاد تصدیق کی، جبکہ Google کی Pay-as-you-go اہلیت کی دستاویزات اسے فعال ماہانہ invoice والے invoiced Cloud Billing account، مخصوص billing-update email اور الگ subscription کی خریداری سے مشروط کرتی ہیں۔

Seat subscription اور استعمال کے مطابق بلنگ میں فرق

فی صارف subscription میں ادارہ ہر خریدی گئی seat کی مقررہ ماہانہ فیس دیتا ہے۔ اس کے ساتھ ملنے والی feature quota project اور edition کے اندر مجاز صارفین کے لیے مشترک ہوتی ہے، اس لیے finance ٹیم کو صارفین کی معلوم تعداد کے مقابل ایک نسبتاً مستقل بنیادی خرچ ملتا ہے۔

Pay-as-you-go edition میں بنیادی فیس یا لازمی پیشگی commitment نہیں۔ Gemini Enterprise app کے استعمال شدہ compute اور tokens پر standard model API rates کے مطابق charges بنتے ہیں، لہٰذا بل seats کی تعداد کے بجائے agent workload کی سرگرمی کے ساتھ اوپر نیچے جاتا ہے۔

اس فرق کا عملی مطلب یہ ہے کہ وقفے وقفے سے چلنے والے agents یا محدود pilot کے لیے خالی seats کی مستقل قیمت سے بچا جا سکتا ہے۔ اس کے برعکس، طویل، بار بار یا غیر متوقع طور پر پھیلنے والے agent کاموں میں metered usage تیزی سے بڑھ سکتا ہے؛ ایسی صورت میں مقررہ seat fee کے بجائے workload کا حجم اصل مالی متغیر بن جاتا ہے۔

Seat-based edition میں شامل quota پہلے استعمال ہوتی ہے۔ quota ختم ہونے پر متعلقہ feature رک سکتا ہے، یا اہل setup میں منتظم overages فعال کر کے اضافی استعمال کو consumption rates پر جاری رکھ سکتا ہے۔ Pay-as-you-go edition میں تمام متعلقہ feature usage شروع ہی سے metered ہوتا ہے، اس لیے included pooled quota اور بعد میں شروع ہونے والے overage کا یہی سلسلہ اس edition پر لاگو نہیں ہوتا۔

نئی بلنگ کے لیے invoiced account کیوں ضروری ہے

اہلیت صرف اس بات سے ثابت نہیں ہوتی کہ کمپنی Google Cloud استعمال کرتی ہے یا اس کے پاس فعال billing account موجود ہے۔ Project کو ایسے invoiced Cloud Billing account سے منسلک ہونا چاہیے جسے فعال ماہانہ invoice ملتا ہو، متعلقہ account کو مخصوص billing-update email موصول ہوئی ہو، اور اس کے بعد Pay-as-you-go edition کی الگ subscription خریدی جائے۔

اس بنا پر self-serve online billing، free trial یا card سے ہونے والی عام Cloud ادائیگی خود بخود کافی نہیں۔ خریداری کا فیصلہ پورے ادارے کے Cloud تعلق کی بجائے اس مخصوص project، اس سے منسلک billing account اور Google کی دی گئی eligibility پر ہوگا۔

پاکستان میں کام کرنے والی Google Cloud کمپنیوں کے لیے اعلان کا عالمی ہونا مقامی account کی فوری اہلیت کی ضمانت نہیں بنتا۔ دستیاب معلومات میں پاکستان کے لیے الگ rollout تاریخ یا ہر مقامی billing arrangement کے لیے عمومی منظوری درج نہیں؛ اس لیے رسائی account کی قسم اور موصول شدہ اطلاع سے طے ہوگی، نہ کہ صرف کمپنی کے جغرافیائی مقام سے۔

Pay-as-you-go edition میں license-based feature quota limits نہیں، کیونکہ استعمال کی قیمت براہ راست ادا ہوتی ہے۔ تاہم اس کا مطلب غیر محدود تکنیکی capacity نہیں: Discovery Engine API سے متعلق rate، allocation اور system limits الگ رہتے ہیں اور billing model بدلنے سے ختم نہیں ہوتے۔

Spend caps بل کو روکتے ہیں، مگر کام بھی رک سکتا ہے

نئے FinOps controls کا سب سے واضح حفاظتی آلہ project-level ماہانہ spend cap ہے۔ حد پوری ہونے پر متاثرہ agent کی API calls عارضی طور پر رک سکتی ہیں، جبکہ project سے باہر باقی production infrastructure چلتا رہتا ہے۔ یہ عام budget notification سے مختلف ہے، کیونکہ یہاں مالی حد workload کے تسلسل پر براہ راست اثر ڈال سکتی ہے۔

منتظم Cloud Billing Console میں خرچ کی حد اور alerts کے ذریعے استعمال کی رفتار دیکھ سکتا ہے۔ Early anomaly detection معمول سے مختلف خرچ کو نمایاں کر کے اضافے سے وابستہ نمایاں SKUs دکھاتی ہے، جبکہ Pricing Calculator فی صارف licenses، developer tools اور background agent runtimes کے متوقع خرچ کا ابتدائی تخمینہ فراہم کرتا ہے۔

یہ controls قیمت کو مقرر نہیں کرتے اور نہ ہی workload کی مانگ کا درست اندازہ خود بنا دیتے ہیں۔ ان کا کام بڑھتے استعمال کو جلد نمایاں کرنا، project کے لیے مالی حد نافذ کرنا اور finance و engineering ٹیموں کو ایک ہی billing context دینا ہے۔

Seat-based project میں overages اور spend cap الگ فیصلے ہیں۔ overages فعال ہونے پر شامل quota ختم ہونے کے بعد charges جاری رہ سکتے ہیں، جبکہ cap اس اضافی استعمال کی زیادہ سے زیادہ ماہانہ حد مقرر کرتی ہے۔ Pay-as-you-go edition میں تمام feature usage پہلے ہی charge ہوتا ہے، اس لیے overage toggle کو seat plan جیسے مفہوم میں نہیں پڑھنا چاہیے۔

مشترکہ usage view سب منصوبوں کو ایک جیسا نہیں بناتا

Google Antigravity، Gemini Enterprise Agent Platform اور app کے استعمال کو ایک مشترکہ انتظامی view میں سمیٹنے کا مقصد الگ licenses اور billing silos کم کرنا ہے۔ Developer tools کی شامل quota بھی project کی سطح پر pool کی جا رہی ہے، تاکہ مجاز ٹیمیں پہلے سے خریدی گئی capacity کو مشترک طور پر استعمال کر سکیں۔

اس رسائی کا rollout بھی یکساں یا فوری نہیں۔ Antigravity اور Android Studio AI use کو Gemini Enterprise subscription میں شامل کرنے کی سہولت منتخب customers سے شروع ہوئی ہے، اس لیے مشترکہ view دیکھنے کی صلاحیت کو ہر موجودہ subscription کی موجودہ خصوصیت نہیں سمجھنا چاہیے۔

ایک dashboard مختلف billing models کو ایک model میں تبدیل نہیں کرتا۔ Finance ٹیم کو مقررہ seat commitment، شامل pooled quota، seat-based overage اور مکمل metered consumption الگ مدات کے طور پر پڑھنا ہوگا؛ مشترکہ view visibility دیتا ہے، مگر ان کے نرخ، اہلیت اور quota rules یکساں نہیں کرتا۔

کاروباری خریدار کے لیے فیصلہ نامہ

Seat subscription اس وقت زیادہ واضح انتخاب ہے جب users کی تعداد معلوم ہو، روزمرہ استعمال نسبتاً مستقل ہو اور finance کو مقررہ ماہانہ baseline درکار ہو۔ مشترکہ quota project کے اندر مانگ تقسیم کر سکتی ہے، جبکہ overage کی اجازت operational continuity اور اضافی خرچ کے درمیان الگ انتظامی فیصلہ رہتی ہے۔

Pay-as-you-go edition غیر ہموار agent workloads، محدود pilots یا ایسے automated کام کے لیے موزوں ہو سکتی ہے جن کا حجم ملازمین کی تعداد کے ساتھ براہ راست نہیں بڑھتا۔ اس میں خالی seats کا بنیادی خرچ نہیں، مگر ہر متعلقہ استعمال charge ہونے کی وجہ سے usage visibility اور project-level مالی حدود زیادہ اہم ہو جاتی ہیں۔

دونوں راستوں میں انتخاب صرف فی seat اور فی token قیمت کا موازنہ نہیں۔ خریدار کو workload کی باقاعدگی، ممکنہ عروج، کام رکنے کی قابل قبول حد، pooled quota کی افادیت اور invoiced billing eligibility کو ایک ساتھ دیکھنا ہوگا۔

29 اگست 2026 تک ثابت شدہ صورت حال یہ ہے کہ Google نے موجودہ seat subscriptions کے ساتھ consumption-based option اور agent cost controls شامل کر دیے ہیں، مگر نئی edition ابھی منتخب customers اور مخصوص billing شرائط تک محدود ہے۔ وسیع rollout کی قطعی تاریخ، ہر پاکستانی account کی اہلیت اور کسی ادارے کا مؤثر مجموعی نرخ عوامی معلومات سے طے نہیں ہوتا؛ یہ billing relationship اور حقیقی workload پر منحصر رہے گا۔