Copilot-granskning får API-stöd – men Balanced blir standard

8 oktober 2026 kl. 12:00|Författare: QUASA:s redaktion|5 min läsning| 1

GitHubs ändringslogg från den 2 oktober 2026 anger att Copilot code review nu kan begäras via REST och GraphQL, med möjlighet att välja granskningsnivå för varje begäran. API-stödet är allmänt tillgängligt för Copilot Pro, Pro+, Max, Business och Enterprise. Samma besked bekräftar att inställningen Default började använda Balanced den 28 september 2026 i nya och befintliga arkiv och organisationer som använder Copilot-granskning.

För ett utvecklingsteam betyder det att ett eget arbetsflöde kan begära granskning av en bestämd pull request. Om ingen nivå väljs för begäran behöver teamet känna till vilken inställning som gäller för användaren och arkivet: ett tidigare uttryckligt val av Lite behölls när standarden ändrades. Balanced ger en djupare analys och kan använda mer resurser, så även ett oförändrat automatiskt flöde kan få en annan förbrukning än tidigare.

REST: begär Copilot som granskare

Startpunkten i REST är en granskarbegäran för den pull request som arbetsflödet hanterar. I GitHubs referens för granskarbegäranden anges POST /repos/{owner}/{repo}/pulls/{pull_number}/requested_reviewers, en lista med granskarnas inloggningsnamn i fältet reviewers och behörigheten Pull requests: write för en finfördelad token. Copilots granskaridentitet är copilot-pull-request-reviewer[bot]. Owner, repo och pull_number ska avse samma pull request som utlöste jobbet.

Ett minimalt REST-flöde identifierar först arkivet och pull request-numret från händelsen, skickar därefter en POST med copilot-pull-request-reviewer[bot] i reviewers-listan och följer sedan upp resultatet. En accepterad granskarbegäran är ännu ingen färdig granskning. GET på samma resurs visar begärda granskare, medan GET /repos/{owner}/{repo}/pulls/{pull_number}/reviews hämtar granskningsposter när de finns.

För läsning med en finfördelad token anger API-referensen Pull requests: read. Begärda granskare och granskningar av publika resurser kan också läsas utan autentisering. Den skillnaden är användbar i ett arbetsflöde med separata token: kontroll av status behöver inte få den skrivrättighet som krävs för att starta granskningen. POST till /pulls/{pull_number}/reviews har däremot ett annat syfte: det skapar en granskningspost från anroparen och är inte anropet som begär Copilots arbete.

GraphQL använder pull request-objektets id

För team som redan använder GraphQL är motsvarigheten mutationen requestReviewsByLogin. Den tar pullRequestId, alltså pull request-objektets node-id, och botLogins med värdet copilot-pull-request-reviewer[bot]. Fältet union kan användas för att lägga till granskaren i den befintliga uppsättningen i stället för att ersätta den. Svaret kan innehålla pull request-objektet, men även här måste arbetsflödet vänta på den faktiska granskningsposten innan det behandlar granskningen som slutförd.

GitHub har lanserat nivåval per API-begäran, men de vanliga offentliga parametertabellerna för REST-begäran och GraphQL-mutationen anger inte ett namngivet fält för valet. Det gör ett påhittat effort-fält till en osäker grund för ett produktionsflöde. Ett team som behöver styra Lite eller Balanced för varje anrop bör först kontrollera det dokumenterade anropsformatet för den API-version och klient som används; annars styr tillämpliga inställningar den begäran som skickas.

Balanced ger djupare analys och högre möjlig förbrukning

Lite är inriktat på snabb, riktad återkoppling om tydliga problem som buggar, sårbarheter och stilavvikelser. Balanced använder en modell med mer utrymme för analys av komplex logik, säkerhetskänslig kod och ändringar mellan tjänster. Valet gäller granskningsdjupet, inte vilka ändringar som skickas till Copilot. Därför kan en övergång från Default som tidigare gav Lite till Default som nu ger Balanced ändra kostnadsbilden även om antalet pull requests är detsamma.

CodeLabs genomgång återger GitHubs uppskattning att en Lite-granskning vanligen förbrukar AI-krediter motsvarande 0,05–1 USD och en Balanced-granskning 0,25–5 USD. Intervallen är uppskattningar, inte fasta priser. Storleken på en pull request och egna instruktioner påverkar förbrukningen, och GitHub Actions-minuter ingår inte i beloppen.

Kostnaden beror också på vem som begär granskningen och hur ofta arbetsflödet gör det. En ny API-begäran efter en kodändring kan vara avsiktlig; en begäran som upprepas när samma webhook levereras igen kan ge en onödig körning. För Business och Enterprise är budgetgränser för AI-krediter därför relevanta när granskningar flyttas från en manuell handling till ett automatiskt jobb.

Det befintliga flödet avgör effekten av standardbytet

Team som redan har automatisk Copilot-granskning behöver jämföra inställningarna med den nya API-utlösaren. En granskning kan redan begäras när en pull request öppnas eller uppdateras. Ett separat jobb som också skickar en begäran vid samma händelse behöver därför känna till vad som redan har beställts. En användbar kontrollpunkt är kombinationen av arkiv, pull request, senaste commit och avsedd granskningsnivå.

Före ändringen: Notera vilka händelser som startar automatisk granskning, om Lite har valts uttryckligen på någon tillämplig nivå och vilken budget som gäller.
Vid API-begäran: Kontrollera rätt pull request och tokenbehörighet samt om samma commit redan har en begärd eller slutförd granskning med den avsedda nivån.
Efteråt: Skilj en mottagen begäran från en publicerad granskningspost och kontrollera vilken nivå som faktiskt användes samt förbrukningen av AI-krediter och GitHub Actions-minuter.

Inställningar för granskningsnivå finns på företags-, organisations-, arkiv- och personnivå, och en mer specifik inställning kan åsidosätta en överordnad. Ett uttryckligt Lite-val fortsätter att gälla där det har gjorts. För ett team som låter Default styra blir följden däremot konkret vid nästa beställda granskning: arbetsflödet kan nå samma pull request som tidigare, men Copilot kan lägga mer analys och fler AI-krediter på den.

Läs också:

Dela: