El 15 de junio Anthropic empieza a contar el consumo de agentes Claude separado del consumo de chat humano. Cada usuario tendrá dos contadores mensuales espejo, no uno. Si tu equipo dispara agentes Claude Code en CI/CD, en background workers o en pipelines de revisión de código, no monitorizar ese segundo contador puede multiplicar la factura por 3-5× durante las primeras semanas.
Estos son los 6 cambios concretos en tu setup que tienen que estar live antes del switch, no después. Hace unos días publicamos otro insight enfocado al CFO con los controles FinOps del mismo switch. Este cubre la otra mitad — la técnica.
Por qué el switch cambia la mecánica de coste
Hasta el 14-jun, el contador unificado de Claude Code te daba una ilusión cómoda: una única línea en la factura, una única alerta, un único humano (normalmente el CFO) revisando el agregado mensual. El consumo de un developer chateando con Claude y el consumo de un agente Claude resolviendo un job en CI sumaban contra el mismo presupuesto.
Eso ocultaba un patrón importante. Un developer chateando con Claude consume entre 50 y 200 mil tokens en una sesión típica de 2-3 horas. Un agente Claude Code lanzado contra un repo grande con un workflow multi-step puede consumir 1-3 millones de tokens en un único job — y los workflows típicos no son únicos, son recurrentes. Si tu equipo tiene 10 developers en plantilla + 4-6 jobs agénticos diarios, el ratio agente/chat en tokens es ya de ≈4:1, no 1:1.
Con el contador unificado, ese ratio quedaba enterrado bajo una media confortable. Con dos contadores espejo, el bucket "agent" se va a vaciar dos a tres veces más rápido que el bucket "chat" — y va a ser visible para todo el comité. Sin gobernanza técnica antes del 15-jun, llegas al 16-jun con tres alertas por hora durante la primera semana.
Los equipos que ya disciplinan su uso de agentes con Spec-Driven Development recuperan en velocidad lo que el switch añade en vigilancia FinOps: en los programas onext AI Engine medimos ×7 velocidad de desarrollo, 0 sprints perdidos y −50% time-to-production sobre equipos de 10-100 developers con la metodología. SDD no es FinOps disfrazado, pero es lo que hace que el FinOps no te frene.
Cambio 1 · Separar el budget de agent y el budget de chat en tu CLAUDE.md
CLAUDE.md es el fichero que Claude Code lee como contexto organizativo antes de cada job. Hasta hoy probablemente sólo tiene convenciones de código y arquitectura. A partir del 15-jun necesita una sección dedicada a presupuesto.
Estructura mínima: tres bloques explícitos.
- Un budget mensual de chat en tokens por developer (cuántos tokens puede gastar cada miembro del equipo en sesiones interactivas).
- Un budget mensual de agent en tokens por workflow (cuánto puede consumir cada pipeline agéntico recurrente, distinguiendo por nombre).
- Un punto de quiebra (umbral en tokens/hora) por encima del cual el agente debe parar y esperar revisión humana.
Lo que se gana: el equipo no descubre el problema cuando llega la factura, lo descubre cuando el agente para por sí solo y abre un mensaje en Slack.
Cambio 2 · Añadir rate limits explícitos por workflow agéntico en CI
Un agente lanzado desde GitHub Actions o equivalente no tiene noción de la hora del día ni del estado del resto de la organización. Sin rate limits, un cambio inocente en un workflow (por ejemplo, ejecutar el agente en cada push en lugar de en cada PR) puede multiplicar el consumo por 20× en un fin de semana.
La recomendación práctica: para cada workflow agéntico definido en CI, declarar explícitamente un máximo de jobs concurrentes y un máximo de jobs por hora. Sin ese límite, un merge descuidado a las 19:00 del viernes puede disparar decenas de jobs en paralelo — y no lo verás hasta el sábado por la mañana cuando lleguen las alertas de coste.
Lo que se gana: techo concreto, predecible, auditable. La estimación más simple para empezar: N jobs por hora ≤ tu budget horario en tokens / consumo medio por job × 0,7 (factor de seguridad para variaciones). Si todavía no tienes ni un solo job métrico medido, mide tres jobs típicos esta semana antes de decidir el techo.
Cambio 3 · Instrumentar OpenTelemetry traces por agente
Sin observabilidad por agente, debugar el coste es imposible. La factura te dice cuánto consumió el bucket "agent" en el mes; no te dice qué agente, qué prompt, qué herramienta, ni cuándo.
OpenTelemetry es el estándar abierto que ya usa tu equipo para microservicios. Para Claude Code la integración mínima es: cada llamada al agente queda como un span, con atributos agent.name, agent.workflow, tokens.input, tokens.output y tools.invoked. Si el agente llama otro agente o invoca una tool externa, queda como child span dentro del trace padre.
Lo que se gana: cuando el bucket "agent" salta el 17 de junio a las 11:42, abres el dashboard, filtras por la última hora y ves exactamente qué workflow y qué prompt está consumiendo 3 veces más de lo previsto. Sin esto, el switch del 15-jun convierte cualquier overrun en una caza de fantasmas que dura días.
Cambio 4 · Reglas de no-loop en specs SDD
Es el cambio más barato de aplicar y el de mayor impacto en coste. Una spec SDD bien escrita previene que el agente caiga en un loop recursivo (se llama a sí mismo, se llama a otro agente que lo llama de vuelta, intenta resolver el problema con 5 iteraciones cuando 1 bastaba). Una spec mal escrita o ausente convierte cada job agéntico en una lotería de tokens.
La regla operativa: en la spec, declarar siempre el número máximo de turns que el agente puede usar para resolver el problema, y declarar qué herramientas no puede invocar (o, de forma equivalente, declarar explícitamente sólo las que puede). Sin esa frontera, el agente Claude Code tiende a explorar herramientas adicionales como mecanismo de "intentar algo más" — y cada exploración cuesta tokens.
Esta disciplina es la base del Spec-Driven Development que aplicamos en cada programa onext AI Engine. La diferencia entre un equipo con SDD maduro y un equipo sin SDD post-15-jun es la diferencia entre una factura previsible y una alerta de overrun cada cinco días.
Cambio 5 · Aprobación humana obligatoria sobre umbral tokens/hora
Los rate limits y las specs no-loop te dan techos suaves: el agente se autorregula. Lo que falta es un techo duro: una intervención humana obligatoria cuando el consumo por hora supera un umbral acordado por el equipo.
La recomendación: por cada bucket agéntico (uno por workflow recurrente), establecer un umbral en tokens/hora. Cuando se cruza, el agente para automáticamente y se abre un mensaje a un canal Slack dedicado con el último prompt, el último trace y un botón de "aprobar siguiente hora" / "parar definitivamente".
Lo que se gana: el peor escenario pasa de "factura disparada durante 5 horas hasta que alguien lo nota a las 3 de la mañana" a "factura controlada durante 30 minutos hasta que el Lead Dev decide". Es la diferencia entre 500 € y 5.000 € en un fin de semana mal gobernado.
Cambio 6 · Auditoría semanal de tokens consumidos por contexto vs por output
Pocas organizaciones lo separan, y es lo que más sorpresa da en la primera revisión. En Claude Code (y en cualquier agente moderno) el coste de los tokens de input —el contexto que se mete en cada llamada— es habitualmente mayor que el coste de los tokens de output.
Si tu equipo aprendió Claude Code con la metáfora del chat humano ("le pregunto, me responde"), tiende a optimizar el output: respuestas más cortas, menos iteraciones. Pero el verdadero ahorro está en el contexto: archivos enteros del repo que se mandan en cada job cuando una sección bastaría, históricos de conversación que se acarrean sesión tras sesión, herramientas con descripciones excesivamente largas que se replican en cada llamada.
Una auditoría semanal de 30 minutos —revisar 5 traces, comparar tokens input vs output, identificar dónde se está mandando contexto innecesario— suele recortar el consumo agéntico entre 15% y 30% en el primer mes. No es un cambio técnico de código, es una disciplina de revisión.
Qué no hay que hacer
Hay tres reacciones tentadoras al switch del 15-jun que conviene descartar antes de tomarlas.
Bloquear todo Claude Code "hasta entender el cambio". Es la decisión que parece más prudente y es la peor. Tu equipo retrocede a Copilot sin control o, peor, a programar sin agente — pierdes la ×7 velocidad de desarrollo que sostiene tu roadmap y los equipos vuelven a hábitos que tardaron meses en abandonar.
Reescribir todas las specs en el último minuto. El switch del 15-jun es de pricing, no de funcionalidad. Las specs que tienes hoy siguen siendo válidas el 16-jun. Si llegas al 14-jun con una refactorización masiva en curso, el riesgo de regresión multiplica el problema FinOps que intentabas evitar.
Migrar a un modelo open-source "por si acaso". El ecosistema enterprise está convergiendo hacia Anthropic (Wall Street JV de mayo, EPAM 10k arquitectos certificados, PwC 30k, SAP-Anthropic — todo en los últimos 60 días). Migrar contra ese vector porque te asusta una factura es la decisión correcta para el día 30, no para el día 60.
Tu siguiente paso
Los 6 cambios anteriores son tu mínimo viable antes del 15-jun. Si quieres comprobar si tu equipo ya tiene la disciplina técnica que el switch va a exigir, el checklist SDD para tu equipo recoge 16 preguntas de diagnóstico — recibes el resultado por email en menos de 10 minutos.
Si tras hacer el checklist quieres una conversación de 30 minutos con onext sobre cómo aplicamos esto con equipos de 100-1.000 empleados, escribe a info@onext.es. El programa onext AI Engine es donde montamos los 6 cambios anteriores como parte del setup, no como parche post-overrun.
Preguntas frecuentes
¿Qué cambia exactamente el 15 de junio en la facturación de Claude Code?
Anthropic separa el contador de consumo de agentes del contador de consumo de chat humano. Cada usuario tendrá dos buckets mensuales espejo en lugar de uno. El precio unitario por token no cambia; lo que cambia es la visibilidad y la asignación del consumo. Antes del 15-jun, un agente en CI y un developer en sesión consumían contra el mismo presupuesto; a partir del 15-jun, contra dos presupuestos independientes.
¿Mi equipo tiene que aprobar los cambios a nivel CTO o basta con Lead Dev?
Los 4 primeros cambios técnicos (CLAUDE.md, rate limits, OpenTelemetry, specs SDD) los puede coordinar Lead Dev sin intervención de CTO si ya hay disciplina SDD instalada. Los 2 últimos (umbral de aprobación humana y auditoría semanal) tocan presupuesto y proceso organizativo — necesitan validación de CTO porque definen qué se considera "anormal" y quién interrumpe a quién. Aprobar el umbral monetario sin CTO es lo que produce los conflictos a las 3 de la mañana.
¿El cambio de Anthropic afecta también a Claude usado vía API directa, o sólo a Claude Code?
El split de contadores se aplica al producto Claude Code (el agente) y al producto Claude.ai (el chat). Si tu equipo invoca el API directamente desde código propio sin usar Claude Code, la facturación API directa sigue su lógica habitual — pero conviene revisar si lo que llamas "API directa" no es de facto un workflow agéntico embebido, en cuyo caso el split te alcanza igual de facto.
¿Cuánto se estima que sube la factura media de un equipo de 10 developers post-switch?
No sube por el switch en sí — el precio unitario por token no cambia. Lo que sí cambia es que los overruns por mal control agéntico ahora son visibles y atribuibles. En la práctica, los equipos sin gobernanza técnica ven incrementos del 30-80% en el primer mes post-switch antes de aplicar los 6 cambios, y vuelven al baseline o por debajo en el segundo mes.
¿Conviene esperar al 15-jun para empezar Spec-Driven Development o adelantarlo?
Adelantarlo. SDD reduce el consumo agéntico antes del switch (menos iteraciones, menos contexto innecesario, menos loops) y reduce la presión organizativa después (menos overruns, menos alertas, menos discusiones con el CFO). Empezar SDD el 14-jun te da casi todo el upside; empezarlo el 16-jun te lo da con un mes de retraso y bajo presión de incident reports.