GitHub ändrar Copilot-policy och fakturering: kontrollera säten, retention och reviewnivå

Tre datum kräver tre separata beslut

Från den 1 september 2026 börjar GitHub åter öppna registrering för nya Copilot Business- och Enterprise-kunder som betalar med kreditkort eller PayPal. För sådana nya kunder måste varje ny plats betalas innan användaren får Copilot-åtkomst. För befintliga kunder med samma betalningsmetoder börjar nästa steg den 1 oktober: alla tilldelade Business- och Enterprise-platser debiteras i förskott vid nästa faktureringsperiods början.

Den tredje kontrollpunkten ligger tidigast den 28 september. Då ska Copilot Chat på github.com, Copilot Chat i GitHub Mobile och Copilot cloud agent samlas i en upplevelse och en policy. Samma datum börjar värdet Default använda Balanced för Copilot code review. Formuleringen ”tidigast” är viktig: behandla 28 september som sista dag för förkontrollen, men dokumentera även det faktiska lanseringsdatumet för ert konto.

Räkna på tilldelade säten, inte aktiva användare

GitHubs faktureringsdokumentation definierar ett säte som en licens tilldelad en användare. Det är därför fel kontrollfråga att bara räkna vilka som använde Copilot förra veckan. Leta efter vilande konton, konsulter som lämnat projektet, dubbletter över organisationer och platser som tilldelats för ett kort prov men inte återkallats. Om samma person har plats i flera organisationer inom samma företag debiteras företaget enligt dokumentationen bara en gång, men rapportens organisationskolumn visar vilken organisation som bär platsen.

En återkallad plats ger ingen proportionell återbetalning; borttagningen slår igenom i nästa månatliga period. En plats som läggs till mitt i perioden proportioneras däremot från tilldelningsdagen till periodens slut. Det gör tidpunkten viktig. Gör inventeringen före periodstart och spara både antalet tilldelade platser och ändringslistan, så går nästa faktura att stämma av mot ett faktiskt underlag.

Överskriden inkluderad användning kan kräva extra betalning för fortsatt Copilot-användning, och den inkluderade användningen kan proportioneras tillsammans med platskostnaden. Exportera därför både sätesrapport och användningsrapport. Bekräfta sedan att spend controls fortfarande har avsedd gräns och att ett tekniskt test inte kan köpa extra AI-krediter utan namngiven kostnadsägare.

Den enhetliga policyn ändrar också datans livslängd

När den nya upplevelsen lanseras ersätts separata policyer för de tre angivna ytorna med en gemensam policy, aktiverad som standard. Att inte göra något behåller Copilot på github.com och i Mobile. Att välja bort den enhetliga upplevelsen gör enligt GitHub att användarna förlorar åtkomst på just dessa två ytor efter lanseringen. Gör alltså inte en opt-out som ett snabbt sätt att undvika retentionfrågan utan att först dokumentera verksamhetseffekten.

Den materiella dataändringen är att Copilot på github.com går över till agent sessions-upplevelsen. Chatdata ska då behållas under kontots livstid i stället för 28 dagar, i linje med cloud agent. Det är inte samma sak som att all Copilot-data får en ny generell retention. Avgränsa kontrollen till chatdata i den annonserade github.com-upplevelsen och jämför den längre lagringen med er godkända dataklassning, åtkomstmodell och process när ett konto stängs.

GitHubs policyöversikt säger att företagspolicyer sätts på företagsnivå först och att de för de flesta funktioner kan aktiveras, stängas av eller lämnas till organisationen. Därför behöver protokollet skilja konfigurerat värde från effektivt värde. Kontrollera företag, organisation och en representativ användare, och använd audit log för att se vem som ändrade policyn. Monkeybases tidigare genomgång av Copilots globala modellpolicy äger frågan om ärvd modelltillgång; här är fokus den nya gemensamma upplevelsen och retentionen.

Default blir Balanced den 28 september

För befintliga och nya organisationer och repositoryn som använder värdet Default börjar GitHub använda Balanced den 28 september 2026. Om ni vill behålla Lite ska ni välja Lite uttryckligen före datumet. Organisationsvärdet gäller repositoryn utan eget val, medan ett repositoryvärde styr automatiskt begärda granskningar där. Vid manuellt begärd review kan användaren välja effort i PR:ns Reviewers-yta.

Balanced är inte bara en etikett. GitHubs dokumentation beskriver längre analys med en modell för mer resonerande bearbetning, fler AI-krediter och möjligen marginellt fler GitHub Actions-minuter än Lite. Som storleksordning uppskattar GitHub för närvarande en typisk Lite-granskning till AI-krediter värda 0,05–1 USD och Balanced till 0,25–5 USD, exklusive Actions-minuter. Intervallen kan ändras och är inte en offert. Mät därför faktisk förbrukning i ett representativt repository innan ni låter Default styra brett.

Den tidigare Monkeybase-nyheten om stora och botskapade pull requests visar hur policy, betalningsägare och faktisk review-täckning provas. Använd samma bevisform här, men byt jämförelsevariabel: kör en likvärdig manuell och automatisk granskning före och efter förändringen, spara effort-nivån från PR-översikten och stäm av AI-krediter samt Actions-förbrukning. Skillnaden ska kunna hänföras till nivåvalet, inte till olika pull requests.

Stoppa överlämningen om ni bara har skärmdumpar från inställningssidorna men inget effektivt användarprov eller ingen rapporterad förbrukning. Målet är inte att varje team ska välja Lite eller Balanced, utan att standarden, datalagringen och kostnadsunderlaget ska vara medvetna beslut som går att verifiera efter ändringen.