Copilot wycofał GPT-5.5, GPT-5.4 i Grok 4.5: zamienniki i audyt polityk modeli przez API

19 października GitHub wycofał z Copilota sześć modeli: GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini, Gemini 3.7 Flash i Grok 4.5. Tego samego dnia ogłosił, że polityki modeli można czytać i zmieniać przez REST API w wersji ogólnie dostępnej (GA). Teza tego tekstu jest praktyczna: jeśli w repozytorium masz przypięty któryś z tych modeli, znajdziesz go jednym poleceniem, a jeśli zarządzasz organizacją, sprawdzisz i włączysz następcę skryptem zamiast klikania po ustawieniach.

Przy modelach wycofywanych w październiku GitHub nie wymaga od nikogo żadnej czynności, żeby stare modele zniknęły. Zadanie dla Ciebie jest odwrotne: upewnić się, że następca jest włączony i że żadna konfiguracja nie wskazuje na model, którego już nie ma.

Co wycofano 19 października i czym to zastąpić

Changelog z 19 października 2026 podaje, że modele zostały wycofane z większości środowisk Copilota, w tym z czatu, edycji w linii, trybów ask i agent oraz uzupełniania kodu. Wszystkie sześć ma tę samą datę, 2026-10-19. Zamienniki z oficjalnej tabeli:

Reguła jest prosta: duże modele GPT zastępuje GPT-6.1 Sol, małe GPT-6 Luna, a w rodzinach Gemini Flash i Grok następca to kolejna wersja. Wszystkie cztery modele-następcy mają w dokumentacji obsługiwanych modeli status ogólnej dostępności (GA).

Uwaga: mapowanie zmieniło się od zapowiedzi

Zapowiedź z 18 września podawała inne nazwy następców: GPT-5.6 Sol zamiast GPT-6.1 Sol, GPT-5.6 Luna zamiast GPT-6 Luna i Grok 4.6 zamiast Grok 4.7. Tylko Gemini 3.8 Flash pozostał bez zmian. Jeśli zapisałeś sobie plan migracji we wrześniu, użyj tabeli z 19 października, bo to ona jest aktualna. Z kolei strona z historią wycofań w dokumentacji GitHuba podaje dla tych modeli tylko ogólne określenia („najnowszy model GPT Sol”, „najnowszy model GPT Luna”), więc konkretne nazwy bierz z changelogu.

W dokumentacji jest jeszcze jedna niespójność. Na dzień 22 października tabela historii wycofań nie zawiera Grok 4.5, a lista obsługiwanych modeli nadal wymienia go jako dostępny. Zdanie z changelogu jest jednoznaczne, więc traktuję Grok 4.5 jako wycofanego, ale to dobry powód, żeby sprawdzić selektor modeli u siebie.

Które konfiguracje mogły się zepsuć

Model możesz wskazać w kilku miejscach: w profilu agenta, w przejściu do kolejnego agenta (handoff), w ustawieniach edytora albo we własnych workflow. Dokumentacja VS Code opisuje pole model w pliku .agent.md jako tekst albo tablicę tekstów. Tablica oznacza kolejność preferencji, a Copilot używa pierwszego dostępnego modelu. Pole model w przejściu do kolejnego agenta przyjmuje nazwę w formacie <nazwa modelu> (copilot).

Czego nie znalazłem w przejrzanych stronach: opisu, co dokładnie robi agent, gdy w polu model jest jedna nazwa wycofanego modelu. Nie napiszę więc, że agent przestaje działać, ani że po cichu przełącza się na inny model. Sprawdź to na jednym agencie, zanim uznasz sprawę za zamkniętą. O tym, jak zbudować własnego agenta, pisałem w tekście jak stworzyć własnego agenta GitHub Copilot w VS Code.

Plik AGENTS.md w źródłach, które przejrzałem, nie ma pola z modelem. Szukaj w nim tylko wzmianek tekstowych, na przykład w instrukcjach „użyj GPT-5.5 do refaktoryzacji”. Jak ten plik współgra z Copilotem i innymi narzędziami, opisuje tekst AGENTS.md vs CLAUDE.md.

