GitHub Copilot mění nabídku modelů: říjnové konce podpory a přechod na náhrady

GitHub v zářijovém oznámení stanovil konec podpory několika modelů v Copilotu na 19. října 2026. Změna se týká různých způsobů práce, od chatu po úpravy a doplňování kódu. Náhrada modelu vyžaduje kontrolu pracovního postupu, ne pouze výběr nového jména v nabídce. Jiná varianta může odpovídat odlišně i na stejné zadání a stejné soubory.

Stav v tomto rozboru je ověřen k 25. říjnu 2026, tedy po uvedeném termínu. Vysvětlujeme oficiálně doporučené náhrady, administrativní nastavení a vlastní návrh ověření přechodu. Nejde o náš výkonnostní test programovacích modelů. Podobně znějící Microsoft 365 Copilot je jiná nabídka než GitHub Copilot pro vývojáře.

Které modely GitHub vyřadil a co doporučil

Oznámení z 18. září uvádí šest položek s datem ukončení 19. října. Pro Gemini 3.7 Flash doporučuje Gemini 3.8 Flash. U GPT‑5.5 a GPT‑5.4 ukazuje na GPT‑5.6 Sol. Za GPT‑5.4 mini a GPT‑5 mini uvádí GPT‑5.6 Luna. Grok 4.5 má podle přehledu nahradit Grok 4.6.

To jsou doporučení konkrétního oznámení, nikoli automaticky seznam nejnovějších modelů na trhu. Pokud dnes vybíráte jinou podporovanou variantu, posuzujte ji zvlášť. Záměna mezi službami může navíc skrýt odlišné podmínky: dostupnost modelu v přímém API neznamená jeho dostupnost ve vašem plánu Copilotu.

GitHub změnu vztahuje na své podporované zkušenosti s Copilotem, včetně chatu, úprav, dotazovacího a agentního režimu i doplňování. Nepředpokládejte, že přechod ovlivní pouze jednu konverzaci. Nejprve si sepište, kde tým vybrané modely skutečně používá a které kroky na jejich chování závisejí.

Dostupnost řídí také správce organizace

U firemních plánů může rozhodovat nastavení modelových zásad. Oznámení popisuje automatické povolení doporučených náhrad při výchozím nastavení, pokud správce globální výchozí volbu nevypnul nebo konkrétní model nezakázal. Nelze tedy každému uživateli slíbit, že všechny náhrady okamžitě uvidí.

Pokud chybí požadovaná možnost, začněte kontrolou pracovního účtu, organizace a příslušného nastavení. Stejný člověk může používat osobní a firemní prostředí s jinými pravidly. Změna klienta nebo vytvoření nové konverzace sama neřeší zákaz na úrovni organizace. Správce potřebuje znát konkrétní požadovanou variantu a účel.

Povolení modelu není rozhodnutí, že jej mají všichni používat na všechno. Oddělte seznam dostupných možností od týmového doporučení pro jednotlivé úlohy. Pro rutinní návrh komentáře můžete mít jiné požadavky než pro zásah do autentizace nebo migraci dat. Pravidlo má být srozumitelné i kolegovi, který se do týmu připojí později.

Nejdřív zjistěte skutečný rozsah používání

Začněte krátkým soupisem pracovní praxe. Zeptejte se vývojářů, jak model vybírají, zda používají uložené instrukce a které výstupy přebírají do dalších kroků. Není nutné sbírat obsah všech soukromých konverzací. Potřebujete porozumět typům práce a závislostem, ne vytvářet nový archiv citlivého kódu.

U každé úlohy si zaznamenejte výchozí podklady, očekávaný výsledek a místo kontroly. Například doplnění testu k existující funkci má jiný konec než úprava několika propojených modulů. Pokud starší postup počítal s konkrétním formátem odpovědi, ověřte, zda jej náhrada zachovává. Technicky správná odpověď může být pro navazující skript nepoužitelná.

• Který model je v daném prostředí skutečně vybraný?
• Jde o osobní volbu, nebo týmovou zásadu?
• Kde vzniká návrh a kde se potvrzuje změna?
• Které testy prokazují správné chování aplikace?
• Kdo řeší výjimku, pokud nová varianta selže?

