GitHub Copilot থেকে ছয় মডেল যাচ্ছে—১৯ অক্টোবরের আগে workflow বদলান
GitHub ১৮ সেপ্টেম্বর জানিয়েছে, GitHub Copilot-এর ছয়টি AI মডেল ১৯ অক্টোবর ২০২৬ অবসরে যাবে। GitHub-এর আনুষ্ঠানিক ঘোষণায় Gemini 3.7 Flash, GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini ও Grok 4.5-এর নাম রয়েছে; পরিবর্তনটি Copilot Chat, inline edits, ask ও agent mode এবং code completion-সহ সব Copilot experience-এ কার্যকর হবে।
অর্থাৎ ১৯ অক্টোবরের আগে শুধু Chat-এর model selector নয়, পুরোনো মডেল নির্দিষ্ট করে রাখা workflow ও integration-ও বদলাতে হবে। ১৯ সেপ্টেম্বর প্রকাশিত NEXSIGHT AI WIRE-এর প্রতিবেদন একই ছয় মডেলের নির্ধারিত অবসর, চারটি প্রস্তাবিত বিকল্প এবং Business ও Enterprise administrator-দের policy যাচাইয়ের প্রয়োজন নিশ্চিত করেছে।
ছয় মডেলের বদলে যে চারটি বিকল্প
GitHub প্রতিটি বিদায়ী মডেলের জন্য একটি suggested alternative দিয়েছে। এই তালিকা migration-এর সরাসরি mapping; এটি পুরোনো ও নতুন মডেলের output, latency, reasoning বা tool-use আচরণ সমান হওয়ার নিশ্চয়তা নয়।
- Gemini 3.7 Flash থেকে Gemini 3.8 Flash
- GPT-5.5 থেকে GPT-5.6 Sol
- GPT-5.4 থেকে GPT-5.6 Sol
- GPT-5.4 mini থেকে GPT-5.6 Luna
- GPT-5 mini থেকে GPT-5.6 Luna
- Grok 4.5 থেকে Grok 4.6
ছয়টি পুরোনো মডেলের বিপরীতে বিকল্প চারটি, কারণ GPT-5.5 ও GPT-5.4—দুটির গন্তব্য GPT-5.6 Sol। একইভাবে GPT-5.4 mini ও GPT-5 mini-এর জন্য GPT-5.6 Luna প্রস্তাব করা হয়েছে। ফলে migration inventory-তে শুধু ছয়টি নাম প্রতিস্থাপন করলেই হবে না; আগে ভিন্ন কাজে ব্যবহৃত দুটি মডেল একই successor-এ গেলে সেই কাজগুলোর আচরণ আলাদাভাবে যাচাই করতে হবে।
Enterprise policy স্বয়ংক্রিয় সুবিধা আটকাতে পারে
Copilot Business ও Copilot Enterprise-এ default model enablement চালু থাকলে প্রস্তাবিত বিকল্পগুলো স্বয়ংক্রিয়ভাবে enabled হওয়ার কথা। তবে administrator global default বন্ধ করে রাখলে অথবা নির্দিষ্ট বিকল্প মডেল explicitly disabled করলে তা স্বয়ংক্রিয়ভাবে চালু হবে না। তখন Copilot settings-এর সংশ্লিষ্ট model policy থেকে access দিতে হবে।
Policy-তে অনুমতি পাওয়া আর সব client-এ মডেলটি ব্যবহার করতে পারা এক বিষয় নয়। GitHub-এর supported-model নথি বলছে, availability ব্যবহারকারীর Copilot plan ও ব্যবহারের জায়গার ওপর নির্ভর করে এবং সময়ের সঙ্গে বদলাতে পারে; একই নথির বর্তমান তালিকায় ছয় বিদায়ী মডেল ও চার বিকল্পই GA হিসেবে আছে।
Client version-ও এই যাচাইয়ের অংশ। নথিতে GPT-5.6 Luna ও GPT-5.6 Sol-এর জন্য Visual Studio Code 1.128.0 minimum হিসেবে দেওয়া আছে, কিন্তু কয়েকটি অন্য IDE ও plugin-এর ঘরে এখনো TBD লেখা। তাই model selector-এ বিকল্প দেখা না গেলে policy বদলানোর আগে plan, client support এবং IDE বা extension version—তিনটিই মিলিয়ে দেখা দরকার।
Hard-coded reference কোথায় খুঁজবেন
GitHub workflow ও integration হালনাগাদ করতে বলেছে, কিন্তু কোনো প্রতিষ্ঠানের model reference কোথায় রাখা আছে তা তার নিজস্ব configuration-এর ওপর নির্ভর করে। নিচের inventory তাই ব্যবহারিক migration checklist, GitHub প্রকাশিত কোনো সর্বজনীন configuration specification নয়।
- Repository ও organization-managed configuration-এ ছয়টি বিদায়ী মডেলের নাম এবং ব্যবহৃত model ID খুঁজুন। YAML, JSON, environment variable, reusable workflow ও shared agent configuration-এর মতো version-controlled বা centrally managed জায়গা আগে পরীক্ষা করুন।
- Custom agent, saved automation এবং Copilot-সংযুক্ত third-party tool নির্দিষ্ট model parameter পাঠায় কি না দেখুন। Display name-এর পাশাপাশি integration-এর নিজস্ব configuration-এ সংরক্ষিত প্রকৃত identifier শনাক্ত করুন।
- Copilot Business বা Enterprise settings-এ প্রতিটি replacement-এর policy state দেখুন। Default availability চালু আছে ধরে না নিয়ে মডেলটি explicitly disabled কি না পরীক্ষা করুন।
- দলের ব্যবহৃত প্রতিটি IDE, extension বা plugin-এ বিকল্প মডেলটি পাওয়া যাচ্ছে কি না যাচাই করুন। নথিতে minimum version অনির্দিষ্ট থাকলে সংশ্লিষ্ট client-এ উপস্থিতি নিশ্চিত না করে production migration সম্পন্ন ধরে নেবেন না।
শুধু repository-wide search-এ দৃশ্যমান নাম বদলানো যথেষ্ট নাও হতে পারে। কোনো integration vendor-specific identifier ব্যবহার করলে তার documentation বা বর্তমান request configuration থেকে সঠিক replacement value নিতে হবে; অনুমান করে ID বানালে policy-তে মডেল enabled থাকলেও automated request ব্যর্থ হতে পারে।
Replacement চালু হওয়ার পর যে পরীক্ষা দরকার
Suggested alternative মানে স্বয়ংক্রিয়ভাবে সমমানের ফল নয়। তাই migration-এর পর একটি ছোট, প্রতিনিধিত্বশীল regression set চালিয়ে পুরোনো ও নতুন configuration-এর ফল তুলনা করা উচিত। Agent workflow-তে tool invocation, অনুমোদিত file-edit scope, instruction অনুসরণ এবং কাজের সমাপ্তি; inline completion-এ repository convention, গ্রহণযোগ্যতা ও latency দেখা যেতে পারে। এগুলো সম্পাদকীয়ভাবে প্রস্তাবিত validation step, GitHub প্রকাশিত benchmark নয়।
Fallback পথও আলাদাভাবে পরীক্ষা করা প্রয়োজন। Primary replacement ব্যবহার করা না গেলে workflow অন্য অনুমোদিত supported model নেয়, নাকি পুরোনো pinned reference-এ থেমে যায়—তা সময়সীমার আগেই জানা দরকার। একই সঙ্গে runtime বা usage reporting-এ প্রকৃত model name দেখা গেলে configuration বদলালেও কোনো পুরোনো reference সক্রিয় থেকে গেছে কি না শনাক্ত করা সহজ হবে।
GitHub বলেছে, অবসরের পর পুরোনো মডেল সরাতে ব্যবহারকারীর আলাদা পদক্ষেপ লাগবে না। এর অর্থ শুধু Copilot থেকে retired model অপসারণের কাজ হাতে করতে হবে না; পুরোনো reference-সহ automation নিজে থেকেই সঠিক replacement বেছে নেবে—এমন প্রতিশ্রুতি ঘোষণায় নেই।
১৯ অক্টোবরের আগে প্রয়োজনীয় শেষ অবস্থা
বর্তমান নিশ্চিত অবস্থান হলো, ছয়টি মডেল ১৯ অক্টোবর ২০২৬ সব GitHub Copilot experience থেকে অবসরে যাওয়ার জন্য নির্ধারিত এবং GitHub চারটি বিকল্প প্রস্তাব করেছে। Business ও Enterprise environment-এ default enablement বিকল্পগুলো চালু করতে পারে, কিন্তু global default বন্ধ বা নির্দিষ্ট model blocked থাকলে administrator-এর হস্তক্ষেপ লাগবে।
সময়সীমার আগে প্রতিটি ব্যবহৃত workflow-এর জন্য তিনটি বিষয় নিশ্চিত করা দরকার: replacement policy-তে অনুমোদিত, প্রয়োজনীয় client-এ উপলভ্য এবং পুরোনো reference ছাড়াই বাস্তব কাজ সম্পন্ন করছে। Supported-model matrix পরিবর্তনশীল হওয়ায় migration-এর দিন এবং ১৯ অক্টোবরের কাছাকাছি সময়ে availability ও minimum-version তথ্য আবার মিলিয়ে দেখাই বাকি অনিশ্চয়তা সামলানোর সবচেয়ে নির্ভরযোগ্য উপায়।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।