Jak znaleźć przypięte modele w repozytorium

Z katalogu głównego repozytorium uruchom wyszukiwanie po nazwach wycofanych modeli:

grep -rniP 'gpt-5\.5|gpt-5\.4(?![ -]?nano)|gpt-5[ -]mini|gemini[ -]3\.7[ -]flash|grok[ -]4\.5' \
  .github .vscode .claude AGENTS.md 2>/dev/null

Wyrażenie pomija GPT-5.4 nano, który nie był na liście wycofań. Dodaj własne katalogi, jeśli trzymasz konfigurację gdzie indziej, na przykład profile użytkownika w ~/.copilot/agents. Do tego sprawdź ręcznie model wybrany w selektorze VS Code, bo to ustawienie nie leży w repozytorium.

Jak włączyć następcę w polityce organizacji

Tu źródła GitHuba nieco się różnią i warto wiedzieć dlaczego. Zapowiedź z 18 września mówi, że przy domyślnym włączaniu modeli (default model enablement) następcy włączają się automatycznie w Copilot Business i Enterprise, chyba że administrator wyłączył globalne ustawienie domyślne albo sam model. Changelog z 19 października ostrzega ostrożniej: administratorzy Copilot Enterprise mogą potrzebować włączyć dostęp do modeli zastępczych w polityce modeli. Oba zdania da się pogodzić. Jeśli wyłączyłeś domyślne włączanie albo zablokowałeś model, nic nie włączy się samo. O tym samym mechanizmie pisałem przy okazji Gemini 4 Argon w Copilocie.

Globalną politykę domyślną, która zadziałała w organizacjach Business i Enterprise między 22 a 26 października, opisuję w tekście o trybie Assisted i globalnej polityce domyślnej. Przykład nowego modelu, który włącza się tą drogą, to GPT-6.1 Terra.

Ścieżki w interfejsie według dokumentacji:

• Organizacja (właściciel organizacji): ustawienia organizacji, Copilot, Models. Przy modelu wybierasz z listy Enabled albo Disabled. W tym samym miejscu ustawisz „Default availability for released models” dla modeli bez własnej konfiguracji.
• Przedsiębiorstwo (właściciel enterprise): AI controls, Copilot, Configure models. Każdy model ma stan włączony, wyłączony albo przekazany do decyzji organizacjom lub zespołom enterprise i aplikacjom.

Pamiętaj o zależnościach. Jeśli właściciel enterprise wymusił stan modelu, organizacja go nie zmieni (w interfejsie widać to jako ikonę blokady). A jeśli enterprise przeszło w tryb zespołów enterprise (opt-in preview), organizacja nie ma dostępu do ustawień modeli w ogóle.

Włączając następcę, sprawdź też, ile kosztuje w Twoim planie. Jak czytać limity i kredyty, opisuje tekst GitHub Copilot quota exceeded i limity.

REST API polityk modeli: co jest dostępne

Changelog z 19 października ogłasza, że punkty końcowe GET i PATCH dla polityk modeli są ogólnie dostępne na czterech poziomach. Dokumentacja REST pokazuje je pod nagłówkiem wersji API X-GitHub-Api-Version: 2026-03-10:

Różnice w szczegółach, które zauważyłem przy porównaniu źródeł:

• Changelog zapisuje ścieżkę zespołu z parametrem {team_slug}, a dokumentacja REST z parametrem {team_id} i opisem „unikalny identyfikator zespołu” (liczba całkowita). Trzymaj się dokumentacji.
• Tokeny klasyczne potrzebują zakresu read:enterprise (odczyt) lub admin:enterprise (zapis) dla enterprise oraz admin:org lub repo dla organizacji. Tokeny o szczegółowych uprawnieniach potrzebują uprawnienia „Enterprise AI controls” (enterprise) albo „Administration” organizacji (zapis).
• Punkty końcowe organizacji działają tylko dla organizacji niezależnej albo należącej do enterprise, które nie używa zespołów enterprise do polityki modeli.
• Aktualizacja jest atomowa: jeśli jednej zmiany z żądania nie da się zastosować, nie zapisze się żadna. Modele z odziedziczoną polityką enterprise są zablokowane i nie można ich zmienić.
• Przy zapisie na poziomie enterprise stan delegate_to_organizations jest dozwolony tylko w przedsiębiorstwach zarządzających Copilotem przez organizacje.

