GitHub Copilot इस महीने AI models के एक और समूह को retire कर रहा है।
GPT-5.5, GPT-5.4 के कई variants, Gemini 3.7 Flash और Grok 4.5 उन models में शामिल हैं जिन्हें 19 अक्टूबर को Copilot से हटाने की योजना है। कुछ अन्य models इसी महीने पहले retire हो चुके हैं।
अब यह कोई असामान्य बात नहीं रही।
पूरे 2026 में GitHub ने OpenAI, Anthropic, Google, xAI और अन्य के models जोड़े हैं, बदले हैं और retire किए हैं। आज developers को उपलब्ध कोई model कुछ ही महीनों में किसी नए model से बदल सकता है।
जो व्यक्ति Copilot से कोई function समझवाता है या test लिखने में मदद लेता है, उसके लिए यह शायद बहुत मायने न रखे।
लेकिन जिस कंपनी ने अपने internal coding agent के लिए कोई खास model परखकर मंज़ूर किया है, उसके लिए यह काफ़ी मायने रख सकता है।
इसलिए असली सवाल केवल यह नहीं है:
हमें कौन-सा AI model इस्तेमाल करना चाहिए?
सवाल यह है:
हमारा development workflow किसी खास model पर कितना निर्भर होना चाहिए?
Copilot के नीचे का model अब स्थिर नहीं रहा
AI coding assistants अब ज़्यादा से ज़्यादा किसी एक model से बंधे होने के बजाय कई models के ऊपर बैठते हैं।
उदाहरण के लिए GitHub Copilot कई प्रदाताओं के models देता है और users को उनमें से चुनने देता है। यह Auto model selection भी देता है, जिसमें Copilot कार्य और models की मौजूदा उपलब्धता के आधार पर model चुनता है।
GitHub ने एक कदम और आगे बढ़ाकर Auto को तीन पसंदों के आधार पर optimize करने की सुविधा दी है:
- Efficiency
- Balance
- Intelligence
यह एक सूक्ष्म लेकिन महत्वपूर्ण बदलाव है।
यह कहने के बजाय:
यही खास model इस्तेमाल करो।
developer अब धीरे-धीरे यह कह सकता है:
इस तरह के काम के लिए मुझे कोई उपयुक्त model दो।
चुनाव का ज़्यादा काम अब नीचे platform संभालता है।
coding के कई रोज़मर्रा के कार्यों के लिए शायद हमें यही चाहिए।
अगर एक सक्षम model की जगह दूसरा सक्षम model ले ले, तो developer को शायद परवाह करने की ज़रूरत न पड़े।
लेकिन यह AI-assisted development का केवल एक प्रकार है।
हर model dependency एक जैसी नहीं होती
AI workflows को तीन स्तरों में बाँटना उपयोगी रहता है।
1. बदलने योग्य (Replaceable)
मान लीजिए एक developer Copilot से कहता है:
समझाओ कि यह function क्या करता है और इसका एक साफ़-सुथरा implementation सुझाओ।
developer को एक उपयोगी उत्तर चाहिए।
अनुरोध एक सक्षम coding model संभाले या दूसरा, यह शायद ख़ास मायने न रखे।
ज़रूरत क्षमता की है, model के नाम की नहीं।
यहीं स्वचालित model routing सही बैठती है।
अगर platform गुणवत्ता, उपलब्धता और cost में संतुलन रखते हुए कोई उपयुक्त model चुन सकता है, तो किसी खास version पर निर्भरता बनाने का मूल्य बहुत कम हो सकता है।
2. चुना हुआ (Selected)
अब एक ऐसी team पर विचार कीजिए जिसने कई models की तुलना की और पाया कि कोई एक model किसी खास काम में विशेष रूप से अच्छा प्रदर्शन करता है।
हो सकता है वह किसी खास programming language को बेहतर संभालता हो।
हो सकता है कोई दूसरा routine transformations के लिए ज़्यादा तेज़ हो।
हो सकता है कोई एक बड़े codebases के लिए बेहतर परिणाम देता हो।
team जानबूझकर उसी model को चुन सकती है।
यह एक उचित निर्णय है।
लेकिन अब उस dependency का एक lifecycle बन जाता है।
अगर model retire हो जाए, तो team को कोई replacement चुनना होगा और यह तय करना होगा कि नया model उस कार्य के लिए अब भी पर्याप्त अच्छा व्यवहार करता है या नहीं।
model बदला जा सकता है, लेकिन पूरी तरह एक-दूसरे की जगह नहीं लिया जा सकता।
3. सत्यापित (Validated)
स्थिति तब फिर बदल जाती है जब कोई model किसी अनुमोदित engineering process का हिस्सा बन जाता है।
कल्पना कीजिए कि एक संगठन ऐसा internal coding agent बना रहा है जो repositories में बदलाव कर सकता है।
deployment से पहले संगठन उस model का मूल्यांकन अपने repositories, coding standards और security requirements के आधार पर करता है।
Security उसकी समीक्षा करती है।
Engineering उसे मंज़ूरी देती है।
team उसके behaviour को मापती है।
उसके आसपास policies configure की जाती हैं।
अब model बदलना केवल इतना नहीं रह जाता:
Copilot के menu से कोई दूसरा विकल्प चुन लो।
संगठन को उस validation का कुछ हिस्सा दोबारा करना पड़ सकता है।
ऐसी स्थिति में model की स्थिरता एक engineering और governance की आवश्यकता बन जाती है।
इस figure का accessible text विकल्प
coding workflow में AI model पर निर्भरता के तीन स्तर, बाएँ से दाएँ। बदलने योग्य (Replaceable): आपको एक सक्षम model चाहिए, और उसके retire होने पर platform दूसरे पर route कर सकता है, जैसे किसी function को समझाते समय। चुना हुआ (Selected): आपको किसी कारण से यही model चाहिए, और उसके retire होने पर आप replacement चुनते हैं और उसका behaviour जाँचते हैं, जैसे जब एक model किसी एक language के लिए सबसे अच्छा हो। सत्यापित (Validated): आपको एक अनुमोदित model चाहिए, और उसके retire होने पर आप उसे dependency upgrade की तरह दोबारा test करते हैं, जैसे किसी internal coding agent के लिए। बाएँ से दाएँ जाते हुए model की पहचान ज़्यादा मायने रखती है।
GitHub समस्या के दोनों पक्षों पर पहले से प्रतिक्रिया दे रहा है
दिलचस्प बात यह है कि GitHub पूरी तरह स्वचालित model switching या fixed models में से किसी एक पर दाँव नहीं लगा रहा।
वह दोनों का समर्थन कर रहा है।
एक तरफ़ Auto है।
Auto Copilot को उपलब्ध models में से चुनने देता है और efficiency, balance या intelligence के लिए optimize कर सकता है।
यह models को developer अनुभव के नीचे बढ़ती हद तक एक-दूसरे की जगह लेने योग्य infrastructure की तरह देखता है।
दूसरी तरफ़ GitHub ने 2026 में Long-Term Support model category शुरू की।
इसका पहला LTS model, GPT-5.3-Codex, पात्र GitHub Copilot Business और Enterprise ग्राहकों के लिए एक साल की उपलब्धता की प्रतिबद्धता के साथ आया।
GitHub ने एक कारण साफ़ बताया: models को मंज़ूर करने से पहले संगठनों को अपनी internal security और safety समीक्षाएँ पूरी करने के लिए समय चाहिए हो सकता है।
यह हमें एक महत्वपूर्ण बात बताता है।
models में तेज़ सुधार और enterprise की स्थिरता, दोनों वास्तविक आवश्यकताएँ हैं।
उत्तर केवल यह नहीं हो सकता:
हमेशा सबसे नया model इस्तेमाल करो।
और यह भी नहीं हो सकता:
हमेशा एक ही model को pin करो।
अलग-अलग workloads को अलग-अलग स्तर की स्थिरता चाहिए।
Model का चुनाव अब policy भी बनता जा रहा है
एक और बदलाव चुपचाप हो रहा है।
AI model चुनना अब हमेशा किसी अकेले developer का निर्णय नहीं रहा।
GitHub ऐसे enterprise controls देता है जिनसे administrators तय कर सकते हैं कि किसी संगठन के भीतर कौन-से models उपलब्ध होंगे।
कंपनियाँ अपनी आवश्यकताओं के आधार पर models तक पहुँच सीमित कर सकती हैं।
इसमें इस तरह के प्रश्न शामिल हो सकते हैं:
- कौन-से प्रदाता अनुमोदित हैं?
- data-handling की कौन-सी व्यवस्थाएँ स्वीकार्य हैं?
- कौन-से models internal evaluation पूरा कर चुके हैं?
- किस स्तर का cost स्वीकार्य है?
- क्या developers open-weight models इस्तेमाल कर सकते हैं?
- क्या teams अपनी provider व्यवस्थाओं के ज़रिए models ला सकती हैं?
एक बार ये निर्णय हो जाएँ, तो model बदलने का असर code लिखने वाले व्यक्ति से कहीं आगे तक जा सकता है।
यह governance, security review, cost controls और internal development standards को प्रभावित कर सकता है।
यहीं model churn केवल एक product update न रहकर एक संगठनात्मक मुद्दा बन जाता है।
Development teams को क्या करना चाहिए?
पहला कदम कोई जटिल model-management process बनाना नहीं है।
पहला कदम यह समझना है कि पहले से किस प्रकार की dependency मौजूद है।
हर महत्वपूर्ण AI-assisted workflow के लिए पूछिए:
क्या model बदलने योग्य (replaceable) है, चुना हुआ (selected) है या सत्यापित (validated) है?
अगर वह बदलने योग्य है, तो model के नाम पर अनावश्यक निर्भरता से बचिए। स्वचालित routing पर्याप्त हो सकती है।
अगर वह चुना हुआ है, तो दर्ज कीजिए कि वह model क्यों चुना गया था और उसके बदले जाने पर कौन-सा behaviour बचा रहना चाहिए।
अगर वह सत्यापित है, तो model बदलने को dependency upgrade की तरह लीजिए। replacement को उन्हीं आवश्यकताओं पर परखिए जिनके कारण मूल model को मंज़ूरी मिली थी।
यह भेद इसलिए मायने रखता है कि इसके बिना teams दो में से कोई एक गलती कर सकती हैं।
वे उन models को नियंत्रित करने में बहुत मेहनत लगा सकती हैं जिन्हें नियंत्रित करने की ज़रूरत नहीं है।
या वे उन workflows में models को एक-दूसरे का विकल्प मान सकती हैं जहाँ behaviour पहले से महत्वपूर्ण हो चुका है।
Abstraction शायद ऊपर की ओर खिसक रही है
Software developers यह pattern पहले देख चुके हैं।
हम अक्सर किसी low-level component को सीधे संभालने से शुरुआत करते हैं।
जैसे-जैसे ecosystem परिपक्व होता है, platforms ऐसी abstractions लाते हैं जो नीचे की ज़्यादा जटिलता को छिपा देती हैं।
AI development शायद उसी दिशा में बढ़ रहा है।
developers के बार-बार यह पूछने के बजाय:
मुझे कौन-सा model इस्तेमाल करना चाहिए?
platforms शायद उन्हें धीरे-धीरे यह बताने देंगे:
मुझे कम cost चाहिए।
मुझे तेज़ responses चाहिए।
मुझे मज़बूत reasoning चाहिए।
मुझे इस workflow के लिए अनुमोदित model चाहिए।
फिर platform तय कर सकता है कि कौन-सा model उस आवश्यकता को पूरा करता है।
GitHub का Auto model selection पहले से इसी दिशा की ओर संकेत करता है।
लेकिन LTS models का अस्तित्व उसी समय विपरीत दिशा की ओर संकेत करता है: कभी-कभी नीचे का model इतना मायने रखता है कि संगठनों को स्थिरता चाहिए।
ये दोनों दृष्टिकोण एक-दूसरे के विरोधी नहीं हैं।
ये दो अलग-अलग प्रकार के AI workload का प्रतिनिधित्व करते हैं।
नज़रिया
GitHub Copilot के भीतर models का तेज़ी से बदलना ऐसा लग सकता है जैसे AI उद्योग बहुत तेज़ी से आगे बढ़ रहा है और यह उसी का एक और लक्षण है।
इसे पढ़ने का एक ज़्यादा उपयोगी तरीका है।
हम यह खोजना शुरू कर रहे हैं कि model की पहचान कहाँ मायने रखती है और कहाँ नहीं।
सामान्य development सहायता के लिए model शायद धीरे-धीरे एक smarter routing layer के पीछे छिपा implementation detail बन जाए।
विशेषीकृत या governed workflows के लिए model शायद एक ऐसी dependency बना रहे जिसे evaluation, approval और नियंत्रित migration path चाहिए।
इससे development teams को किसी एक सर्वश्रेष्ठ coding model को खोजने की कोशिश से बेहतर एक सवाल मिलता है:
हमारे workflow का कौन-सा हिस्सा वास्तव में इस पर निर्भर करता है कि यह model ठीक यही model हो?
अगर उत्तर “लगभग कुछ नहीं” है, तो churn को platform पर छोड़ दीजिए।
अगर उत्तर में परखा हुआ behaviour, security approval, cost की मान्यताएँ या governance controls शामिल हैं, तो वह model आपके architecture का हिस्सा है, और उसके lifecycle पर ध्यान देना ज़रूरी है।
और पढ़ें: AI Agents Need a Control Plane उस governance layer को देखता है जो enterprises AI agents के आसपास जोड़ते हैं, और Building Agentic Systems, Part 2 बताता है कि agentic system को भरोसेमंद क्या बनाता है।
स्रोत और आगे पढ़ने के लिए
स्रोतों की समीक्षा: 4 अक्टूबर 2026।
- GitHub Docs — Supported AI models in GitHub Copilot। models की मौजूदा सूची और यह सूचना कि उपलब्धता बदल सकती है।
- GitHub Changelog — Selected models in GitHub Copilot deprecated, 2 October 2026। 2 अक्टूबर 2026 को retire हुए models और सुझाए गए replacements।
- GitHub Changelog — Upcoming deprecation of selected GitHub Copilot models in mid-October, 18 September 2026। वे models जिन्हें 19 अक्टूबर 2026 को Copilot से हटाने की योजना है।
- GitHub Docs — About Copilot auto model selection। Auto कार्य और उपलब्धता के आधार पर model कैसे चुनता है, और कौन-से models बाहर रखे जाते हैं।
- GitHub Changelog — Configure cost and quality in Copilot auto model selection, 14 September 2026। Efficiency, Balance और Intelligence की पसंदें।
- GitHub Changelog — GPT-5.3-Codex long-term support in GitHub Copilot, 18 March 2026। GitHub का पहला Long-Term Support model और Copilot Business तथा Enterprise के लिए उसकी उपलब्धता की प्रतिबद्धता।
- GitHub Docs — Custom agents configuration। custom agent के लिए model चुनना।
- GitHub Docs — Managing availability of models in your enterprise। enterprise owners models को कैसे enable या disable करते हैं।
- GitHub Docs — Enterprise managed settings। पूरे enterprise में Copilot CLI और VS Code के लिए केंद्रीय configuration।
- GitHub Docs — AI model comparison। coding कार्यों के लिए models की तुलना पर GitHub का मार्गदर्शन।