Koppla upp PR-Agent: GitHub Action, modellnyckeln och vad det kostar i tokens

Frågan som den här sidan besvarar är inte vad en PR-agent är – det är en annan artikel – utan vad som händer mellan att du bestämmer dig för att du vill ha PR-Agent på ditt repository och att den granskar en pull request. Gapet mellan de två punkterna är ungefär en YAML-fil och en modellnyckel, och de delar folk gör fel på är de som ingen dokumenterar: vilken installationsväg som är aktuell, vad standardmodellen kostar per granskning och varför en enda pull request kan debitera dig tio gånger.

PR-Agent är det öppen källkods-verktyg som CodiumAI byggde och senare donerade till communityn. Det finns nu i en egen GitHub-organisation som ett community-underhållet äldre projekt från Qodo, MIT-licensierat, med cirka 12,6k stjärnor och 1,7k forks. Det är gratis; de modellanrop det gör är det inte, och det är den enda siffran i den här konfigurationen som skalas med ditt team.

De tre installationsvägarna, och vilken du faktiskt vill ha

• GitHub Action – en workflow-fil som kör code>the-pr-agent/pr-agent@main/code> vid pull request-händelser. Detta är den rekommenderade vägen och den du bör börja med: den kräver ingen server, ingen webhook-endpoint och ingen hemlighet utöver modellnyckeln och den token som GitHub redan ger åtgärden.

• CLI:n — code>pip install pr-agent/code>, sedan code>pr-agent --pr_url <url> review/code>. Användbart för att prova en granskning mot en befintlig PR innan du kopplar upp något, och för att köra samma motor från en bärbar dator eller ett CI-jobb som inte är GitHub Actions.

• Containern och webhooken — Docker-avbildningen, eller den värdbaserade webhook-sökvägen för GitLab, Bitbucket, Azure DevOps och Gitea. Välj detta när dina repon inte finns på GitHub, eller när du behöver att granskningen körs inom din egen nätverksgräns.

Ett förbehåll värt att känna till innan du kopierar ett versionsnummer från en handledning: projektets egen dokumentation påpekar att det publicerade code>pip/code>-paketet för närvarande ligger efter den senaste utgåvan, och hänvisar användare till en installation via GitHub-tagg om de behöver den nyaste koden. Det är ett bestående tillståndsproblem snarare än en incident, men det innebär att "dokumentationen sa åt mig att pip install" och "jag har den aktuella utgåvan" inte är samma mening.

Modellnyckeln är det faktiska beslutet

PR-Agent levereras med modellstöd som är avsiktligt öppet. Versionsinformationen listar GPT-5.6 som den nya standarden, med stöd för Gemini 3.6 samt familjerna Claude Opus 5 och Claude Sonnet 5, och DeepSeek och Mistral fungerar via samma konfigurationsblock. Oavsett vilken du väljer är det du som anger nyckeln, och granskningen körs på ditt konto.

Det är avvägningen med öppen källkod i en mening: du äger infrastrukturen – nycklar, hemligheter, driftstid och fakturan – i utbyte mot en kostnad per granskning som inte har något med platser att göra. Ett team på fem utvecklare med ett värdbaserat verktyg som prissätts per plats betalar samma sak oavsett om det slår ihop tio pull requests i månaden eller tusen. Med tokenprissättning följer siffran det du faktiskt granskar, vilket är bättre när du har mycket att göra och sämre när du inte har det.

Två konfigurationsval påverkar den siffran mer än modellvalet gör:

• Kör en gång per pull request, inte en gång per push. Vissa verktyg granskar varje commit som standard. En PR med tio pushes blir tio granskningskörningar, tio modellanrop och tio gånger kostnaden, för nio granskningar av kod som inte längre finns. Kontrollera den här inställningen först, var du än distribuerar.

• Begränsa diffen.Vart och ett av dessa verktyg komprimerar diffen innan den når modellen, eftersom en ändring på 2 000 rader inte får plats i en prompt med utrymme att tänka. PR-Agents PR-komprimeringsstrategi är den kanoniska implementeringen. En genererad fil, en låsfil eller ett vendorerat beroende kan dominera diffen och kostnaden utan att innehålla något en granskare skulle läsa – uteslut dem.

Vad kommandona gör, och vad var och en kostar

När verktyget har installerats svarar det på snedstreckskommandon i pull requesten. Varje sådant är vanligtvis ett modellanrop, vilket är anledningen till att svar kommer inom tiotals sekunder och kostar bråkdelar av en cent:

• code>/describe/code> — skriver PR-titeln, sammanfattningen, genomgången och etiketterna enbart utifrån diffen.

