La inflación de tokens: cómo Anthropic sube la factura de la IA sin subir precios

💡 TL;DR — Anthropic no ha subido el precio de Claude Opus 4.7. Ha hecho algo más sutil: ha cambiado el tokenizador y el nivel de "esfuerzo" por defecto. Resultado: mismo precio por token, pero más tokens por cada consulta. La factura sube sin anuncio de subida. Si metes IA en procesos de negocio, esto obliga a dejar de mirar el pricing del modelo y empezar a gobernar el consumo.

Qué ha pasado realmente

Con el lanzamiento de Claude Opus 4.7, Anthropic envió un mensaje muy claro a desarrolladores y empresas:

"El precio sigue siendo el mismo que el de Opus 4.6: 5 dólares por millón de tokens de entrada y 25 dólares por millón de tokens de salida."

Aparentemente, cero fricción: actualizas el modelo, mejoras resultados, y la factura no cambia.

La realidad es más incomoda. En el mismo comunicado, Anthropic avisa de dos cambios con impacto directo en el coste:

1. Nuevo tokenizador. La misma entrada genera entre 1,0 y 1,35 veces más tokens que con Opus 4.6.
2. Nuevo nivel de "esfuerzo" xhigh por defecto. El modelo razona más antes de responder, sobre todo en flujos agénticos, y produce más tokens de salida — que son 5 veces más caros que los de entrada.[1]

Es el equivalente a que tu proveedor de luz te diga "no hemos subido el kWh"… pero cambie discretamente el contador para que gires más rápido.

Por qué el tokenizador sí importa (aunque suene técnico)

Los modelos de lenguaje no procesan texto: procesan tokens. Un tokenizador es lo que convierte tu texto en esas unidades mínimas que el modelo entiende y cobra.

Si Anthropic cambia el tokenizador, el mismo prompt que antes generaba 1.000 tokens ahora puede generar hasta 1.350. Y como se factura por token, el coste efectivo sube aunque el precio unitario se mantenga.

Esto no es una teoría: lo han verificado terceros.

• Simon Willison comparó el system prompt oficial de Opus 4.7 en ambos modelos: pasó de 5.039 tokens de salida con 4.6 a 7.335 tokens con 4.7. Un crecimiento de 1,46x, por encima del 1,35x oficial.
• Bill Chambers creó una herramienta llamada Tokenomics para medir el consumo real entre ambos modelos. El promedio agregado entre sus usuarios: +38,6 % de tokens.
• En el caso de imágenes, el aumento puede llegar a 3x, porque el nuevo modelo soporta hasta 3,75 Mpíxeles y eso dispara el número de tokens por imagen.[1]

Y todo esto antes de tocar el segundo factor: el nivel de esfuerzo.

El nuevo nivel xhigh: más "pensamiento", más factura

Opus 4.7 introduce un nuevo nivel de razonamiento, xhigh, situado entre high y max. Y lo ha puesto por defecto para todos los planes.

Traducción: el modelo "piensa más" antes de responder, especialmente en turnos posteriores de configuraciones agénticas. Eso mejora la fiabilidad en problemas difíciles… y genera más tokens de salida. La propia Anthropic lo reconoce:

"Opus 4.7 piensa más en niveles de esfuerzo alto, particularmente en turnos posteriores en configuraciones agénticas. Esto mejora su fiabilidad en problemas difíciles, pero sí significa que produce más tokens de salida."

Y no es solo un tema de coste. En Reddit y X hay hilos muy críticos hablando de regresiones, alucinaciones, respuestas excesivamente largas y límites de los planes Pro y Max que se agotan antes que con el modelo anterior.[1]

La fórmula que debería mirar cualquier CFO o responsable de IT

El "precio de Claude" no es 5$ni 25$. El coste real que impacta en tu P&L responde a esta fórmula:

$$\text{Coste} = \text{Tokens}_{\text{entrada}} \times P_{\text{in}} + \text{Tokens}_{\text{salida}} \times P_{\text{out}}$$

Con los parámetros actuales de Opus 4.7:

Es decir: si hace un mes tu piloto de IA costaba 1.000 €/mes con Opus 4.6, al migrar a 4.7 sin tocar nada puedes estar perfectamente en 1.350 – 1.500 €/mes. Sin haber recibido ningún email de "subida de precios".

El patrón más incomodo: el pricing ya no es la métrica

