El 15 de juny Anthropic comença a comptar el consum d'agents Claude separat del consum de chat humà. Cada usuari tindrà dos comptadors mensuals mirall, no un. Si el teu equip dispara agents Claude Code en CI/CD, en background workers o en pipelines de revisió de codi, no monitoritzar aquest segon comptador pot multiplicar la factura per 3-5× durant les primeres setmanes.
Aquests són els 6 canvis concrets al teu setup que han d'estar live abans del switch, no després. Fa uns dies vam publicar un altre insight enfocat al CFO amb els controls FinOps del mateix switch. Aquest cobreix l'altra meitat — la tècnica.
Per què el switch canvia la mecànica de cost
Fins al 14-juny, el comptador unificat de Claude Code et donava una il·lusió còmoda: una única línia a la factura, una única alerta, un únic humà (normalment el CFO) revisant l'agregat mensual. El consum d'un developer xatejant amb Claude i el consum d'un agent Claude resolent un job en CI sumaven contra el mateix pressupost.
Això amagava un patró important. Un developer xatejant amb Claude consumeix entre 50 i 200 mil tokens en una sessió típica de 2-3 hores. Un agent Claude Code llançat contra un repo gran amb un workflow multi-step pot consumir 1-3 milions de tokens en un únic job — i els workflows típics no són únics, són recurrents. Si el teu equip té 10 developers en plantilla + 4-6 jobs agèntics diaris, el ràtio agent/chat en tokens ja és de ≈4:1, no 1:1.
Amb el comptador unificat, aquest ràtio quedava enterrat sota una mitjana confortable. Amb dos comptadors mirall, el bucket "agent" es buidarà dues o tres vegades més ràpid que el bucket "chat" — i serà visible per a tot el comitè. Sense governança tècnica abans del 15-juny, arribes al 16-juny amb tres alertes per hora durant la primera setmana.
Els equips que ja disciplinen el seu ús d'agents amb Spec-Driven Development recuperen en velocitat el que el switch afegeix en vigilància FinOps: als programes onext AI-Accelerated Development mesurem ×7 velocitat de desenvolupament, 0 sprints perduts i −50% time-to-production sobre equips de 10-100 developers amb la metodologia. SDD no és FinOps disfressat, però és el que fa que el FinOps no et freni.
Canvi 1 · Separar el budget d'agent i el budget de chat al teu CLAUDE.md
CLAUDE.md és el fitxer que Claude Code llegeix com a context organitzatiu abans de cada job. Fins avui probablement només té convencions de codi i arquitectura. A partir del 15-juny necessita una secció dedicada a pressupost.
Estructura mínima: tres blocs explícits.
- Un budget mensual de chat en tokens per developer (quants tokens pot gastar cada membre de l'equip en sessions interactives).
- Un budget mensual d'agent en tokens per workflow (quant pot consumir cada pipeline agèntic recurrent, distingint per nom).
- Un punt de ruptura (llindar en tokens/hora) per damunt del qual l'agent ha de parar i esperar revisió humana.
El que es guanya: l'equip no descobreix el problema quan arriba la factura, el descobreix quan l'agent para tot sol i obre un missatge a Slack.
Canvi 2 · Afegir rate limits explícits per workflow agèntic en CI
Un agent llançat des de GitHub Actions o equivalent no té noció de l'hora del dia ni de l'estat de la resta de l'organització. Sense rate limits, un canvi innocent en un workflow (per exemple, executar l'agent a cada push en lloc de a cada PR) pot multiplicar el consum per 20× en un cap de setmana.
La recomanació pràctica: per a cada workflow agèntic definit en CI, declarar explícitament un màxim de jobs concurrents i un màxim de jobs per hora. Sense aquest límit, un merge descuidat a les 19:00 del divendres pot disparar desenes de jobs en paral·lel — i no ho veuràs fins al dissabte al matí quan arribin les alertes de cost.
El que es guanya: sostre concret, predictible, auditable. L'estimació més simple per començar: N jobs per hora ≤ el teu budget horari en tokens / consum mitjà per job × 0,7 (factor de seguretat per a variacions). Si encara no tens ni un sol job mètric mesurat, mesura tres jobs típics aquesta setmana abans de decidir el sostre.
Canvi 3 · Instrumentar OpenTelemetry traces per agent
Sense observabilitat per agent, debugar el cost és impossible. La factura et diu quant va consumir el bucket "agent" al mes; no et diu quin agent, quin prompt, quina eina, ni quan.
OpenTelemetry és l'estàndard obert que el teu equip ja fa servir per a microserveis. Per a Claude Code la integració mínima és: cada crida a l'agent queda com un span, amb atributs agent.name, agent.workflow, tokens.input, tokens.output i tools.invoked. Si l'agent crida un altre agent o invoca una tool externa, queda com a child span dins del trace pare.
El que es guanya: quan el bucket "agent" salta el 17 de juny a les 11:42, obres el dashboard, filtres per l'última hora i veus exactament quin workflow i quin prompt està consumint 3 vegades més del previst. Sense això, el switch del 15-juny converteix qualsevol overrun en una caça de fantasmes que dura dies.
Canvi 4 · Regles de no-loop a les specs SDD
És el canvi més barat d'aplicar i el de més impacte en cost. Una spec SDD ben escrita evita que l'agent caigui en un loop recursiu (es crida a si mateix, crida un altre agent que el crida de tornada, intenta resoldre el problema amb 5 iteracions quan amb 1 n'hi havia prou). Una spec mal escrita o absent converteix cada job agèntic en una loteria de tokens.
La regla operativa: a la spec, declarar sempre el nombre màxim de turns que l'agent pot fer servir per resoldre el problema, i declarar quines eines no pot invocar (o, de manera equivalent, declarar explícitament només les que pot). Sense aquesta frontera, l'agent Claude Code tendeix a explorar eines addicionals com a mecanisme d'"intentar alguna cosa més" — i cada exploració costa tokens.
Aquesta disciplina és la base del Spec-Driven Development que apliquem a cada programa onext AI-Accelerated Development. La diferència entre un equip amb SDD madur i un equip sense SDD post-15-juny és la diferència entre una factura previsible i una alerta d'overrun cada cinc dies.
Canvi 5 · Aprovació humana obligatòria per damunt d'un llindar tokens/hora
Els rate limits i les specs no-loop et donen sostres tous: l'agent s'autoregula. El que falta és un sostre dur: una intervenció humana obligatòria quan el consum per hora supera un llindar acordat per l'equip.
La recomanació: per a cada bucket agèntic (un per workflow recurrent), establir un llindar en tokens/hora. Quan es creua, l'agent para automàticament i s'obre un missatge a un canal de Slack dedicat amb l'últim prompt, l'últim trace i un botó d'"aprovar la següent hora" / "parar definitivament".
El que es guanya: el pitjor escenari passa de "factura disparada durant 5 hores fins que algú se n'adona a les 3 de la matinada" a "factura controlada durant 30 minuts fins que el Lead Dev decideix". És la diferència entre 500 € i 5.000 € en un cap de setmana mal governat.
Canvi 6 · Auditoria setmanal de tokens consumits per context vs per output
Poques organitzacions ho separen, i és el que més sorprèn a la primera revisió. A Claude Code (i a qualsevol agent modern) el cost dels tokens d'input —el context que s'introdueix a cada crida— és habitualment més gran que el cost dels tokens d'output.
Si el teu equip va aprendre Claude Code amb la metàfora del chat humà ("li pregunto, em respon"), tendeix a optimitzar l'output: respostes més curtes, menys iteracions. Però el veritable estalvi és al context: arxius sencers del repo que s'envien a cada job quan una secció bastaria, històrics de conversa que s'arrosseguen sessió rere sessió, eines amb descripcions excessivament llargues que es repliquen a cada crida.
Una auditoria setmanal de 30 minuts —revisar 5 traces, comparar tokens input vs output, identificar on s'està enviant context innecessari— sol retallar el consum agèntic entre un 15% i un 30% el primer mes. No és un canvi tècnic de codi, és una disciplina de revisió.
Què no cal fer
Hi ha tres reaccions temptadores al switch del 15-juny que convé descartar abans de prendre-les.
Bloquejar tot Claude Code "fins a entendre el canvi". És la decisió que sembla més prudent i és la pitjor. El teu equip retrocedeix a Copilot sense control o, pitjor, a programar sense agent — perds la ×7 velocitat de desenvolupament que sosté el teu roadmap i els equips tornen a hàbits que van trigar mesos a abandonar.
Reescriure totes les specs a l'últim minut. El switch del 15-juny és de pricing, no de funcionalitat. Les specs que tens avui segueixen sent vàlides el 16-juny. Si arribes al 14-juny amb una refactorització massiva en curs, el risc de regressió multiplica el problema FinOps que intentaves evitar.
Migrar a un model open-source "per si de cas". L'ecosistema enterprise està convergint cap a Anthropic (Wall Street JV de maig, EPAM 10k arquitectes certificats, PwC 30k, SAP-Anthropic — tot en els últims 60 dies). Migrar contra aquest vector perquè t'espanta una factura és la decisió correcta per al dia 30, no per al dia 60.
El teu següent pas
Els 6 canvis anteriors són el teu mínim viable abans del 15-juny. Si vols comprovar si el teu equip ja té la disciplina tècnica que el switch exigirà, el checklist SDD per al teu equip recull 16 preguntes de diagnòstic — reps el resultat per email en menys de 10 minuts.
Si després de fer el checklist vols una conversa de 30 minuts amb onext sobre com apliquem això amb equips de 100-1.000 empleats, escriu a info@onext.es. El programa onext AI-Accelerated Development és on muntem els 6 canvis anteriors com a part del setup, no com a pedaç post-overrun.
Preguntes freqüents
Què canvia exactament el 15 de juny en la facturació de Claude Code?
Anthropic separa el comptador de consum d'agents del comptador de consum de chat humà. Cada usuari tindrà dos buckets mensuals mirall en lloc d'un. El preu unitari per token no canvia; el que canvia és la visibilitat i l'assignació del consum. Abans del 15-juny, un agent en CI i un developer en sessió consumien contra el mateix pressupost; a partir del 15-juny, contra dos pressupostos independents.
El meu equip ha d'aprovar els canvis a nivell de CTO o n'hi ha prou amb el Lead Dev?
Els 4 primers canvis tècnics (CLAUDE.md, rate limits, OpenTelemetry, specs SDD) els pot coordinar el Lead Dev sense intervenció del CTO si ja hi ha disciplina SDD instal·lada. Els 2 últims (llindar d'aprovació humana i auditoria setmanal) toquen pressupost i procés organitzatiu — necessiten validació del CTO perquè defineixen què es considera "anormal" i qui interromp qui. Aprovar el llindar monetari sense el CTO és el que produeix els conflictes a les 3 de la matinada.
El canvi d'Anthropic afecta també Claude usat via API directa, o només Claude Code?
El split de comptadors s'aplica al producte Claude Code (l'agent) i al producte Claude.ai (el chat). Si el teu equip invoca l'API directament des de codi propi sense usar Claude Code, la facturació de l'API directa segueix la seva lògica habitual — però convé revisar si allò que anomenes "API directa" no és de facto un workflow agèntic embegut, cas en què el split t'afecta igualment de facto.
Quant s'estima que puja la factura mitjana d'un equip de 10 developers post-switch?
No puja pel switch en si — el preu unitari per token no canvia. El que sí que canvia és que els overruns per mal control agèntic ara són visibles i atribuïbles. A la pràctica, els equips sense governança tècnica veuen increments del 30-80% el primer mes post-switch abans d'aplicar els 6 canvis, i tornen al baseline o per sota el segon mes.
Convé esperar al 15-juny per començar Spec-Driven Development o avançar-lo?
Avançar-lo. SDD redueix el consum agèntic abans del switch (menys iteracions, menys context innecessari, menys loops) i redueix la pressió organitzativa després (menys overruns, menys alertes, menys discussions amb el CFO). Començar SDD el 14-juny et dona gairebé tot l'upside; començar-lo el 16-juny te'l dona amb un mes de retard i sota pressió d'incident reports.
