GitLab.com पर rate limits बदल रहे हैं

GitLab.com के नए API rate limits — anonymous users के लिए 60 requests per hour और free authenticated tier के लिए 5,000 प्रति hour — इस बात को लेकर चिंता पैदा कर रहे हैं कि humans, CI pipelines, और open source contributors सार्वजनिक projects के साथ कितनी आसानी से interact कर पाएँगे। कई लोग इस बदलाव को LLMs और bots द्वारा भारी automated scraping की प्रतिक्रिया तथा paywalls, authentication requirements, और कम खुले web की व्यापक प्रवृत्ति का हिस्सा मानते हैं। अन्य लोगों का तर्क है कि यह limits cost-control का उचित उपाय हैं जो sign-in या self-hosting को प्रोत्साहित करते हैं, लेकिन यह भी चिंता है कि इससे open source hosting और collaboration अधिक commercialized या fragmented मॉडलों की ओर धकेली जा सकती है।

अनुमानित कारण: LLM Scraping और Bot Traffic

  • बहुत से लोग मानते हैं कि सख्त limits का कारण LLM/agent scraping और automated traffic है।
  • कुछ लोग कहते हैं कि यह एक व्यापक बदलाव का शुरुआती कदम है: open web AI-scale scraping को संभाल नहीं सकता, इसलिए यह अधिक बंद, authenticated, और paywalled होता जाएगा।
  • अन्य लोगों का कहना है कि AI scraping को तकनीकी रूप से कम किया जा सकता है और इसे monetization के लिए एक सुविधाजनक justification के रूप में इस्तेमाल किया जा रहा है।

नई Rate Limits का प्रभाव

  • unauthenticated users को 60 requests/hour प्रति IP मिलते हैं; कई लोग नोट करते हैं कि औसतन यह “one request per minute” है, लेकिन संभवतः इसे token bucket के रूप में लागू किया गया है।
  • लोगों को चिंता है कि यह:
    • CGNAT या साझा school/office networks के पीछे मौजूद humans को प्रभावित करेगा।
    • issues/PRs को casual रूप से browse करना या multi-API-page loads को frustrating बना देगा।
  • logged-in free users को reportedly 5,000 requests/hour मिलते हैं, जिसे बहुत से लोग उचित मानते हैं।
  • कुछ लोग इसे वापस लिए जाने की भविष्यवाणी करते हैं; अन्य लोग सोचते हैं कि bot load को देखते हुए limits अभी भी बहुत उदार हो सकती हैं।

इंटरनेट और Commercialization पर व्यापक बहस

  • thread “non-commercial internet” की मांगों की ओर मुड़ जाता है, जिसमें ads या bots न हों, और जिसे users सीधे pay करें।
  • counterpoints:
    • जो भी मूल्यवान है, वह commercialization और abuse को आकर्षित करता है।
    • paywalls lower-income users को नुकसान पहुँचाते हैं; ISPs पहले से ही access को gate करते हैं।
    • bots को रोकने के लिए proof-of-identity privacy और anonymity को कमजोर करेगा।
  • कुछ लोग “indie web” approaches (personal sites, webrings) सुझाते हैं, लेकिन नोट करते हैं कि जो भी लोकप्रिय होगा, वह predators और spam को आकर्षित करेगा।

Open Source Funding और Paywalls

  • विचार: scrapers से charge करें और revenue को repos के साथ share करें, जैसे streaming royalties।
  • अन्य लोग “Cobra effect” incentives के बारे में चेतावनी देते हैं: fake repos और self-scraping से payouts हासिल करना।
  • चिंता है कि generic limits और “upgrade to Premium/Ultimate” मार्गदर्शन मिलकर OSS को effectively paywalled या private setups की ओर धकेलते हैं।

GitHub और अन्य Platforms

  • users GitHub पर बढ़ती friction देखते हैं (bot detection, सख्त logged-out limits)।
  • comparisons से पता चलता है कि unauthenticated 60/hour एक de facto norm बनता जा रहा है।
  • कुछ लोगों का मानना है कि AI scale पर generous unauthenticated access टिकाऊ नहीं है।

GraphQL, APIs, और Agents

  • कई लोग LLM agents के लिए GraphQL का उपयोग करने की सलाह देते हैं ताकि request counts और payload sizes कम हों।
  • अन्य लोग चेतावनी देते हैं कि complex GraphQL queries server-expensive हो सकती हैं, hidden limits से टकरा सकती हैं, और GitHub/GitLab जैसे backends पर दबाव डाल सकती हैं।
  • सामान्य राय: carefully scoped होने पर agents के लिए बेहतरीन; लेकिन servers के लिए खतरनाक अगर नहीं।

Self-Hosting और Alternatives

  • कुछ लोग external rate limits और भविष्य के paywalls से बचने के लिए self-hosted Git platforms (जैसे Forgejo, self-hosted GitLab) की ओर जा रहे हैं।
  • सुझाव है कि यदि आपको बड़े पैमाने पर unauthenticated access चाहिए, तो आपको अपना mirror या infrastructure चलाना चाहिए।