13 घंटे में €54,000 का बिलिंग उछाल: API restrictions के बिना Firebase browser key से Gemini API कॉल हुए

• Firebase browser key बिना किसी API restrictions के exposed थी, जिसके कारण बाहर से Gemini API requests अपने-आप होने लगे और बहुत कम समय में भारी बिलिंग हो गई
• वास्तविक user traffic से असंबंधित रहते हुए 13 घंटों में €54,000 से अधिक का खर्च चार्ज हुआ, और cost alerts देर से trigger हुए जिससे प्रतिक्रिया में देरी हुई
• Google Cloud support team ने इन requests को valid usage के रूप में classify किया और billing adjustment request को अस्वीकार कर दिया
• Google ने spend caps, Auth key, automatic key blocking, prepaid billing जैसी सुरक्षा सुविधाएँ शुरू की हैं, और unrestricted key usage को चरणबद्ध तरीके से बंद करने की योजना है
• डेवलपर्स को client code में keys शामिल नहीं करनी चाहिए, और API key restrictions तथा budget limits ज़रूर सेट करने चाहिए

---

Firebase browser key exposure की वजह से Gemini API billing spike का मामला

• घटना का सार

  • पहले केवल Firebase Authentication इस्तेमाल करने वाले प्रोजेक्ट में Firebase AI Logic सक्रिय करते ही Gemini API usage अचानक बढ़ गया
  • वास्तविक user traffic से अलग automated requests बहुत कम समय में आने लगे, जिससे लगभग 13 घंटों में €54,000 से अधिक की बिलिंग हुई
  • API को disable करने और credentials को rotate करने के after असामान्य traffic रुक गया
  • budget alert (€80) और cost anomaly detection alert कई घंटे की देरी से trigger हुए, और प्रतिक्रिया के समय तक लगभग €28,000 का खर्च हो चुका था
  • अंतिम billed amount delayed cost reporting के कारण €54,000 से अधिक तय हुई

• Google Cloud support का परिणाम

  • logs और analysis material जमा करने के बावजूद, requests को प्रोजेक्ट से उत्पन्न valid usage माना गया और billing adjustment request अस्वीकार कर दी गई
  • यह usage असामान्य था और user-driven traffic नहीं था, फिर भी सिस्टम ने इसे सामान्य billable usage के रूप में संसाधित किया

• उपयोगकर्ता के प्रश्न

  • Firebase AI Logic या Gemini सक्षम करने के बाद ऐसे मिलते-जुलते मामले मौजूद हैं या नहीं, यह पूछा गया
  • App Check, quotas, server-side calls पर migration के अलावा कोई अतिरिक्त सुरक्षा उपाय हैं या नहीं, यह पूछा गया
  • ऐसे मामलों के लिए कोई अतिरिक्त escalation path मौजूद है या नहीं, यह भी पूछा गया

Google की प्रतिक्रिया (Logan Kilpatrick)

• बिलिंग और usage limit सुविधाएँ

  • Gemini API users के लिए billing account caps शुरू किए गए हैं, और Tier 1 users को monthly $250 limit के बाद अपने-आप block कर दिया जाता है
  • project spend caps सेट किए जा सकते हैं; उदाहरण के लिए personal account को $50 तक सीमित किया जा सकता है
  • सभी billing reports में लगभग 10 मिनट की delay होती है

• API key security और बदलाव

  • unrestricted API key का उपयोग जल्द ही Gemini API में disable किया जाएगा

    • नए users के लिए default रूप से Auth key बनाई जाती है, जो पहले की तुलना में ज़्यादा secure है
    • client code में keys शामिल नहीं करनी चाहिए; exposed होने पर cost लग सकती है
    • public web पर key exposed होने पर automatic detection और disable की सुविधा है, और कुछ मामलों में यह कुछ मिनटों में block भी हुई है

• key restrictions और service scope

  • Google AI Studio में बनाई गई keys default रूप से Gemini API only के लिए restricted होती हैं

    • जबकि Google Cloud Console जैसे अन्य रास्तों से बनाई गई keys कई services तक पहुँच सकती हैं, इसलिए ज़रूरत पड़ने पर service-specific restrictions सेट करनी चाहिए

• अतिरिक्त कदम और आगे की योजना

  • मामले की समीक्षा के लिए सीधे email ([e-mail]) पर संपर्क करने को कहा गया
  • prepaid billing सिस्टम शुरू किया गया है, जिससे use से पहले payment मॉडल की ओर बदला जा रहा है
  • यह फिलहाल अमेरिका के नए accounts पर लागू हो चुका है और दुनिया भर में चरणबद्ध रूप से फैलाया जा रहा है
  • इन कदमों का उद्देश्य डेवलपर्स के लिए cost control और unexpected billing prevention को मज़बूत करना है

[GN⁺]

Hacker News की राय

