GitHub Copilot Auto model selection: test de drie tiers

Wil je weten of Efficiency, Balance of Intelligence het beste bij je team past? Herhaal dezelfde codeertaken onder iedere instelling en beoordeel ze met dezelfde tests en reviewregels. De naam van een tier vertelt wat Copilot probeert te prioriteren; ze voorspelt niet welk model elke taak krijgt of hoe goed de code wordt.

Gepubliceerd: 2026-10-06 · Laatst bijgewerkt: 2026-10-06 · Auteur: Joost Heijden

Dit is een demo-opzet voor een fictieve repository. Er zijn geen Copilot-runs uitgevoerd en er worden geen prijs- of kwaliteitsresultaten geclaimd. Het doel is een eerlijk vergelijk: dezelfde taak, dezelfde startcode, dezelfde beoordelingslat.

Wat verandert er tussen Efficiency, Balance en Intelligence?

De tiers veranderen de voorkeur van Auto; ze zetten niet elk een vast model vast. GitHub beschrijft Efficiency als kostenvoorkeur, Balance als afweging tussen kosten, kwaliteit en latency, en Intelligence als kwaliteitsvoorkeur. Dezelfde modellen blijven beschikbaar binnen de tierselectie, voor zover plan en beheerbeleid ze toestaan.

Volgens de aankondiging van 14 september 2026 kan Auto voor iedere prompt een passend model kiezen uit dezelfde beschikbare modellen. Een eenvoudige taak kan dus ook onder Intelligence bij een kleiner model uitkomen. Je test daarom twee zaken apart: welke tiervoorkeur je meegaf en welke modelroute en uitkomst je werkelijk zag.

De actuele GitHub-documentatie meldt dat Auto met task optimization algemeen beschikbaar is in Copilot Chat op GitHub.com, VS Code, Copilot CLI, de GitHub Copilot-app en JetBrains. De drie tiers zijn alleen beschikbaar in VS Code, CLI en de Copilot-app. Copilot cloud agent heeft ook Auto, maar geen van de drie tierkeuzes. Beschikbare modellen blijven afhankelijk van plan en beheerbeleid; noteer dus welke client en tier je werkelijk test.

Welke taken horen in je evalset?

Gebruik kleine, terugkerende codetaken waarvoor je een objectieve controle kunt maken. Een compacte set kan bestaan uit een documentatiewijziging, een bugfix met regressiontest en een taak met een duidelijke scopegrens.

De tabel beschrijft een testplan, geen meting. Bewaar per case een vaste case-ID, verwachte uitkomst, acceptatiecriteria en startcommit. Gebruik synthetische code of een repository waarvoor jouw team testgebruik toestaat. Voeg geen klantcode, geheimen of persoonsgegevens toe als je dat niet hebt beoordeeld in intern beleid.

Stap 1: maak de vergelijking reproduceerbaar

Kies één client die de drie tiers aanbiedt, bijvoorbeeld VS Code, en noteer de extensie- en clientversie. Gebruik voor elke run dezelfde basiscommit, instructies, toolrechten en tests. Herstel de werkboom tussen runs zodat de tweede tier niet voortbouwt op code die de eerste al heeft aangepast.

Voer taken één voor één uit. Wissel de volgorde van tiers af tussen herhalingen om tijdstip, servicebelasting en modelbeschikbaarheid minder snel met één tier te verwarren. Laat een reviewer de diffs beoordelen zonder te vertellen welke tier de code maakte als dat praktisch is.

Definieer vooraf wat geslaagd betekent. Bijvoorbeeld: alle vaste tests slagen, geen ongewenste bestanden veranderen, de wijziging voldoet aan de taak en een reviewer accepteert de diff. Als een taak onduidelijk is, verbeter eerst de casebeschrijving in plaats van achteraf de rubric voor één resultaat aan te passen.

Stap 2: meet modelroute, uitkomst en responstijd

GitHub laat in ondersteunde clients zien welk model een antwoord gebruikte: in Copilot Chat en de Copilot-app kun je de modelnaam bij het antwoord bekijken; in de CLI verschijnt die in de terminal. Leg de getoonde naam per run vast. Noem hem niet vooraf, want Auto kiest op basis van taak en actuele beschikbaarheid.

Bewaar per taak bijvoorbeeld deze CSV-kolommen:

case_id,tier,run,selected_model,accepted,tests_passed,latency_ms,usage_units
DOC-01,efficiency,1,actual-model-label,yes,yes,12500,reported-unit-or-blank

