Fins fa poc, el cost dels agents de codi en un equip de desenvolupament era un compte senzill: tantes llicències per tantes persones. Des de l'1 de juny de 2026, tots els plans de GitHub Copilot es facturen per ús, i l'ús de Claude Code es mesura i es cobra en tokens. La llicència continua existint, però ja no és tot el cost.
La idea que defensa aquest insight: amb el pagament per ús, una part de la despesa en agents ja no la fixa el contracte sinó la manera de treballar de l'equip. Una tasca mal definida es paga dues vegades, en tokens mentre l'agent explora i en retreball quan l'encerta a la segona. Per això l'especificació també és una eina de pressupost.
Què ha canviat a la factura
GitHub va anunciar el canvi el 27 d'abril de 2026 i ho va explicar sense embuts: amb el model anterior, «a quick chat question and a multi-hour autonomous coding session» podien costar el mateix, i aquell model era «no longer sustainable». Des del juny, l'ús es calcula per tokens d'entrada, de sortida i en memòria cau. Cada llicència de Copilot Business inclou 19 $ al mes en crèdits i cada una d'Enterprise, 39 $; el que no es gasta es reparteix a tota l'empresa, i el que passa d'aquí es paga a part o es talla.
El 28 d'octubre, a GitHub Universe, es va fer un pas més: els clients de GitHub Enterprise poden fer servir totes les funcions de Copilot sense comprar una subscripció a part. En paraules de GitHub: «You pay for the AI credits you use».
Límit Són xifres dels mateixos fabricants, consultades el 30 d'octubre de 2026, i els preus canvien sovint. Les de Claude Code són mitjanes de molts equips: la documentació avisa que el cost per persona varia molt segons el model, la mida del codi i la manera de treballar. No és una comparativa d'eines ni un pressupost.
I l'ús creixerà. Anthropic va publicar el 16 d'octubre com ha canviat la feina a la seva pròpia empresa: a l'agost, les hores dels seus agents en sessions dirigides per empleats ja multiplicaven per sis les hores de les persones. És una sola empresa, que a més fabrica el model, així que no es pot extrapolar. Però assenyala cap a on va la part variable de la factura.
El que no està especificat es paga dues vegades
La documentació de costos de Claude Code és útil precisament perquè no parla de preus, sinó d'hàbits. Diu això: «Vague requests like "improve this codebase" trigger broad scanning». Una petició concreta, com afegir una validació a una funció d'un fitxer concret, deixa l'agent treballar llegint poc. Cada fitxer que l'agent llegeix per entendre què se li demana són tokens.
El segon pagament és el retreball. La mateixa documentació recomana planificar abans d'implementar en les tasques complexes, per evitar un «expensive re-work» si la direcció inicial és dolenta, i donar a l'agent objectius de verificació (casos de prova, el resultat esperat) perquè comprovi la seva feina abans que algú li hagi de demanar la correcció.
Si es llegeix amb atenció, això és una especificació: què s'ha de canviar, on, i com se sabrà que està bé. És el que li falta a una tasca escrita per a persones, com expliquem a una issue no és una especificació per a un agent de codi, i el que converteix els criteris d'acceptació en una cosa que es pot comprovar, com a la teva spec ja és un eval. L'Spec-Driven Development (SDD), el desenvolupament guiat per especificacions, no va néixer per estalviar tokens. Però amb el pagament per ús, també ajuda a no gastar tokens de més.
| Llicència per persona | Pagament per ús | |
|---|---|---|
| Què es paga | Un import fix per persona i mes | Els tokens que consumeix cada tasca, per sobre del que hi ha inclòs |
| Què el fa pujar | Contractar més persones | Tasques llargues, encàrrecs imprecisos, context que l'agent ha de reconstruir, refer feina |
| Qui el controla | Compres, un cop l'any | L'equip, cada dia, amb la manera d'encarregar la feina; i qui fixa els límits de despesa |
| Què es pressuposta | Llicències | Feina lliurada, amb un límit |
Elaboració d'onext a partir de l'anunci de GitHub (2026-04-27) i de la documentació de costos de Claude Code (consultada el 2026-10-30)
Què canvia a la pràctica
Res d'això demana una eina nova. Demana decidir quatre coses abans que arribi la primera factura variable:
- Comença amb un equip pilot i pren una línia base. És la recomanació literal de la documentació de Claude Code: «start with a small pilot group» per tenir una referència abans d'estendre-ho a tothom. Mesura la despesa i, alhora, el lliurament: què mesurar és a KPI per a equips de desenvolupament amb IA.
- Posa els límits de despesa abans de la primera factura. GitHub permet pressupostos per empresa, per centre de cost i per usuari. Als plans d'equip i d'empresa de Claude, amb els crèdits d'ús activats, hi ha límits per organització, per grup i per persona. Decidir el límit després d'una sorpresa és més car que decidir-lo abans.
- Pressuposta per feina lliurada, no per llicència. La pregunta útil no és quant costa cada lloc, sinó quant costa cada canvi que arriba a producció i amb quina qualitat. És la mateixa lògica de la tesi de valor que convé demanar a un equip de desenvolupament.
- Encarrega la feina especificada. Què es canvia, on, amb quins criteris d'acceptació i com es comprova. És preparar la feina de l'agent, que és la part de la feina de les persones que més creix, com expliquem a preparar, revisar i decidir.
El preu per token el posa el proveïdor. Quants tokens calen per a cada tasca depèn, en bona part, de com l'encarrega el teu equip.
El que aquest insight no diu
No diu que els agents de codi siguin cars ni promet cap estalvi: no hi ha cap dada general que digui si un equip gasta més o menys amb ells, i les mitjanes d'un fabricant no serveixen com a pressupost de ningú. Tampoc no compara eines ni preus. I no cal esperar que el primer mes sigui el millor: DORA dedica una part de la seva feina sobre el retorn de la IA a gestionar «the initial "productivity dip" of a new rollout», el sotrac del principi de qualsevol desplegament.
El que sí que diu és que la part variable existeix, que creix i que es pot governar amb coses que l'equip ja controla. Dins d'un producte passa una cosa semblant: el que té regles clares no se li pregunta al model, com expliquem a quant del teu agent hauria de ser codi.
Per on continuar
Si vols veure com treballa el teu equip amb els agents abans que la factura t'ho digui, el diagnòstic és gratuït. Abans, pots llegir com instal·lem el mètode a AI-Accelerated Development.
Preguntes freqüents
Quant costa un agent de codi per desenvolupador?
Depèn del model, de la mida del codi i de com treballa cada persona. Com a referència, la documentació de Claude Code (consultada el 30 d'octubre de 2026) dona una mitjana d'uns 13 $ per desenvolupador i dia actiu en desplegaments d'empresa, entre 150 i 250 $ al mes, i per sota de 30 $ per dia actiu per al 90 % dels usuaris. És una mitjana del fabricant, no un pressupost: els preus canvien sovint.
Des de quan es paga GitHub Copilot per ús?
Des de l'1 de juny de 2026, tots els plans de Copilot es facturen per ús, amb crèdits calculats a partir dels tokens consumits. Les llicències de Business i Enterprise inclouen 19 $ i 39 $ al mes en crèdits per usuari. A més, des del 28 d'octubre de 2026 els clients de GitHub Enterprise poden fer servir totes les funcions de Copilot sense una subscripció a part i paguen els crèdits que fan servir (de moment, a través de l'equip comercial de GitHub).
Per què una tasca mal definida costa més?
Perquè l'agent ha d'explorar més per entendre què se li demana, i cada fitxer que llegeix són tokens. La documentació de Claude Code ho diu així: les peticions imprecises com «millora aquest codi» provoquen una exploració àmplia, i les concretes el deixen treballar amb poques lectures. Si a més la direcció inicial és dolenta, es paga el retreball.
Com poso un límit de despesa als agents del meu equip?
Els mateixos proveïdors ho permeten. A GitHub Copilot es fixen pressupostos per empresa, per centre de cost i per usuari. Als plans d'equip i d'empresa de Claude, si s'activen els crèdits d'ús, es posen límits per organització, per grup o per persona; amb l'API, límits per espai de treball. Convé posar-los abans de la primera factura, no després.
Com pressuposto el que gasta el meu equip en agents?
Comença per un equip pilot i pren una línia base abans d'estendre-ho, com recomana la mateixa documentació de Claude Code. Després, mira la despesa al costat del que l'equip lliura: quant costa cada canvi que arriba a producció, no quant costa cada llicència.
Fer servir agents de codi surt més car que no fer-los servir?
Aquest insight no ho diu i no hi ha cap dada general que ho respongui. El que sí que diu és que, amb el pagament per ús, una part del cost depèn de com encarrega la feina el teu equip, i que aquesta part es pot mesurar i governar.
Fonts
- GitHub, «GitHub Copilot is moving to usage-based billing», GitHub Changelog, 27 d'abril de 2026.
- Jay Parikh, «GitHub Universe 2026: Evolving every layer of the stack», GitHub Blog, 28 d'octubre de 2026.
- Anthropic, «Manage costs effectively», documentació de Claude Code (sense data; consultada el 30 d'octubre de 2026).
- Nathan Wilmers, Regina Catipon, Maxim Massenkoff i Peter McCrory, «How employment is changing at Anthropic», Anthropic, 16 d'octubre de 2026.
- DORA, «ROI of AI-assisted Software Development», actualitzat el 22 d'abril de 2026.
Bernat López és fundador i CEO d'onext, boutique d'IA. Acompanya equips de desenvolupament i de producte a treballar amb IA amb mètode —especificació abans de programar, una persona que decideix on hi ha risc i Spec-Driven Development— i aplica a la seva pròpia empresa el que proposa: onext funciona amb el seu propi sistema agèntic.
LinkedIn →