Hasta hace poco, el coste de los agentes de código en un equipo de desarrollo era una cuenta sencilla: tantas licencias por tantas personas. Desde el 1 de junio de 2026, todos los planes de GitHub Copilot se facturan por uso, y el uso de Claude Code se mide y se cobra en tokens. La licencia sigue ahí, pero ya no es todo el coste.
La idea que defiende este insight: con el pago por uso, una parte del gasto en agentes ya no la fija el contrato sino la forma de trabajar del equipo. Una tarea mal definida se paga dos veces, en tokens mientras el agente explora y en retrabajo cuando acierta a la segunda. Por eso la especificación también es una herramienta de presupuesto.
Qué ha cambiado en la factura
GitHub anunció el cambio el 27 de abril de 2026 y lo explicó sin rodeos: con el modelo anterior, «a quick chat question and a multi-hour autonomous coding session» podían costar lo mismo, y ese modelo era «no longer sustainable». Desde junio, el uso se calcula por tokens de entrada, de salida y en caché. Cada licencia de Copilot Business incluye 19 $ al mes en créditos y cada una de Enterprise, 39 $; lo que no se gasta se reparte en toda la empresa, y lo que pasa de ahí se paga aparte o se corta.
El 28 de octubre, en GitHub Universe, se dio un paso más: los clientes de GitHub Enterprise pueden usar todas las funciones de Copilot sin comprar una suscripción aparte. En palabras de GitHub: «You pay for the AI credits you use».
Límite Son cifras de los propios fabricantes, consultadas el 30 de octubre de 2026, y los precios cambian a menudo. Las de Claude Code son medias de muchos equipos: la documentación avisa de que el coste por persona varía mucho según el modelo, el tamaño del código y la forma de trabajar. No es una comparativa de herramientas ni un presupuesto.
Y el uso va a crecer. Anthropic publicó el 16 de octubre cómo ha cambiado el trabajo en su propia empresa: en agosto, las horas de sus agentes en sesiones dirigidas por empleados ya multiplicaban por seis las horas de las personas. Es una sola empresa, que además fabrica el modelo, así que no se puede extrapolar. Pero señala hacia dónde va la parte variable de la factura.
Lo que no está especificado se paga dos veces
La documentación de costes de Claude Code es útil precisamente porque no habla de precios, sino de hábitos. Dice esto: «Vague requests like "improve this codebase" trigger broad scanning». Una petición concreta, como añadir una validación a una función de un archivo concreto, deja al agente trabajar leyendo poco. Cada archivo que el agente lee para entender qué se le pide son tokens.
El segundo pago es el retrabajo. La misma documentación recomienda planificar antes de implementar en las tareas complejas, para evitar un «expensive re-work» si la dirección inicial es mala, y dar al agente objetivos de verificación (casos de prueba, el resultado esperado) para que compruebe su trabajo antes de que alguien tenga que pedirle la corrección.
Si se lee con atención, eso es una especificación: qué hay que cambiar, dónde, y cómo se sabrá que está bien. Es lo que le falta a una tarea escrita para personas, como contamos en una issue no es una especificación para un agente de código, y lo que convierte los criterios de aceptación en algo que se puede comprobar, como en tu spec ya es un eval. El Spec-Driven Development (SDD), el desarrollo guiado por especificaciones, no nació para ahorrar tokens. Pero con el pago por uso, también ayuda a no gastar tokens de más.
| Licencia por persona | Pago por uso | |
|---|---|---|
| Qué se paga | Un importe fijo por persona y mes | Los tokens que consume cada tarea, por encima de lo incluido |
| Qué lo hace subir | Contratar más personas | Tareas largas, encargos vagos, contexto que el agente tiene que reconstruir, rehacer trabajo |
| Quién lo controla | Compras, una vez al año | El equipo, cada día, con la forma de encargar el trabajo; y quien fija los límites de gasto |
| Qué se presupuesta | Licencias | Trabajo entregado, con un límite |
Elaboración de onext a partir del anuncio de GitHub (2026-04-27) y de la documentación de costes de Claude Code (consultada el 2026-10-30)
Qué cambia en la práctica
Nada de esto pide una herramienta nueva. Pide decidir cuatro cosas antes de que llegue la primera factura variable:
- Empieza con un equipo piloto y toma una línea base. Es la recomendación literal de la documentación de Claude Code: «start with a small pilot group» para tener una referencia antes de extenderlo a todos. Mide el gasto y, a la vez, la entrega: qué medir está en KPIs para equipos de desarrollo con IA.
- Pon los límites de gasto antes de la primera factura. GitHub permite presupuestos por empresa, por centro de coste y por usuario. En los planes de equipo y empresa de Claude, con los créditos de uso activados, hay límites por organización, por grupo y por persona. Decidir el límite después de una sorpresa es más caro que decidirlo antes.
- Presupuesta por trabajo entregado, no por licencia. La pregunta útil no es cuánto cuesta cada puesto, sino cuánto cuesta cada cambio que llega a producción y con qué calidad. Es la misma lógica de la tesis de valor que conviene pedirle a un equipo de desarrollo.
- Encarga el trabajo especificado. Qué se cambia, dónde, con qué criterios de aceptación y cómo se comprueba. Es preparar el trabajo del agente, que es la parte del trabajo de las personas que más crece, como contamos en preparar, revisar y decidir.
El precio por token lo pone el proveedor. Cuántos tokens hacen falta para cada tarea depende, en buena parte, de cómo la encarga tu equipo.
Lo que este insight no dice
No dice que los agentes de código sean caros ni promete un ahorro: no hay un dato general que diga si un equipo gasta más o menos con ellos, y las medias de un fabricante no sirven como presupuesto de nadie. Tampoco compara herramientas ni precios. Y no hay que esperar que el primer mes sea el mejor: DORA dedica una parte de su trabajo sobre el retorno de la IA a gestionar «the initial "productivity dip" of a new rollout», el bache del principio de cualquier despliegue.
Lo que sí dice es que la parte variable existe, que crece y que se puede gobernar con cosas que el equipo ya controla. Dentro de un producto pasa algo parecido: lo que tiene reglas claras no se le pregunta al modelo, como contamos en cuánto de tu agente debería ser código.
Por dónde seguir
Si quieres ver cómo trabaja tu equipo con los agentes antes de que la factura lo diga por ti, el diagnóstico es gratuito. Antes, puedes ver en qué punto estás con el autodiagnóstico de SDD o leer cómo instalamos el método en AI-Accelerated Development.
Preguntas frecuentes
¿Cuánto cuesta un agente de código por desarrollador?
Depende del modelo, del tamaño del código y de cómo trabaja cada persona. Como referencia, la documentación de Claude Code (consultada el 30 de octubre de 2026) da una media de unos 13 $ por desarrollador y día activo en despliegues de empresa, entre 150 y 250 $ al mes, y por debajo de 30 $ por día activo para el 90 % de los usuarios. Es una media del fabricante, no un presupuesto: los precios cambian a menudo.
¿Desde cuándo se paga GitHub Copilot por uso?
Desde el 1 de junio de 2026, todos los planes de Copilot se facturan por uso, con créditos calculados a partir de los tokens consumidos. Las licencias de Business y Enterprise incluyen 19 $ y 39 $ al mes en créditos por usuario. Además, desde el 28 de octubre de 2026 los clientes de GitHub Enterprise pueden usar todas las funciones de Copilot sin una suscripción aparte y pagan los créditos que usan (de momento, a través del equipo comercial de GitHub).
¿Por qué una tarea mal definida cuesta más?
Porque el agente tiene que explorar más para entender qué se le pide, y cada archivo que lee son tokens. La documentación de Claude Code lo dice así: las peticiones vagas como «mejora este código» provocan una exploración amplia, y las concretas le dejan trabajar con pocas lecturas. Si además la dirección inicial es mala, se paga el retrabajo.
¿Cómo pongo un límite de gasto a los agentes de mi equipo?
Los propios proveedores lo permiten. En GitHub Copilot se fijan presupuestos por empresa, por centro de coste y por usuario. En los planes de equipo y empresa de Claude, si se activan los créditos de uso, se ponen límites por organización, por grupo o por persona; con la API, límites por espacio de trabajo. Conviene ponerlos antes de la primera factura, no después.
¿Cómo presupuesto lo que gasta mi equipo en agentes?
Empieza por un equipo piloto y toma una línea base antes de extenderlo, como recomienda la propia documentación de Claude Code. Después, mira el gasto junto a lo que el equipo entrega: cuánto cuesta cada cambio que llega a producción, no cuánto cuesta cada licencia.
¿Usar agentes de código sale más caro que no usarlos?
Este insight no lo dice y no hay un dato general que lo responda. Lo que sí dice es que, con el pago por uso, una parte del coste depende de cómo encarga el trabajo tu equipo, y que esa parte se puede medir y gobernar.
Fuentes
- GitHub, «GitHub Copilot is moving to usage-based billing», GitHub Changelog, 27 de abril de 2026.
- Jay Parikh, «GitHub Universe 2026: Evolving every layer of the stack», GitHub Blog, 28 de octubre de 2026.
- Anthropic, «Manage costs effectively», documentación de Claude Code (sin fecha; consultada el 30 de octubre de 2026).
- Nathan Wilmers, Regina Catipon, Maxim Massenkoff y Peter McCrory, «How employment is changing at Anthropic», Anthropic, 16 de octubre de 2026.
- DORA, «ROI of AI-assisted Software Development», actualizado el 22 de abril de 2026.
Bernat López es fundador y CEO de onext, boutique de IA. Acompaña a equipos de desarrollo y de producto a trabajar con IA con método —especificación antes de programar, una persona que decide donde hay riesgo y Spec-Driven Development— y aplica a su propia empresa lo que propone: onext funciona con su propio sistema agéntico.
LinkedIn →