{"schema_version":"1.0","service":"Publicasta","type":"article","id":524,"slug":"github_copilot_model_retirement_workflow_migration","title":"GitHub wycofa cztery modele z Copilota. Jak przygotować migrację bez zgadywania","excerpt":"2 października z Copilota znikną cztery modele. Zespoły powinny sprawdzić dostęp i zasady, obsługę w używanych aplikacjach, koszty oraz wyniki prób na własnych zadaniach.","language":"pl","default_language":"en","canonical_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=pl","image":{"url":"https://publicasta.com/storage/projects/8/pages/524/2026/09/36618231-a8a7-4cc0-b021-44ed5452d883.webp","alt":"Zespół inżynierów analizuje schemat etapowej migracji między modelami AI"},"publisher":{"id":8,"slug":"ai_practice","name":"AI Practice","url":"https://publicasta.com/ai_practice"},"author":{"name":"Anton R"},"published_at":"2026-09-06T10:50:21+00:00","updated_at":"2026-09-06T10:50:21+00:00","content_markdown":"![Zespół inżynierów analizuje schemat etapowej migracji między modelami AI](https://publicasta.com/storage/projects/8/pages/524/2026/09/36618231-a8a7-4cc0-b021-44ed5452d883.webp)\n\n GitHub zapowiedział, że 2 października 2026 roku usunie z GitHub Copilot cztery modele: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code oraz Claude Opus 4.7. Zmiana ma objąć wszystkie wymienione w komunikacie sposoby korzystania z Copilota, w tym czat, edycję kodu bezpośrednio w edytorze, tryb pytań, tryb agenta i uzupełnianie kodu. Do tego dnia zespoły powinny zaktualizować procesy oraz integracje zależne od konkretnych modeli.\n\n Nie jest to jeszcze opis dokonanego wyłączenia, lecz termin planowanej zmiany. Ta różnica ma znaczenie operacyjne: pozostały czas warto przeznaczyć nie na pochopną zmianę modelu w pojedynczym ustawieniu, ale na odnalezienie wszystkich zależności, sprawdzenie uprawnień i porównanie działania na własnych zadaniach. Po terminie nie trzeba ręcznie usuwać starych modeli. Brak przygotowania może jednak ujawnić się dopiero wtedy, gdy ważny proces zacznie korzystać z innego modelu albo straci do niego dostęp.\n\n ## Sugerowany następca to początek migracji, a nie obietnica równoważności\n\n GitHub wskazuje następujące kierunki przejścia:\n\n - z Gemini 3.5 Flash lub Gemini 3.6 Flash na Gemini 3.8 Flash;\n- z Kimi K2.7 Code na Kimi K3;\n- z Claude Opus 4.7 na Claude Opus 5.\n\n Takie przyporządkowanie ułatwia rozpoczęcie migracji, ale nie dowodzi, że nowy model zachowa się identycznie. Modele mogą różnić się trafnością, czasem odpowiedzi, skłonnością do podawania nieprawdziwych informacji i przydatnością w poszczególnych zadaniach. GitHub zaleca dobór modelu do zastosowania, a nie wyłącznie do nazwy. Dokumentacja produktu nie zastąpi jednak próby przeprowadzonej na kodzie, zasadach i typowych poleceniach danego zespołu.\n\n Pierwszym krokiem powinien być spis miejsc, w których wybór modelu jest jawny albo ukryty. Należy objąć nim zapisane konfiguracje, automatyzacje, integracje, instrukcje dla programistów oraz ustawienia domyślne organizacji i przedsiębiorstwa. Osobno warto zanotować procesy, w których użytkownik wybiera model ręcznie, te korzystające z modelu ustawionego domyślnie oraz te oparte na automatycznym wyborze. Są to odmienne zależności i mogą wymagać innych poprawek.\n\n Taki spis powinien odpowiadać nie tylko na pytanie „jaki model?”, lecz także „gdzie i dla kogo?”. Ten sam zespół może używać czatu w kilku aplikacjach, rozszerzenia do środowiska programistycznego, Copilot CLI oraz przepływów działających w trybie agenta. Dostępność modelu zależy od planu, zasad administratora i używanego interfejsu, a także może się zmieniać. Oznaczenie modelu jako ogólnie dostępnego nie oznacza więc, że pojawi się on od razu w każdym miejscu pracy.\n\n ## Najpierw dostęp i zgodność używanych narzędzi\n\n W Copilot Business i Copilot Enterprise administratorzy mogą potrzebować zezwolić na modele zastępcze w zasadach dotyczących modeli. Ustawienie może zostać narzucone przez właściciela przedsiębiorstwa, przekazane do decyzji organizacji albo wynikać z domyślnej dostępności. Sama obecność następcy w dokumentacji nie wystarcza: trzeba sprawdzić ustawienie administracyjne oraz listę modeli widoczną dla rzeczywistego użytkownika w używanej aplikacji.\n\n Szczególnej uwagi wymaga Kimi K3. GitHub zalicza go do modeli o otwartych wagach, które w planach Business i Enterprise są domyślnie wyłączone niezależnie od ogólnego ustawienia dostępności. Jeżeli nie obowiązują inne ograniczenia, administrator może zezwolić na niego wprost. Migracja z Kimi K2.7 Code zakończy się więc powodzeniem dopiero po potwierdzeniu zasad, uprawnień i faktycznej obecności Kimi K3 tam, gdzie ma być używany.\n\n Trzeba również uwzględnić wersje klientów i rozszerzeń. Według bieżącej dokumentacji minimalne wersje są jeszcze określane jako wstępne: dla części obsługi Gemini 3.8 Flash widnieje informacja, że wymaganie nie zostało ustalone, natomiast dla Kimi K3 podano VS Code 1.131, a dla Claude Opus 5 — VS Code 1.128.0. Nie należy traktować tych liczb jako wieczystych. Są punktem kontrolnym na czas przygotowań i wymagają ponownego sprawdzenia przed wdrożeniem.\n\n ## Próba na własnych zadaniach zamiast oceny po nazwie\n\n Porównanie powinno odtwarzać rzeczywistą pracę, a nie opierać się na kilku efektownych poleceniach. Warto przygotować niewielki, lecz reprezentatywny zestaw zadań: wyjaśnianie istniejącego kodu, poprawę błędu, zmianę obejmującą kilka plików, tworzenie testów, przegląd różnicy między wersjami, pracę zgodną z instrukcjami repozytorium oraz uzupełnianie kodu. Nie każdy zespół potrzebuje wszystkich tych prób; ważne, by zestaw odzwierciedlał zadania, od których naprawdę zależy jego tempo i jakość.\n\n Te same przypadki należy wykonać na modelu wycofywanym i proponowanym następcy, z możliwie takim samym kontekstem, poleceniem i ustawieniami. Ocena nie powinna kończyć się na wrażeniu, że odpowiedź „brzmi lepiej”. Przydatne kryteria to poprawność rozwiązania, zgodność z ograniczeniami, liczba potrzebnych poprawek, wynik testów, czas do uzyskania akceptowalnej zmiany oraz to, czy model nie wymyślił interfejsów, plików albo zachowań, których nie ma w repozytorium.\n\n W trybie agenta znaczenie ma również zakres wykonanych działań. Należy sprawdzić, czy model właściwie planuje pracę, korzysta z dostępnych narzędzi, respektuje granice zadania i nie wprowadza zmian poza potrzebnym obszarem. W czacie ważniejsza może być jakość objaśnień i umiejętność wskazania niepewności, a przy uzupełnianiu kodu — odsetek trafnych podpowiedzi i ilość późniejszych poprawek. Jeden zbiorczy wynik może ukryć różnice między tymi zastosowaniami.\n\n Próba ma służyć decyzji, nie tworzeniu pozoru niezależnego rankingu. Dokumentacja GitHuba opisuje cechy produktu, nie jest natomiast testem konkretnego repozytorium. Zespół nie powinien dopisywać wyników, których nie zmierzył, ani przenosić cudzych ocen na własne środowisko. Jeśli następca sprawdza się dobrze w jednych zadaniach, a gorzej w innych, rozsądnym wynikiem może być podział zastosowań między kilka dostępnych modeli zamiast jednej wymiany dla całej organizacji.\n\n ## Koszt trzeba policzyć na rzeczywistym użyciu\n\n Cennik z 6 września 2026 roku pokazuje, że podobieństwo nazwy nie musi oznaczać podobnej ceny. Stawki za milion tokenów wynoszą odpowiednio:\n\n - Gemini 3.5 Flash: 1,50 dolara za tokeny wejściowe, 0,15 dolara za wejście z pamięci podręcznej i 9 dolarów za wyjście;\n- Gemini 3.6 Flash i Gemini 3.8 Flash: 0,75 dolara za wejście, 0,075 dolara za wejście z pamięci podręcznej i 3,75 dolara za wyjście;\n- Kimi K2.7 Code: 0,95 dolara za wejście, 0,19 dolara za wejście z pamięci podręcznej i 4 dolary za wyjście;\n- Kimi K3: 3 dolary za wejście, 0,30 dolara za wejście z pamięci podręcznej i 15 dolarów za wyjście;\n- Claude Opus 4.7 i Claude Opus 5: 5 dolarów za wejście, 0,50 dolara za wejście z pamięci podręcznej, 6,25 dolara za zapis w pamięci podręcznej i 25 dolarów za wyjście.\n\n To migawka cennika, a nie prognoza rachunku. Jeden kredyt AI odpowiada 0,01 dolara, natomiast uzupełnianie kodu i podpowiedzi następnej edycji nie zużywają tych kredytów. Ostateczny koszt zależy od planu, funkcji, liczby tokenów i wykorzystania pamięci podręcznej. Równe stawki Claude Opus 4.7 i Claude Opus 5 nie przesądzają też o równym zużyciu: modele mogą potrzebować innej ilości kontekstu i generować odpowiedzi różnej długości.\n\n Dlatego warto zestawić koszt z wynikiem użytecznym dla zespołu. Tańsza odpowiedź, której poprawa zajmuje dużo czasu, może być gorszym wyborem niż droższa odpowiedź zaakceptowana po pierwszej próbie. Z kolei droższy model nie przynosi automatycznie lepszego wyniku w prostym zadaniu. Sensowną miarą jest koszt zaakceptowanego zadania lub ukończonego etapu pracy, obliczony na podstawie obserwowanego użycia, a nie samej tabeli stawek.\n\n W przypadku przejścia z Kimi K2.7 Code na Kimi K3 różnica cennikowa jest na tyle wyraźna, że wymaga osobnego oszacowania. Nie oznacza to, że migracja jest nieopłacalna; oznacza jedynie, że nie wolno założyć neutralności kosztowej. Przed szerszym udostępnieniem należy zmierzyć typową długość wejścia i wyjścia, częstotliwość użycia oraz liczbę zadań zakończonych akceptowalnym wynikiem.\n\n ## Ustawienie domyślne, wybór ręczny i tryb Auto to trzy różne sprawy\n\n Od 2 września ustawienia zarządzane na poziomie przedsiębiorstwa pozwalają wybrać dostępny model domyślny dla nowych rozmów oraz zmienić ten wybór dla poszczególnych zespołów przedsiębiorstwa. GitHub ogłosił tę możliwość jako ogólnie dostępną dla planów Business i Enterprise w aplikacji Copilot, Copilot CLI i VS Code. Nie należy rozciągać tej deklaracji na inne interfejsy, których komunikat nie wymienia.\n\n Model domyślny wpływa na rozpoczęcie nowej rozmowy, ale nie jest tym samym co model wybrany ręcznie ani mechanizm Auto. W praktyce trzeba więc sprawdzić osobno nowe rozmowy, istniejące instrukcje nakazujące wybór konkretnego modelu i procesy pozostawiające decyzję użytkownikowi. Warto też odnotować, czy ustawienie pochodzi z poziomu przedsiębiorstwa, organizacji czy zespołu. Bez tego lokalna poprawka może zostać zastąpiona przez ustawienie nadrzędne.\n\n Auto może być rozsądnym rozwiązaniem awaryjnym, ale nie gwarantuje zachowania przypiętego modelu. Mechanizm dobiera model z uwzględnieniem dostępności, stanu systemów i złożoności zadania, pozostając przy tym w granicach planu oraz zasad organizacji. Zestaw modeli branych pod uwagę może się zmieniać. W obsługiwanych interfejsach można sprawdzić, którego modelu faktycznie użyto, i tę informację warto zapisywać podczas prób oraz po wdrożeniu.\n\n Jeśli proces wymaga powtarzalnego zachowania albo został zatwierdzony pod kątem określonego modelu, samo włączenie Auto nie zamyka migracji. Trzeba najpierw ocenić je na tych samych przypadkach co bezpośredniego następcę. Auto może natomiast ograniczyć ryzyko braku dostępności w zadaniach, w których dopuszczalna jest zmienność i dla których zespół potrafi kontrolować wynik.\n\n ## Wdrożenie etapami i plan wycofania\n\n Po testach najlepiej zacząć od małej grupy użytkowników lub wybranego rodzaju zadań. Etap pilotażowy powinien mieć określony czas, właściciela decyzji oraz warunki rozszerzenia: na przykład brak nowych błędów krytycznych, akceptowalny czas realizacji i koszt mieszczący się w ustalonym zakresie. Równie ważne są warunki zatrzymania, takie jak utrata dostępu w istotnym interfejsie, powtarzające się naruszenia instrukcji repozytorium lub nagły wzrost kosztu ukończonego zadania.\n\n Przez okres przejściowy warto zachować wyniki prób, użyte polecenia, wersje aplikacji i rozszerzeń, faktycznie wykorzystany model oraz decyzję osoby oceniającej. Nie chodzi o gromadzenie wszystkich rozmów bez ograniczeń, lecz o możliwość wyjaśnienia, dlaczego migracja została zaakceptowana i gdzie pojawiła się różnica. Zapis musi respektować zasady ochrony kodu i danych obowiązujące w organizacji.\n\n Plan awaryjny nie może opierać się na powrocie do modelu, który 2 października ma zniknąć. Powinien wskazywać inny dostępny model, bezpieczny sposób ręcznego wykonania krytycznego zadania albo czasowe ograniczenie funkcji. Należy go przećwiczyć przed terminem, ponieważ niewidoczny dla użytkownika model zapasowy nie pomoże, jeśli blokują go zasady administratora lub nieobsługiwana wersja aplikacji.\n\n ## Lista decyzji przed 2 października\n\n Gotowość do zmiany można ocenić za pomocą kilku konkretnych pytań:\n\n 1. Gdzie zapisano lub narzucono wybór jednego z czterech wycofywanych modeli?\n2. Które funkcje Copilota i które używane aplikacje zależą od tego wyboru?\n3. Czy proponowany następca jest dozwolony przez zasady przedsiębiorstwa i organizacji oraz widoczny dla użytkownika?\n4. Czy używane wersje aplikacji i rozszerzeń zapewniają jego obsługę?\n5. Jak następca wypada na reprezentatywnych zadaniach pod względem poprawności, czasu, wymaganych poprawek i nieprawdziwych odpowiedzi?\n6. Jaki jest koszt zaakceptowanego wyniku przy rzeczywistym zużyciu, a nie tylko stawka za milion tokenów?\n7. Czy ustawienie domyślne, ręczny wybór oraz Auto zostały sprawdzone jako osobne ścieżki?\n8. Kto zatwierdza wdrożenie, kto je obserwuje i jaki jest plan awaryjny po wycofaniu starego modelu?\n\n Odpowiedzi powinny trafić do właścicieli konkretnych procesów, nie pozostać wyłącznie w centralnym dokumencie. Administrator odpowiada za dostęp i zasady, lecz osoba utrzymująca automatyzację najlepiej wie, gdzie model został wskazany na stałe. Programiści mogą z kolei ocenić, czy wynik jest użyteczny w praktyce. Migracja wymaga połączenia tych perspektyw.\n\n Największym błędem byłoby potraktowanie daty jako przypomnienia o zmianie nazwy w menu. GitHub podał sugerowanych następców i zakres planowanego wycofania, ale nie obiecał identycznej jakości, opóźnienia, dostępności ani kosztu. Zespół, który przed 2 października zinwentaryzuje zależności, sprawdzi zasady i wersje narzędzi, powtórzy własne zadania oraz wdroży zmianę etapami, zamienia wymuszoną migrację w kontrolowaną decyzję techniczną.","available_translations":[{"language":"ar","title":"قبل 2 أكتوبر: خطة عملية للاستعداد لإيقاف أربعة نماذج في GitHub Copilot","html_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=ar","markdown_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=ar","json_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=ar"},{"language":"de","title":"Copilot will vier Modelle einstellen: So gelingt die Umstellung bis zum 2. Oktober","html_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=de","markdown_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=de","json_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=de"},{"language":"en","title":"GitHub Copilot Is Retiring Four Models: A Practical Migration Plan","html_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=en","markdown_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=en","json_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=en"},{"language":"es","title":"GitHub Copilot retirará cuatro modelos: cómo preparar la migración sin improvisar","html_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=es","markdown_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=es","json_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=es"},{"language":"fr","title":"GitHub Copilot retire quatre modèles : préparer la migration avant le 2 octobre","html_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=fr","markdown_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=fr","json_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=fr"},{"language":"pl","title":"GitHub wycofa cztery modele z Copilota. Jak przygotować migrację bez zgadywania","html_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=pl","markdown_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=pl","json_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=pl"},{"language":"ru","title":"Copilot отключит четыре модели: как подготовить рабочие процессы к 2 октября","html_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=ru","markdown_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=ru","json_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=ru"},{"language":"zh","title":"GitHub Copilot 四款模型将下线：迁移不只是在下拉菜单里换个模型","html_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=zh","markdown_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=zh","json_url":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=zh"}],"_links":{"self":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=pl","api":"https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=pl","html":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=pl","canonical":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=pl","markdown":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=pl","json":"https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=pl","channel":"https://publicasta.com/api/public/v1/channels/ai_practice","channel_articles":"https://publicasta.com/api/public/v1/channels/ai_practice/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}