• code>/review/code> – söker efter buggar, säkerhetsproblem och underhållbarhetsproblem, med allvarlighetsgrader och en poäng.

• code>/improve/code> — föreslår kodändringar som kan checkas in i stället för kommentarer.

• code>/ask/code> — besvarar en fråga med utgångspunkt i diffen, vilket är det kommando som granskare använder mest när de väl litar på verktyget.

• code>/update_changelog/code> – återskapar ändringsloggsposten för pull requesten.

Det automatiska beteendet som de flesta team vill ha är en enda code>/review/code> när en pull request öppnas. Allt annat kan lämnas till en kommentar, vilket håller kostnaden förutsägbar och håller agenten ur vägen för en granskare som redan läser.

Felmoderna som ingen varnar dig om

• Åtgärden lyckas men publicerar ingenting. Vanligtvis ett behörighetsproblem: workflow-token kan läsa diffen men inte skriva en kommentar. Kontrollera åtgärdens logg efter en 403 på kommentarsanropet innan du felsöker modellen.

• Den granskar fel diff. Pull requests från forks körs som standard med en begränsad token, och ett arbetsflöde som inte har konfigurerats för dem granskar en tom eller ofullständig diff och rapporterar inga fynd. Tystnad är inte ett friskintyg.

• Recensionen är självsäker och felaktig. Varje modellbaserad granskare kommer ibland att beskriva kod som inte finns i diffen. Åtgärden är strukturell snarare än på promptnivå: kräv att verktyget citerar de rader det klagar på, och behandla ett icke-citerat fynd som en kommentar snarare än som en spärr.

• Kostnaden smyger sig på. Inte på grund av en prisändring, utan på grund av omfattningen: fler repositorier, fler pushar per PR, större diffar. Sätt en månadsbudget på nyckeln du utfärdade för detta ändamål och behandla larmet som signalen om att något har förändrats i ditt arbetsflöde snarare än i modellen.

Var en router passar in, och var den inte gör det

En PR-agent är en av få AI-arbetsbelastningar där det verkligen är användbart att byta modell under pågående körning: den billiga första genomgången fångar formateringsfel och uppenbara defekter, och endast de pull requests som tar sig igenom den behöver en dyr modell. Det är precis det mönster som OrcaRouters OrcaCode Review-produkt implementerar – en snabb genomgång med en billig frontier-modell, eskalering till en starkare sådan när den första kontrollen hittar något – och det är också något du själv kan efterlikna med PR-Agent genom att peka dess konfiguration mot en gateway och routa efter PR-storlek.

Det en router inte gör är att få granskningen att bli korrekt. Värdet ligger i en enda nyckel för varje modell du kan tänkas jämföra, leverantörens listpris utan påslag, och failover när en leverantör har en dålig eftermiddag mitt i din merge-kö. Claude Opus 5.5 och Claude Sonnet 5.5, GPT-5.6 och Gemini-serien går alla att anropa via samma OpenAI-kompatibla endpoint, vilket gör "vilken modell som granskar vår kod" till en konfigurationsändring snarare än en upphandlingsövning.

Vad du ska göra den här veckan

• Installera GitHub Action i ett enda repository, inte i alla. Ett repository ger dig granskningskvaliteten och kostnaden per PR; alla ger dig båda sakerna dividerat med en omätt nämnare.

• Bestäm modellen genom mätning, inte genom rykte. Kör code>/review/code> på dina senaste tjugo mergade pull requests med två olika modeller och jämför de fynd som en människa instämde i. Det numret är det enda riktmärke som spelar roll här.

• Ställ in ”en gång per pull request” innan du ställer in något annat, och ange en budget för nyckeln.

• Behåll den mänskliga grinden. En PR-agent som blockerar merges är en PR-agent som ditt team hittar ett sätt att kringgå inom en månad.

Källanmärkning: Uppgifterna om PR-Agents ursprung, licens, antal stjärnor, installationsvägar, kommandouppsättning och modellstandardvärden, samt noteringen att pip-paketet ligger efter den senaste utgåvan, kommer från projektets eget kodförråd och dokumentation såsom de lästes den 4 november 2026. Prissättningen per användare och per kredit för de värdbaserade alternativen kommer från leverantörernas publicerade sidor och nämns endast som jämförelse. Grok och modellnamn används som konfigurationsexempel; modellidentifierarna på OrcaRouters gateway kontrollerades mot den aktuella modellistan samma datum. Fellägena är hämtade från hur dessa verktyg beter sig när arbetsflödestoken har för begränsad behörighet, inte från en specifik incidentrapport.