Odpowiedź zawiera default_availability oraz tablicę models z polami model_name, display_name i policy_state. W żądaniu zapisu używasz model_name zwróconych przez GET, więc nie zgaduj tych identyfikatorów.

Przykład: audyt i włączenie następców skryptem

Poniższe przykłady budują na ścieżkach i polach z dokumentacji, ale nie uruchamiałem ich na prawdziwej organizacji. Przed pierwszym zapisem przeczytaj wynik odczytu. Podstaw nazwę organizacji i token z uprawnieniami wymienionymi wyżej.

Odczyt polityk organizacji przez curl:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/orgs/ORG/copilot/model-policies

Ten sam odczyt przez GitHub CLI, z filtrem na następców z tabeli:

gh api -H "X-GitHub-Api-Version: 2026-03-10" /orgs/ORG/copilot/model-policies \
  --jq '.models[]
        | select(.display_name | test("GPT-6\\.1 Sol|GPT-6 Luna|Gemini 3\\.8 Flash|Grok 4\\.7"; "i"))
        | [.model_name, .display_name, .policy_state] | @tsv'

Filtr dopasowuje display_name, bo nie mam potwierdzonych identyfikatorów model_name dla tych czterech modeli. Jeśli wynik jest pusty albo któryś model ma stan disabled, masz do zrobienia pracę administracyjną. Dla modelu ze stanem disabled zapis wygląda tak (parametry z dokumentacji: models[].model_name i models[].policy_state o wartości enabled albo disabled):

echo '{"models":[{"model_name":"<MODEL_NAME_Z_ODCZYTU>","policy_state":"enabled"}]}' \
  | gh api --method PATCH -H "X-GitHub-Api-Version: 2026-03-10" \
      /orgs/ORG/copilot/model-policies --input -

Aby wykryć rozbieżności między organizacjami, wypisz stany w pętli i porównaj wynik:

for org in org-a org-b org-c; do
  gh api -H "X-GitHub-Api-Version: 2026-03-10" "/orgs/$org/copilot/model-policies" \
    --jq '.models[] | [.display_name, .policy_state] | @tsv' | sed "s/^/$org\t/"
done | sort -k2 > model-policies.tsv

W takim pliku od razu widać, w której organizacji następca jest wyłączony albo w której włączono model, który pozostałe wyłączyły. Taki skrypt możesz uruchamiać z harmonogramu i traktować zmianę wyniku jak alert. Na poziomie enterprise ten sam odczyt wykonasz na ścieżce /enterprises/ENTERPRISE/copilot/model-policies, a zespoły i aplikacje mają osobne ścieżki z tabeli.

Checklista administratora

1. Przeczytaj tabelę z changelogu z 19 października i zignoruj nazwy następców z zapowiedzi z 18 września.
2. Odczytaj politykę modeli (GET) i sprawdź stan GPT-6.1 Sol, GPT-6 Luna, Gemini 3.8 Flash i Grok 4.7.
3. Zdecyduj, czy chcesz włączyć następców jawnie, czy polegać na „Default availability”. Przy wyłączonym ustawieniu domyślnym nic nie włączy się samo.
4. Jeśli enterprise wymusza stan modelu albo używa zespołów enterprise, zmiana należy do właściciela enterprise.
5. Przejrzyj repozytoria poleceniem grep z tego tekstu i popraw pliki .agent.md, przejścia do kolejnych agentów oraz własne workflow.
6. W plikach agentów dla VS Code zapisuj model jako tablicę z modelem zapasowym zamiast jednej nazwy.
7. Uruchom odczyt API z harmonogramu i porównuj wynik z poprzednim.
8. Sprawdź kolejną falę wycofań z 16 listopada (niżej) i zaplanuj ją, zanim nadejdzie.

