Claude Opus 4.7 de Anthropic gasta más tokens de lo anunciado

El nuevo tokenizador de Claude Opus 4.7 puede encarecer de forma notable el uso del modelo: en pruebas reales, el consumo se acercó al 45–47 %, y no al 0–35 % que indica Anthropic en su guía de migración. Para los equipos que trabajan con prompts largos, grandes instrucciones de sistema y prefijos en caché, la diferencia no es cosmética. Golpea directamente las cuotas, la velocidad y el coste de cada sesión.

El análisis nació de la discrepancia entre la promesa y la práctica. La documentación de Anthropic afirma que el nuevo tokenizador usa aproximadamente entre 1.0 y 1.35 veces más tokens que el de Opus 4.6. El autor decidió comprobarlo no con ejemplos abstractos, sino con materiales parecidos a la carga de trabajo real de los desarrolladores.

En la primera medición pasó documentación técnica por el tokenizador y obtuvo un aumento de hasta 1.47x. En la segunda tomó un archivo CLAUDE.md real, es decir, un gran contexto de instrucciones, y vio un resultado casi idéntico: 1.45x. La distancia con el límite superior de la guía es demasiado grande para atribuirla al ruido habitual de las mediciones.

El problema no es el aumento de tokens en sí: a veces un tokenizador más pesado sí aporta mejoras en calidad, estabilidad o manejo de textos complejos. La cuestión es que Anthropic no ha cambiado ni los precios ni las cuotas. Si el mismo texto ocupa ahora más tokens, el usuario llega antes a los límites de contexto, topa antes con el rate limit y gasta más presupuesto en cada iteración.

Es especialmente doloroso en escenarios con un prompt de sistema largo, un conjunto de reglas, ejemplos de respuestas, fragmentos de documentación y un prefijo en caché que se envía una y otra vez. Sobre el papel, la tarifa es la misma, pero su capacidad útil es en la práctica menor.

Por eso el autor fue más allá del simple recuento e intentó entender qué recibe el modelo a cambio. Según la descripción del experimento, se comprobaron las ventajas declaradas del nuevo tokenizador y su comportamiento en tareas prácticas. La conclusión clave es que no hubo una compensación milagrosa: al menos en los escenarios probados, el aumento del consumo fue muy visible, mientras que la mejora no parecía igual de clara ni sistemática. Dicho de otro modo, para quien paga por tokens o vive dentro de cuotas de suscripción, el trato no favorece al usuario. Eso no significa necesariamente que Opus 4.7 sea peor como modelo, pero sí que su economía se ha vuelto menos cómoda.

Es una señal importante para el mercado. El tokenizador rara vez se discute fuera de un círculo estrecho de ingenieros, aunque determina cuánto texto real cabe en la ventana de contexto y cuánto cuesta cada operación vía API. Una diferencia del 5–10 % suele ser tolerable y puede perderse entre la variabilidad normal de las peticiones.

Pero un salto de alrededor del 45 % ya no es un detalle técnico: influye en la arquitectura de los agentes, la longitud de las instrucciones de sistema, la estrategia de caché e incluso la economía unitaria de un producto. Si un equipo tiene un pipeline donde el mismo prefijo grande participa en cientos de llamadas, los tokens adicionales empiezan a devorar dinero y capacidad de procesamiento muy rápido.

La conclusión práctica es sencilla: la migración a Claude Opus 4.7 debe evaluarse con los corpus de texto propios, no con la formulación de marketing de la guía de migración. Conviene probar por separado los prompts de sistema, los archivos de instrucciones, la documentación, las plantillas de tareas de agentes y todo lo que entre con frecuencia en el contexto. Si las mediciones muestran un aumento cercano a 1.45x, quizá el equipo tenga que recortar prompts, sacar parte de la lógica del contexto, replantear la caché o incluso aplazar la migración hasta que el beneficio sea más claro.

La lección principal es que la calidad de un modelo no puede juzgarse solo por demos y benchmarks: a veces lo decisivo no es la inteligencia de la respuesta, sino el precio de cada token de más.