El fin de los tokens subvencionados: por qué el pricing usage-based cambia la estrategia de AI agents en la empresa

A 28 de mayo de 2026, una parte importante de la industria AI ya está dejando atrás el modelo mental de “copilot plano por usuario”. El cambio no consiste solo en una nueva tabla de precios. Consiste en que los proveedores están empezando a cobrar de forma mucho más visible por el trabajo real que ejecutan los modelos: tokens de entrada, tokens de salida, contexto en caché, búsquedas, herramientas y sesiones largas.

Para un CTO, ese cambio importa porque los agentes no se comportan como un SaaS tradicional por asiento. Un usuario humano puede abrir un chat, pedir una tarea y cerrar la sesión. Un agente puede encadenar pasos, revisar repositorios completos, llamar herramientas, iterar durante horas y consumir contexto a una escala mucho menos predecible. Cuando eso pasa, el coste marginal de inferencia deja de ser un detalle técnico y pasa a ser una decisión de arquitectura, control y operación.

La consecuencia es simple: la adopción de AI agents ya no puede diseñarse solo como enablement de herramientas. Tiene que diseñarse como una capacidad operable, medible y financieramente sostenible.

Qué está cambiando exactamente

La señal más explícita llegó desde GitHub. El 27 de abril de 2026 anunció que GitHub Copilot pasará a facturación usage-based desde el 1 de junio de 2026. El argumento es revelador: una pregunta rápida y una sesión autónoma de varias horas ya no pueden costar lo mismo. GitHub plantea el cambio como una transición desde unidades abstractas a consumo de `AI Credits` calculado a partir de tokens de entrada, salida y caché.

No es un caso aislado. Anthropic ya documenta el uso en equipo de Claude Code como consumo de tokens API, con límites y controles de gasto por workspace. OpenAI, por su parte, sigue una lógica claramente usage-based en su API: precios por millón de tokens, herramientas con coste específico y presupuestos mensuales configurables a nivel de cuenta o proyecto. En ambos casos, la idea de fondo es la misma: el uso intensivo y agentico debe gobernarse como consumo operativo, no como acceso prácticamente plano.

La lectura editorial coincide con eso. `The AI Daily Brief` resumió el 22 de mayo de 2026 que el “flat-rate AI experiment” está, en la práctica, acabándose. Es una buena forma de entender el momento: el mercado está dejando de subvencionar de manera opaca workloads pesados mientras intenta mantener fiabilidad y márgenes.

Conviene matizar algo importante. No todos los proveedores han hecho el giro de la misma forma ni en la misma fecha. Pero la dirección converge: más visibilidad sobre consumo real, menos ficción de coste uniforme por usuario y más presión para que el cliente gestione gasto, límites y rendimiento por caso de uso.

Por qué los agentes rompen el modelo mental de coste por usuario

El problema del pricing plano no es solo financiero para el proveedor. También es un mal modelo mental para la empresa compradora.

Un copiloto usado como asistente puntual tiene una variabilidad de coste relativamente acotada. Un agente no. Puede:

• leer mucho más contexto del que leería una persona en una consulta breve
• generar múltiples iteraciones antes de converger
• invocar herramientas que añaden tokens y tiempo de ejecución
• encadenar subtareas o subagentes dentro de un mismo workflow
• quedarse atrapado en loops o rutas de trabajo poco eficientes

En otras palabras: el coste deja de correlacionar bien con el número de usuarios y empieza a correlacionar con el tipo de trabajo, el nivel de autonomía, la calidad del contexto, la disciplina operativa y la elección de modelos.

Esto cambia también la conversación interna. Si una empresa sigue comprando AI agents como si fueran solo “licencias de productividad”, es muy fácil que el presupuesto aparente sea razonable mientras el coste real se desplaza a consumos variables mal observados. El problema no aparece en la compra inicial. Aparece cuando varios equipos empiezan a escalar automatizaciones útiles y el consumo deja de ser anecdótico.

El verdadero riesgo no es pagar más, sino no saber por qué se paga

La peor situación para un CTO no es descubrir que la AI cuesta dinero. Eso ya era evidente. La peor situación es descubrirlo tarde y sin capacidad de explicar qué workflows consumen, qué valor producen y qué controles faltan.

Hay cinco riesgos especialmente frecuentes.

1. Gasto invisible por workflow

Cuando la observabilidad se queda en métricas de herramienta o de usuario, nadie ve bien cuánto cuesta un caso de uso concreto. Se sabe quién usa la plataforma, pero no qué automatización consume más, qué agente se dispara de presupuesto o qué flujo genera más retrabajo.

Sin esa capa, la organización no puede hacer una conversación seria de ROI.

2. Loops y contexto sobredimensionado

En workloads agenticos, una mala arquitectura de contexto o una autonomía mal definida no solo degrada calidad. También degrada economía. El agente relee demasiados artefactos, mantiene conversaciones demasiado largas o reintenta tareas que deberían cortar antes. Lo que parece un problema de diseño se convierte enseguida en un problema de coste.

3. Modelo equivocado para la tarea equivocada

Si todo se enruta al modelo más caro por defecto, la organización compra comodidad local a costa de eficiencia estructural. El pricing usage-based obliga a decidir con más disciplina qué tareas merecen frontier models, cuáles funcionan bien con modelos más baratos y dónde conviene usar caché, batch o límites de contexto.

