GitHub fasar ut sex Copilot-modeller 1 september: kontrollera undantaget och ersättaren

De sex modellerna och undantaget

GitHubs changelog från 31 juli anger samma stoppdatum för sex modeller och säger att ändringen gäller i alla Copilot-upplevelser, däribland Chat, inline-redigering, ask- och agentlägen samt kodkomplettering. Det betyder att inventeringen inte får stanna vid modellväljaren i VS Code. Ett team kan ha gjort explicita val i flera editorer, i ett agentflöde eller i en organisations- eller enterprisepolicy.

Den första ersättaren håller bara i nio dagar

Den daterade notisen är startpunkten, inte facit för modellvalet. Där står MAI-Code-1-Flash som ersättare för Raptor Mini den 1 september. Den 11 augusti publicerade GitHub en ny notis: MAI-Code-1-Flash pensioneras i sin tur den 10 september 2026 och ersätts av MAI-Code-1.1-Flash. Ett team som följer juli-tabellen ordagrant gör alltså två migreringar på nio dagar.

GitHubs aktuella stödsida listar både modeller som är tillgängliga nu och modeller som är planerade för pensionering. Den sidan visar den 25 augusti MAI-Code-1-Flash med stoppdatum 10 september och MAI-Code-1.1-Flash som stödd modell. Samma sida påminner om att tillgängligheten beror på Copilot-plan och klient. Välj därför inte en ersättare enbart för att namnet står i en äldre changelog: kontrollera stödtavlan samma dag som beslutet tas och bekräfta modellen i den klient där arbetet sker.

Inventera explicita val före policyn

Börja med de sex exakta modellnamnen. Sök i de repositories där teamet lagrar editorinställningar, agentdefinitioner, instruktioner och automationsfiler. Sök också i intern dokumentation och mallar som utvecklare kopierar från. En träfflista är bättre än en allmän fråga om ”vem som använder Copilot”, eftersom ett gammalt modellnamn kan ligga i en fil som körs sällan.

rg -n -i \
  -e 'Gemini 3\.1 Pro' \
  -e 'Claude Opus 4\.[56]' \
  -e 'Claude Sonnet 4\.[56]' \
  -e 'Raptor Mini' \
  .

Kommandot är en kandidatjakt, inte ett bevis på full täckning. Modellval som ligger i GitHubs webbgränssnitt, en lokal editorprofil eller ett externt konfigurationssystem finns inte nödvändigtvis i repositoryt. Lägg därför varje träff i en enkel tabell med fyra kolumner: yta, nuvarande modell, ansvarig person och tänkt ersättare. Markera separat om valet är användarstyrt, incheckat eller styrt av en central policy.

Kontrollera enterprise- och organisationspolicyn

På Copilot Business och Enterprise kan en ersättare vara stödd av GitHub men ändå blockerad för teamet. GitHubs nuvarande administratörsdokumentation låter en enterpriseägare sätta modeller till Enabled, Disabled eller Optional. En valfri modell kan sedan göras tillgänglig per organisation eller, i förhandsläget för enterprise-team, per team. På organisationsnivå kan ett beslut som enterpriseägaren har låst inte skrivas över.

Det andra ledet fångar fel som en skärmbild från administratörsvyn missar: användaren kan få sin licens från en annan organisation, klienten kan sakna stöd eller modellen kan vara otillgänglig för planen. GitHubs policyöversikt säger dessutom att policyer gäller på ytor där användaren autentiserar sig till Copilot, men att alla policyer inte gäller på varje yta. Skriv därför upp både identitet och klient i provprotokollet.

Kör ett smalt regressionsprov

Modellnamnet är inte ett utbytbart versionsnummer. En snabbare ersättare kan följa instruktioner annorlunda, använda verktyg på ett annat sätt eller ge en annan form på svaret. Välj tre till fem representativa uppgifter från teamets verkliga arbete: till exempel en kodkomplettering med lokala konventioner, en ändring över två filer och ett agentjobb som får använda ett avgränsat verktyg. Kör samma indata och samma behörigheter på den gamla och nya modellen före 1 september.

Sätt godkäntkriterier före körningen: vilka filer får ändras, vilka tester ska passera, vilket utdataformat krävs och vilka verktygsanrop är förbjudna? För den fulla metoden finns vår guide om att kontraktstesta AI-integrationen innan modellen uppdateras. Här räcker ett avgränsat pass som kan avslöja en blockerande skillnad innan stoppdatumet.

Ändra därefter ett ställe i taget: central policy först om den blockerar ersättaren, sedan incheckade konfigurationer och sist lokala val. Behåll en verifierad reservmodell om klienten erbjuder det. Den långsiktiga arkitekturen — abstraktionslager, fallback och hur du undviker att modellnamn sprids genom kodbasen — finns i guiden om modellbortfall och reservmodeller. Den här migreringen ska inte bygga om allt, men den ska lämna färre hårdkodade namn efter sig än den hittade.