• हमने बजट अलर्ट (€80) और cost overrun alert सेट किए थे, लेकिन दोनों कई घंटे की देरी से ट्रिगर हुए
  जब तक हम प्रतिक्रिया दे पाते, लागत पहले ही €28,000 तक पहुँच चुकी थी, और अंत में देरी से आई cost reporting के कारण €54,000 से ज़्यादा का बिल लग गया
  ऐसी स्थिति में “hard spending cap तकनीकी रूप से असंभव है” कहना इन तीनों कंपनियों का कोई भरोसेमंद बहाना नहीं है

  • इसलिए मैं Google Cloud जैसी सेवाओं का जहाँ तक हो सके इस्तेमाल नहीं करता
    यह कहना कि hard cap असंभव है, बेतुका है, और कम से कम users को विकल्प तो देना ही चाहिए
  • यह सचमुच पागलपन है। एक अच्छा प्रोजेक्ट बनाते समय सिर्फ एक गलती के कारण €30,000~€50,000 का भुगतान करना पड़े, यह ज़िंदगी बदल देने वाला झटका हो सकता है
    पहले ऐसी गलतियाँ सिर्फ bug होती थीं, अब वे दिवालियापन तक ले जा सकती हैं
  • यह गैरकानूनी होना चाहिए
    अगर आपने बाथरूम की टाइल बदलने का काम दिया हो और बदले में बगीचे के remodeling का बिल थमा दिया जाए, तो साफ़ है कि आपको उसे ठुकराने का अधिकार होना चाहिए
  • मैं एक manager के रूप में ऐसे customer service disaster की वजह से Google Cloud से बचता हूँ
    लेकिन telecom billing systems के साथ काम करने के अनुभव से मैं समझ सकता हूँ कि TB स्तर के logs को aggregate करने में समय लगता है
    फिर भी telecom कंपनियाँ आम तौर पर 2~3% bad debt को मानकर चलती हैं और customers के लिए नरमी दिखाती हैं
    Google को भी ऐसी स्थिति में इससे कहीं ज़्यादा graceful response देना चाहिए
    खासकर अगर AI key के public होते ही यह हुआ, तो Google को key scanning से इसे पहचानकर block करना चाहिए था
  • Gemini API docs के मुताबिक, project level और billing account level दोनों पर monthly spend limit सेट की जा सकती है
    लेकिन व्यवहार में यह feature सही से काम करता नहीं दिखता

• मेरा भी ऐसा ही अनुभव रहा है
  मैंने GCP में $100 का budget सेट किया था, लेकिन limit पार होने के 5 घंटे बाद ईमेल alert मिला
  हैरानी की बात है कि इस feature को priority नहीं दी जाती
  short term में Google की कमाई शायद कम हो जाए, लेकिन ऐसा अनुभव झेलने वाला developer फिर कभी इसकी सिफारिश नहीं करेगा

  • जब भी ऐसी बात सुनता हूँ तो गुस्सा आता है
    हमारी 2 लोगों की टीम एक runaway job की वजह से लगभग बर्बाद हो गई थी
    हमने GCP के recommended तरीके से alerts को kill switch से जोड़ा था, लेकिन alert 6 घंटे देर से आया
    आखिरकार refund पाने के लिए हमें सबूत देने पड़े
    Google ने कहा, “line items बहुत ज़्यादा थे इसलिए pipeline पीछे रह गई,” लेकिन क्या सिस्टम ऐसे ही हालात के लिए नहीं बनाया गया था?
  • यह समझना मुश्किल है कि alert delay कैसे स्वीकार्य हो सकती है
    आख़िर Google के साथ cost settlement कैसे हुआ, यह जानने की उत्सुकता है
  • सच तो यह है कि AWS भी इस feature को priority नहीं देता
    कोई भी cloud provider पैसे की धारा रोकने वाला feature पहले नहीं बनाता
  • “short-term revenue के लिए long-term trust छोड़ देना” — यही बात सटीक बैठती है
    यह late-stage capitalism का आदर्श उदाहरण है

• GitHub search results देखने पर पता चलता है कि public repositories में Gemini API tokens सीधे exposed मिले हैं
  Google लंबे समय तक API keys को secret नहीं मानता था, और LLM keys से अचानक उन्हें secret की तरह treat करने लगा
  संभव है कि लेखक ने frontend या code sharing के दौरान key expose कर दी हो

  • यह समस्या पहले भी रिपोर्ट की जा चुकी है, और Google ने कहा था कि वह leaked keys को Gemini API में block करेगा
    संबंधित HN thread और official docs में भी यह स्पष्ट लिखा है
    फिर भी ऐसे मामले दोबारा क्यों सामने आ रहे हैं, यह सवाल बना हुआ है
  • असल में search results में कोई वास्तविक key नहीं दिखती
  • leaked key पर तुरंत invalidate होने का संदेश आता है
    “Your API key was reported as leaked. Please use another API key.”
    यानी लगता है कि ज़्यादातर अपने-आप block हो जाती हैं
  • यह कहना कि API key को secret की तरह नहीं रखना चाहिए, बेमानी है