4. Falta de chargeback o showback

Cuando varios equipos comparten presupuesto AI sin reglas claras, aparecen fricciones previsibles. Producto quiere acelerar discovery, ingeniería quiere automatizar delivery, operaciones quiere probar agentes internos y marketing quiere escalar research o contenido. Si nadie puede atribuir consumo con claridad, el presupuesto se vuelve político antes que operativo.

5. Escalar autonomía antes que controles

El pricing usage-based no castiga solo el volumen. También castiga la falta de disciplina. Un agente con permisos amplios, poca trazabilidad y sin criterios claros de parada puede ser caro y arriesgado a la vez. Ahí es donde coste, calidad y governance dejan de ser conversaciones separadas.

Qué debería hacer ahora un CTO

La respuesta útil no es frenar la adopción. Es madurarla más deprisa que el gasto.

Estas cinco decisiones ayudan a hacerlo.

Presupuestar por caso de uso, no solo por proveedor

La unidad útil de gestión no es “cuánto gastamos en OpenAI, Anthropic o GitHub”. La unidad útil es “cuánto cuesta este workflow y qué retorno esperamos”. Un agente de soporte interno, uno de delivery, uno de research o uno de operaciones de marketing no comparten la misma economía ni la misma tolerancia al error.

Si el presupuesto se define por proveedor, la conversación llega tarde. Si se define por caso de uso, puede convertirse en una decisión de portfolio.

Diseñar observabilidad de consumo desde el principio

Hace falta ver consumo, latencia, rutas de modelo, herramientas llamadas, tamaño de contexto, reintentos y coste por ejecución. No para microgestionar cada prompt, sino para distinguir patrones sanos de patrones caros e improductivos.

Una organización no necesita observabilidad perfecta para empezar. Pero sí necesita suficiente visibilidad como para detectar dónde se está quemando presupuesto sin generar valor proporcional.

Aplicar routing de modelos con criterio económico

No todo el trabajo merece el modelo más caro ni el máximo contexto. El routing debería responder a dos preguntas:

1. qué nivel de inteligencia necesita de verdad esta tarea
2. qué coste máximo tiene sentido para el valor que produce

Esa disciplina obliga a diseñar mejor. También mejora la resiliencia del sistema cuando cambian precios, límites o disponibilidad de modelos.

Fijar límites de autonomía y gasto

Igual que un sistema financiero serio define autorizaciones por importe y riesgo, una capa seria de agentes debería definir límites por consumo, duración de sesión, número de pasos, herramientas permitidas y condiciones de escalado humano.

Esto no es una barrera a la innovación. Es lo que evita que el aprendizaje salga demasiado caro.

Convertir ROI en una conversación operativa

La pregunta correcta no es si la AI “parece útil”. La pregunta es si reduce tiempo, retrabajo, coste o riesgo de manera mensurable en un workflow concreto. Eso exige medir outcomes, no solo actividad.

Cuando el pricing era más opaco, muchas organizaciones podían posponer esa disciplina. Con pricing usage-based, posponerla sale peor.

Lo que este cambio dice sobre el mercado

Hay una lectura estratégica de fondo. El fin de los tokens subvencionados no es solo una mala noticia para quien esperaba barra libre. También es una señal de madurez.

El mercado está dejando claro que los agentes generan valor, pero no valor gratis. Operarlos exige una economía real: consumo visible, presupuestos, límites, monitorización y decisiones más finas sobre arquitectura. Eso se parece mucho más a operar una capacidad de software que a comprar una app cerrada por asiento.

Para una empresa mediana o grande, esta transición puede ser positiva si la interpreta bien. Obliga a profesionalizar antes la adopción. Obliga a distinguir experimentos vistosos de workflows sostenibles. Y obliga a conectar AI con finanzas, plataforma, seguridad y operación antes de que el uso se disperse.

Dónde encaja vBote

Aquí es donde vBote puede aportar valor real sin vender humo. No tanto por elegir “el modelo ganador” de la semana, sino por ayudar a diseñar sistemas de agentes que una empresa pueda operar con criterio.

Eso incluye:

• definir la economía por caso de uso
• instrumentar observabilidad de consumo y rendimiento
• diseñar routing de modelos y límites de autonomía
• reducir loops, contexto excesivo y gasto invisible
• conectar coste, control y ROI dentro del workflow real

La tesis útil para negocio no es “usa más agentes”. Es “usa agentes que puedas medir, gobernar y sostener”.

El siguiente paso razonable

Si una empresa ya está probando AI coding, research automation o agentes internos, ahora mismo conviene revisar una pregunta incómoda: ¿seguimos pensando este esfuerzo como licencias por usuario o ya lo estamos operando como una capacidad con economía propia?

Porque el cambio de pricing que se está consolidando en mayo y junio de 2026 no es una anécdota comercial. Es una advertencia de diseño. Los agentes AI ya no pueden desplegarse como si el coste real estuviera escondido detrás de una tarifa plana.

Y cuanto antes asuma eso un CTO, antes podrá escalar con menos sorpresa, mejor control y un ROI bastante más defendible.