De regel is een formaatvoorbeeld, geen echte meting. Vervang model, tijd en verbruiksmaat alleen door wat jouw run en facturatie werkelijk rapporteren.

• Kwaliteit: leg testresultaat en reviewacceptatie afzonderlijk vast.
• Latency: meet van verzenden tot bruikbaar antwoord; gebruik dezelfde client en netwerkcondities.
• Modelroute: kopieer het model dat de client werkelijk meldt.
• Verbruik: gebruik een officiële billing- of usagebron op het granulariteitsniveau dat zij ondersteunt. Als je bron geen kosten per taak toewijst, noteer een usage-unit of aggregaat; verzin geen eurobedrag.

GitHub rekent Auto-gebruik af op basis van het gekozen model, ongeacht de tier. Alleen betaalde plannen krijgen de gedocumenteerde korting van 10% op modelkosten, en die geldt voor Copilot Chat, CLI, de Copilot-app en cloud agent. Controleer de actuele billingregels voor jouw plan en client; een tier is geen vast prijskaartje en Free-gebruik valt niet onder die korting.

Stap 3: vat de CSV samen zonder de rubric te verstoppen

Met dit voorbeeldscript bereken je per tier het aandeel geaccepteerde runs en de gemiddelde gemeten responstijd. Het leest alleen een bestand dat jij zelf hebt gevuld; er is geen output uitgevoerd of gemeten voor dit artikel.

$rows = Import-Csv -LiteralPath '.\copilot-auto-eval.csv'

$rows |
  Group-Object -Property tier |
  ForEach-Object {
    $accepted = @($_.Group | Where-Object { $_.accepted -eq 'yes' }).Count
    $total = $_.Count
    $latency = ($_.Group | Measure-Object -Property latency_ms -Average).Average

    [pscustomobject]@{
      tier = $_.Name
      accepted_runs = $accepted
      total_runs = $total
      acceptance_rate = [math]::Round($accepted / $total, 3)
      average_latency_ms = [math]::Round($latency, 0)
    }
  } |
  Format-Table -AutoSize

Controleer dat elke case even vaak in iedere tier voorkomt, latency_ms numeriek is en accepted alleen yes/no bevat. Rapporteer aantallen naast percentages. Bij een kleine set kan één afwijkende taak het beeld veranderen; presenteer uitkomsten als resultaten van deze evalset, niet als productwaarheid.

Welke foutmodus maakt de vergelijking misleidend?

Een veelvoorkomende fout is alleen de snelste of meest geaccepteerde run vergelijken. Dan verdwijnen mislukte tests, onbruikbare diffs en gekozen modelroutes uit beeld. Een andere fout is elke opdracht één keer uitvoeren: modelbeschikbaarheid, promptvariantie en tijdelijke belasting kunnen het resultaat beïnvloeden.

Leg ook vast wanneer de modelcatalogus, clientversie of policy veranderde. Beschikbare modellen hangen volgens GitHub af van plan en beheerbeleid, waaronder toegangs-, dataresidentie- en evaluatiemodelinstellingen. Een wijziging daarin maakt vergelijking met vorige week minder rechtstreeks.

Wanneer gebruik je Auto en wanneer kies je zelf een model?

Gebruik Auto wanneer je de selectie per taak wilt laten meebewegen en je team de route achteraf kan controleren. Kies een vast model wanneer een taak een expliciete, herhaalbare modelkeuze vereist of wanneer beleid Auto uitsluit. Behoud in beide gevallen dezelfde tests en reviewregels; alleen de modelpicker maakt code niet correct.

Begin bij teamuitrol met een beperkte groep en representatieve taken. Stel op basis van de evalset vast welke trade-offs acceptabel zijn en herhaal de meting na relevante model-, plan- of policywijzigingen. Stop de uitrol als tests of reviewregels achteruitgaan, ook wanneer latency of kosten verbeteren.

Lees voor de algemene methode hoe je een AI-agent met een minimale evalset test en voor herhaalbare instructies hoe je AI coding agent skills reviewbaar maakt. Voor hulp bij teamintegratie vind je de route naar AI-engineering voor organisaties.

Besliskader

Beeldbrief: 16:9-diagram met dezelfde synthetische taken door Efficiency, Balance en Intelligence; meetpunten voor testuitkomst, werkelijk model, latency en usage-bron.
Alt-tekst: Drie Copilot Auto-tiers vergelijken dezelfde codeertaken op tests, gekozen model, responstijd en gerapporteerd verbruik.