• Google Cloud में hard cap सेट करने का कोई आसान तरीका नहीं है
  मैंने भी एक घंटे से ज़्यादा settings खंगालने के बाद आख़िर Reddit पर Pub/Sub → Cloud Function → billing disable वाला तरीका ढूँढ़ा
  यह पूरी तरह पागलपन भरा ढाँचा है

  • मेरा पसंदीदा test यह है कि Gemini model से कहा जाए, “project की API usage लाने वाला script लिखो”
    इसकी 100% failure rate है
  • यह व्यावहारिक रूप से user trap (antifeature) है
  • शायद यह जानबूझकर ऐसा design किया गया है
    अगर user का खुद बनाया protection fail हो जाए, तो कहना आसान हो जाता है कि “यह हमारी ज़िम्मेदारी नहीं थी”
  • ऐसे feature का न होना दिखाता है कि कंपनी के पास users की सुरक्षा के लिए काफ़ी incentive नहीं है
  • AWS और Azure भी ऐसे ही हैं
    अच्छा होता अगर usage threshold पार होते ही kill-switch अपने-आप चल जाता
    5 घंटे का downtime मंज़ूर है, लेकिन इतना बड़ा bill नहीं

• यह पोस्ट पढ़ते ही मैंने तुरंत अपना Firebase plan downgrade कर दिया
  एक महीने में किसी ऐसे API के लिए $6,909 charge होने का मामला देखकर झटका लगा जिसे मैंने कभी call ही नहीं किया था
  मैंने भी पहले एक training session के दौरान API key बनाई थी, तो यह सोचकर घबराहट हुई कि कहीं उसकी फोटो तो नहीं ले ली गई होगी

  • क्या सच में उस session में किसी ने key की फोटो ली थी? वजह जानने की उत्सुकता है

• 2020~21 में मैं छात्रों को cloud services सिखाते समय AWS Free Tier इस्तेमाल करता था
  मैंने MediaWiki server चलाया, लेकिन spam accounts लगातार बनते रहे और security अस्थिर लगती थी
  ऐसा लगता था जैसे network ports पर हमेशा हमला हो रहा हो
  अंत में समझ आया कि budget को $20~30 तक सीमित करने का कोई तरीका नहीं है, और मैंने AWS छोड़ दिया
  cloud ऊपर से आसान लगता है, लेकिन असीमित cost explosion की वजह से यह individuals और companies दोनों के लिए जोखिम भरा है

• solo developers या छोटी teams के लिए public cloud एक डरावना और अस्थिर माहौल है
  safety rails नहीं हैं, और cost अनंत तक बढ़ सकती है
  इसलिए प्रोजेक्ट के काफ़ी समय का इस्तेमाल मैं cost monitoring और blocking logic पर करता हूँ
  पहले मैं सिर्फ साधारण VPS इस्तेमाल करता था, लेकिन अब कई बार Google या AWS services इस्तेमाल करनी पड़ती हैं
  फिर भी GCP थोड़ा बेहतर लगता है क्योंकि वहाँ प्रोग्रामmatically billing account link काटा जा सकता है

  • अगर कोई बस पैसे ही न दे तो क्या होगा, यह सोचने वाली बात है
    अमेरिका में शायद कानूनी समस्या हो, लेकिन दूसरे देशों में क्या होगा, पता नहीं

• ऐसे billing systems customer experience (CX) के नज़रिये से बेहद ख़राब तरीके से design किए गए हैं
  billing event-based है, इसलिए usage queue में जमा होती रहती है और aggregation में delay होता है
  alerts भी aggregation के बाद ही आते हैं, इसलिए delay होने पर limit काफ़ी पहले ही पार हो चुकी होती है
  यह ढाँचा कंपनी की रक्षा करता है, customer की नहीं
  अगर सच में customer-centric होते, तो hard limit पहुँचते ही उस रकम से ऊपर charge ही नहीं होना चाहिए था
  तभी कंपनी के पास अपने aggregation system को बेहतर बनाने की असली प्रेरणा होगी

  • दरअसल event-based होना खुद समस्या नहीं है
    prepaid plan या data cap services की तरह पहले से balance काटने वाले मॉडल में यह आसानी से संभव है
    आख़िरकार यह Google की business practice की समस्या है

• Google Cloud की official docs के अनुसार, आप emergency में billing account disable करके charging रोक सकते हैं
  official guide में “irreversible resource loss” का warning भी है
  लेकिन testing या internal apps के लिए यह एक अच्छा emergency brake है
  दूसरा alternative doc और budget alert setup doc भी देखने लायक हैं

  • लेकिन cost incur होने और alert आने के बीच कई घंटे से कई दिनों तक की delay हो सकती है
    मैंने 5 मिनट में $400 खर्च कर दिए थे

• हमारे साथ भी यही समस्या हुई थी
  जो key पहले secret नहीं मानी जाती थी, वह Gemini API enable करते ही secret बन गई, लेकिन कोई warning नहीं थी
  अच्छी बात यह रही कि alert से हमें जल्दी पता चल गया, इसलिए नुकसान $26,000 तक सीमित रहा
  हमने Google support से refund माँगा, लेकिन शुरू में मना कर दिया गया और अब मामला review में है
  ऐसे मामलों में जितना हो सके ऊपर तक issue escalate करना चाहिए