Co dalej: 16 listopada

W changelogu z 15 października GitHub zapowiedział kolejną falę, na 16 listopada 2026: Claude Opus 4.8, Claude Opus 5 (oba z następcą Claude Opus 5.5) oraz GPT-5.6 Terra (następca: GPT-6.1 Sol lub GPT-6 Luna). Claude Opus 4.8 pozostanie dostępny dla indywidualnych subskrybentów na planach rocznych. Przykładowy agent w moim tekście o własnych agentach Copilota używa właśnie GPT-5.6 Terra, więc ten sam przegląd konfiguracji przyda się za miesiąc. Dobór modeli do zadań opisuje przewodnik po modelach w Copilocie, a politykę modeli, której HydraFusion musi przestrzegać, omawiam w tekście o HydraFusion w GitHub Copilot. Podobny problem po stronie API OpenAI opisałem w tekście o wyłączeniu GPT-4o i GPT-4.1. O ograniczaniu tego, co agent może zrobić, a nie tylko tego, z jakiego modelu korzysta, czytasz w tekście o granicach dostępu agentów Copilota.

FAQ

Czy muszę coś zrobić, żeby stare modele zniknęły?

Nie. Changelog wprost mówi, że usunięcie wycofanych modeli nie wymaga żadnej czynności. Czynność jest po stronie administratora tylko wtedy, gdy następca nie jest włączony w polityce.

Czym zastąpić GPT-5.5 i GPT-5.4?

Według oficjalnej tabeli z 19 października modelem GPT-6.1 Sol. Dla GPT-5.4 mini i GPT-5 mini zalecany jest GPT-6 Luna.

Czy po wycofaniu moje pliki .agent.md przestały działać?

Nie potwierdziłem tego w dokumentacji. Opisuje ona pole model jako tekst lub tablicę z kolejnością preferencji, ale nie opisuje zachowania przy pojedynczym, wycofanym modelu. Sprawdź to praktycznie na jednym agencie i dodaj model zapasowy.

Które punkty końcowe REST API obsługują polityki modeli?

GET i PATCH dla przedsiębiorstwa, zespołu enterprise, aplikacji enterprise i organizacji. Ścieżki są w tabeli powyżej, a wersja API w dokumentacji to 2026-03-10.

Kto może zmieniać polityki modeli przez API?

W organizacji właściciel organizacji. W enterprise właściciel enterprise albo osoba z uprawnieniem write_enterprise_ai_controls do zapisu, a read_enterprise_ai_controls do odczytu.

Dlaczego punkty końcowe organizacji nie działają w mojej firmie?

Dokumentacja stawia warunek: organizacja musi być niezależna albo należeć do enterprise, które nie używa zespołów enterprise do polityki modeli. W trybie zespołów polityką zarządza się na poziomie enterprise. Jaki kod błędu zobaczysz w takim przypadku, dokumentacja nie mówi.

Źródła

• GitHub Changelog: GitHub Copilot models deprecated on October 19, 2026 (19.10.2026, tabela wycofanych modeli i następców)
• GitHub Changelog: Upcoming deprecation of selected GitHub Copilot models in mid-October (18.09.2026, zapowiedź z wcześniejszymi nazwami następców i opisem domyślnego włączania)
• GitHub Changelog: Upcoming deprecation of selected GitHub Copilot models in mid-November (15.10.2026, fala z 16 listopada)
• GitHub Changelog: Copilot model policy API for enterprise, orgs, and teams (19.10.2026, GA punktów końcowych GET i PATCH)
• GitHub Docs: REST API endpoints for Copilot model policy management (organizacja)
• GitHub Docs: REST API endpoints for enterprise AI controls (enterprise, zespoły enterprise, aplikacje enterprise)
• GitHub Docs: Supported AI models in Copilot (obsługiwane modele i historia wycofań)
• GitHub Docs: Managing availability of models in your enterprise i Managing the availability of models in an organization (ścieżki w interfejsie)
• VS Code Docs: Custom agent file reference (pole model jako tablica preferencji)