Výsledkem má být malý přehled konkrétních postupů. Pokud není jasné, jak dosavadní model pomáhal, nebude ani možné poctivě vyhodnotit přínos náhrady. Samotná změna nabídky pak snadno vede k náhodnému přepínání bez poznatků použitelných pro celý tým.

Připravte tři různé úlohy pro ověření

První úloha může být malá a snadno kontrolovatelná: doplnění testu pro známou okrajovou podmínku. Druhá má prověřit práci s kontextem, například opravu chyby, jejíž příčina je v jiném souboru než viditelný projev. Třetí má ověřit zdrženlivost: zadání s chybějícím požadavkem, který model nemá domyslet za vlastníka produktu.

Používejte stejný výchozí stav projektu. Pokud se mezi pokusy mění závislosti nebo už kolega část chyby opravil, výsledky nejsou přímo srovnatelné. Připravte samostatnou pracovní větev nebo jinak izolovanou kopii odpovídající vašemu běžnému postupu. Zkouška nemá nechtěně změnit skutečnou produkční aplikaci.

Předem určete správný konec. U testu je důležité, zda zachytí původní problém. U opravy, zda vyřeší chybu bez porušení jiného chování. U nejasného zadání, zda model pojmenuje chybějící informaci. Uhlazené vysvětlení v chatu nemůže tyto podmínky nahradit.

Příklad změny, která vypadá dobře a přesto nestačí

Představme si funkci, která zpracovává datum dodání. Nový model navrhne elegantnější převod a přidá test běžného dne. V zadání ale bylo důležité rozlišit prázdnou hodnotu od skutečného data a zachovat chování na přelomu časových pásem. Oprava může projít jednoduchou ukázkou a přesto změnit význam dat.

Do přejímací sady proto přidejte neúplný vstup, hranici dne a neočekávaný formát. Tyto příklady nevznikají proto, aby byl model záměrně neúspěšný. Mají zastupovat skutečné podmínky vašeho produktu. Pokud je dosavadní funkce zvládala, náhrada asistenta nemá být důvodem je přestat kontrolovat.

Zaznamenejte také čas potřebný k opravě návrhu. Model, který vytvoří krátkou změnu správně napodruhé, může být provozně výhodnější než model s působivým, ale rozsáhlým přepisem. Takové rozhodnutí vyžaduje vaše skutečné výsledky. Z oznámení o ukončení podpory je nelze odvodit.

Agentní režim potřebuje hranice změn

Při agentní práci může asistent navrhovat nebo provádět několik navazujících kroků. Určete mu povolený rozsah: konkrétní problém, dotčené soubory a potřebné kontroly. Přidání nové funkce, výměna knihovny a plošné přeformátování nejsou automatickou součástí opravy jedné chyby.

Před přijetím změny projděte rozdíl proti výchozímu stavu. Všímejte si odstraněných testů, potlačených chyb a změn konfigurace. „Testy prošly“ není dostatečný závěr, pokud byly mezitím podmínky testů oslabeny. Kontrola má sledovat skutečný produktový požadavek, nejen zelený výsledek příkazu.

Pomoci může i stručný kontrolní seznam pro recenzenta. Ten má znát původní chybu a důvod změny, nikoli celou historii rozhovoru s AI. Převzetí kódu do běžného vývoje proto doplňte popisem výsledného chování a smysluplnou validací. Odpovědnost za přijetí změny zůstává součástí týmového procesu.

Co dělat s uloženými návody a instrukcemi

Pokud firemní návod přímo doporučuje vyřazený model, upravte jej v rámci příslušné správy dokumentace. Neomezujte změnu na název. Ověřte také, zda dávají smysl uvedené kroky a snímky rozhraní. Starý návod může být matoucí i tehdy, když je jeho hlavní myšlenka stále správná.

Instrukce postavte na požadovaném výsledku a ověřitelných hranicích. Místo závislosti na jedné obvyklé formulaci odpovědi určete potřebná pole, příklady a přípustné výjimky. To usnadní další přechod v budoucnu. Podrobnější principy práce s kontextem najdete v rozboru modelu GPT‑6.1 Sol.