Esto no es un bug. Es un cambio de modelo de negocio silencioso. Y encaja con otras señales:

• Quejas previas de "regresiones" en Opus 4.6.
• Tarifas planas de IA para programar que, según varios análisis, son matemáticamente insostenibles.
• Proveedores que ajustan cuotas, ventanas de contexto y niveles de esfuerzo sin grandes anuncios.

Dibuja un patrón claro: el proveedor mueve palancas internas que afectan al coste efectivo, sin tocar la tarifa de cara a la galería.

Para una empresa que tenga IA solo en una demo, esto es anécdota. Para una empresa que está metiendo IA en procesos críticos — ventas, soporte, finanzas, operaciones — esto es un riesgo estratégico de primer orden.

Cómo gobernar el coste real de la IA en tu empresa

En los proyectos de automatización e IA en los que trabajamos en Procesim, partimos de una premisa simple:

🧭 El coste de la IA en producción no se controla eligiendo "el modelo más barato". Se controla gobernando el consumo por caso de uso.

Estas son las cinco palancas que aplicamos de forma sistemática:

1. Medir el coste por caso de uso, no por modelo

No basta con saber que "Claude Opus cuesta X". Hay que saber cuánto cuesta cada workflow: responder un ticket, generar una propuesta, analizar una factura, etc. Esto exige logging de tokens por tarea y reporting agregado.

2. Definir presupuestos duros por tarea

La práctica de Anthropic con los task budgets va en la línea correcta: poner techos a cuántos tokens puede consumir cada tarea antes de cortar o escalar. En arquitecturas con n8n, agentes o RAG, traducimos esto en límites explícitos por ejecución.

3. Ajustar el nivel de esfuerzo por tipo de tarea

No todo necesita xhigh. Clasificación de correos, resumen de reuniones, extracción de datos estructurados… muchas tareas funcionan perfecto con medium o high. Dejar xhigh solo para razonamiento crítico (debugging complejo, análisis legal, diseño de arquitectura) ya reduce la factura sin perder calidad.

4. Controlar la verbosidad del modelo

Cada palabra de más en la salida es dinero. Prompts que obliguen a respuestas estructuradas, con límites explícitos de longitud y salidas en formato JSON suelen recortar entre un 20 % y un 40 % del consumo de salida.

5. Tener plan B (y C)

Un buen sistema de IA en producción no depende de un único proveedor ni de un único modelo. Diseñamos routing por tarea: modelo potente para razonamiento complejo, modelos más pequeños o locales para lo rutinario, y fallback a versiones anteriores (Opus 4.6, Sonnet 4.6…) cuando el ROI no compensa.

Qué deberías hacer esta semana si usas Claude en producción

Una checklist muy aplicada:

• Revisar el consumo de tokens antes y después de la migración a Opus 4.7 (mínimo 1 semana).
• Comprobar si xhigh está actuando por defecto en tus endpoints, y bajarlo donde no aporte valor.
• Usar /usage en Claude Code o los paneles de la API para ver en qué se va el gasto.
• Fijar presupuestos por tarea en los flujos agénticos (n8n, Claude Code, agentes custom).
• Validar si para tu caso compensa seguir con Opus 4.6 o Sonnet 4.6, mientras sigan disponibles.
• Empezar a reportar coste de IA por proceso de negocio, no solo por factura total.

La conclusión incómoda

La historia de Claude Opus 4.7 no va realmente de un modelo. Va de cómo los proveedores de IA están madurando su modelo de ingresos. Y va de cómo las empresas que usan IA tienen que madurar su modelo de control.

En 2026, ganar con IA no va de elegir el modelo más barato ni el más potente. Va de gobernar el consumo caso por caso, con la misma seriedad con la que se gobierna cualquier otra partida de coste crítico.

Quien no lo haga, va a descubrir la próxima "inflación de tokens" donde siempre se descubre: en la factura, no en el comunicado oficial.

🚀 ¿Estás metiendo IA en procesos de tu empresa y quieres tener control real del coste por workflow? En Procesim diseñamos arquitecturas de IA agéntica con gobernanza, task budgets y observabilidad de coste desde el día uno. Si quieres revisar cómo está tu caso, hablamos.

---

Fuente principal: Anthropic no ha subido el precio de Claude. Ha inventado algo mejor: la inflación de tokens — Xataka