Het antwoord is dat GitHub Copilot overstapt van een vast aantal verzoeken per maand naar een model waarbij je betaalt voor het daadwerkelijke AI-gebruik. Dit kan leiden tot onverwachte kostenpieken, vooral voor teams die intensief gebruikmaken van de AI-assistent. Het is nu zaak om je gebruik te monitoren en te optimaliseren om te voorkomen dat je maandelijkse rekening opeens verdubbelt of verdrievoudigt.

Wat er aan de hand is

GitHub heeft in april aangekondigd dat het de prijsstructuur van Copilot wijzigt. Waar je voorheen een vast aantal ‘verzoeken’ en ‘premium verzoeken’ kreeg op basis van je abonnementsniveau, betaal je nu op basis van daadwerkelijk verbruik. Dit nieuwe model gaat vandaag in. Volgens Ars Technica melden gebruikers op sociale media en forums dat hun ’normale’ gebruik nu een groot deel van hun maandelijkse tegoed aan AI-credits opsoupeert. Sommige gebruikers zagen dat hun maandelijkse quotum in minder dan een dag op was. GitHub zelf gaf aan dat het oude systeem oneerlijk was omdat ’een snelle chatvraag en een meerdaagse autonome coderingssessie de gebruiker hetzelfde kostten’, waardoor Copilot een groot deel van de stijgende inferentiekosten moest absorberen. Gebruikers delen schattingen van GitHub’s eigen tool die laten zien dat hun eerdere maandelijkse gebruik onder het nieuwe plan duizenden dollars zou kosten.

Wat dit betekent

Voor MKB-ontwikkelteams betekent deze verandering dat de voorspelbaarheid van de maandelijkse kosten verdwijnt. Waar je voorheen een vast bedrag betaalde, kun je nu ineens geconfronteerd worden met een rekening die veel hoger uitvalt dan verwacht. Dit is vooral riskant voor teams die Copilot intensief gebruiken voor taken als het genereren van hele codeblokken, het refactoren van grote bestanden of het uitvoeren van autonome coderingssessies. De impact is het grootst voor bedrijven die geen zicht hebben op hoeveel AI-credits hun ontwikkelaars dagelijks verbruiken. Een team van vijf ontwikkelaars dat voorheen ’normaal’ gebruikte, kan nu ineens voor een paar honderd tot duizenden euro’s extra kosten zien, afhankelijk van de complexiteit van het werk.

Hoe je dit kunt toepassen

Als je een klein ontwikkelteam van twee tot vijf personen runt, is het verstandig om direct een dashboard in te richten waarmee je het dagelijkse AI-creditsverbruik per ontwikkelaar kunt volgen. GitHub biedt zelf tools om je gebruik te monitoren. Je zou kunnen afspreken dat elk teamlid aan het einde van de dag een korte notitie maakt van hoeveel credits hij of zij heeft verbruikt. Zo krijg je snel inzicht in wie de grootste verbruikers zijn en welke taken de meeste credits kosten. Overweeg om een wekelijkse check-in van vijf minuten in te plannen om de cijfers te bespreken en eventueel bij te sturen.

Als je een team aanstuurt dat veel repetitieve code schrijft, zoals het genereren van boilerplate of het maken van standaard API-calls, dan kun je overwegen om deze taken te bundelen. In plaats van dat elke ontwikkelaar losse verzoeken doet, kun je een script schrijven dat in één sessie meerdere taken uitvoert. Dit vermindert het aantal ‘dure’ premium verzoeken. Een mogelijkheid is om een standaard ‘codegeneratie-sessie’ in te plannen aan het begin van de week, waarin het team gezamenlijk alle standaardcode genereert. Dit bespaart credits en zorgt voor consistentie.

Als je een freelancer bent die Copilot gebruikt voor projecten met een vast budget, is het belangrijk om je credits te budgetteren alsof het een aparte kostenpost is. Je zou kunnen beginnen met een proefweek waarin je je normale werk doet en noteert hoeveel credits je verbruikt. Op basis daarvan kun je een schatting maken van je maandelijkse kosten en deze meenemen in je uurtarief of projectprijs. Overweeg om een ‘AI-kostenbuffer’ van 10-15 procent in te bouwen in je offertes, zodat je niet voor verrassingen komt te staan.

Als je een CTO of tech lead bent die verantwoordelijk is voor de tech-stack, kun je overwegen om een interne ‘AI-credits policy’ op te stellen. Spreek af welke taken wel en niet met Copilot mogen worden gedaan. Bijvoorbeeld: het genereren van unittesten is toegestaan, maar het volledig automatisch herschrijven van een hele module niet, tenzij daar toestemming voor is. Je zou ook kunnen overwegen om een ‘credits-limiet’ per ontwikkelaar in te stellen, zodat niemand ongemerkt het hele teamquotum opmaakt. Dit klinkt misschien rigide, maar het voorkomt dat één persoon per ongeluk de maandelijkse kosten voor het hele team opdrijft.

Bron: Arstechnica