Po změně dejte uživatelům krátkou informaci: která možnost skončila, jaká náhrada je povolená a kde hlásit problém. Není nutné opisovat všechny technické parametry modelu. Kolega potřebuje především vědět, jak bezpečně pokračovat ve své běžné práci a jaký výsledek se od něj očekává.

Cena, limit a kvalita se posuzují samostatně

Náhrada v Copilotu se neúčtuje automaticky stejně jako přímé API příslušného výrobce. Ověřte konkrétní plán, pravidla použití a dostupné informace o spotřebě. Tokenový ceník jiné platformy není spolehlivou předpovědí účtu GitHubu. Do porovnání patří také potřebné funkce pracovního prostředí.

Stejně oddělte rychlost odpovědi a čas do přijaté změny. Rychlý návrh může být výhodný při jednoduché orientaci v kódu. Složitý problém může vyžadovat více kontextu a důkladnější ověření. Tým by měl vědět, kdy volí rychlé doplnění a kdy práci, jejíž chyba může mít významný dopad.

Při vyhodnocení sledujte opakované vzorce. Jestliže se většina problémů týká nejasného zadání nebo chybějících podkladů, samotná změna modelu nemusí stačit. Někdy pomůže zlepšit dokumentaci projektu, zpřehlednit testy nebo úlohu rozdělit. Nový model není náhradou za tyto části vývoje.

Jak poznat, že přechod skončil

Uzavření není jen okamžik, kdy starý model zmizí z nabídky. Máte mít dostupnou povolenou náhradu, ověřené běžné úlohy, upravené relevantní návody a jasného vlastníka podpory. Zbylé problémy označte konkrétně, aby nezůstaly schované v obecném „už to funguje“.

Připravte krátký záznam s datem, prostředím, vybraným modelem a výsledkem zkoušky. Pokud se dvě skupiny uživatelů liší oprávněním, uveďte tuto odlišnost. Závěr z osobního účtu neprokazuje stejnou nabídku v podnikové organizaci. Stejně tak lokální editor a jiné rozhraní nemusí mít totožnou dostupnost všech funkcí.

Po přechodu dál sbírejte skutečné chyby a používejte je jako další kontrolní příklady. Nemusíte neustále opakovat všechny zkoušky bez důvodu. Nové ověření má smysl po změně modelu, důležité konfigurace nebo při opakovaném problému. Evidence má pomáhat práci, nikoli se stát samoúčelnou administrativou.

Časté otázky

Musí uživatel staré modely ručně odstranit?

Oznámení uvádí, že po ukončení podpory není třeba provádět samostatné odstranění. Důležitější je dostupnost vhodné náhrady a aktualizace pracovních postupů, které na starou volbu spoléhaly.

Proč doporučenou náhradu nevidím?

Zkontrolujte účet, prostředí a firemní modelové zásady. Správce mohl změnit výchozí povolování nebo konkrétní model zakázat. Při řešení uveďte přesné označení požadované varianty a místo, kde ji očekáváte.

Znamená doporučení automaticky stejný výkon?

Jde o doporučený směr přechodu. Vlastní kvalitu pro konkrétní kód ověřte na reprezentativních úlohách a proti známému správnému výsledku. Samotné podobné jméno modelu shodu chování neprokazuje.

Máme přejít rovnou na úplně jinou rodinu?

Je to samostatné rozhodnutí. Nejprve určete, jaký problém má změna řešit, a porovnejte dostupnost, náklady a přijaté výsledky. Zrušení staré možnosti samo neurčuje jednu univerzálně nejlepší náhradu pro celý tým.

Končí stejný model současně také u jeho výrobce?

Oznámení GitHubu popisuje nabídku GitHub Copilotu. Nelze z něj automaticky vyvodit stejný termín vypnutí přímého API výrobce nebo jiné služby. Pokud tým používá model také mimo Copilot, vytvořte pro toto použití samostatný seznam závislostí a ověřte příslušné oznámení. Shodné jméno může skrývat jiné rozhraní, smluvní podmínky i harmonogram podpory. Při přechodu proto evidujte dodavatele služby vedle jména modelu. Pomůže to také při komunikaci s podporou, protože problém s dostupností ve firemním editoru se nemusí týkat vlastního vývojářského projektu.