Opus 4.7 de Anthropic gasta más tokens: inflación oculta con los mismos precios

Anthropic ha lanzado Claude Opus 4.7, y las primeras pruebas a través de la API han mostrado algo inesperado: un mismo texto puede ocupar bastantes más tokens en el nuevo modelo que en Opus 4.6. Con precios formalmente sin cambios, esto supone un aumento discreto pero real de los costes.

En qué consiste el problema

El tokenizador es el componente que divide el texto en fragmentos antes de pasárselo al modelo. El número de esos fragmentos determina el coste de una solicitud y el espacio que ocupa en la ventana de contexto. Cuando Anthropic cambia el tokenizador entre versiones, un mismo prompt pasa a «pesar» de otra manera. Con Opus 4.7, el peso ha aumentado.

Si antes una solicitud típica ocupaba 1000 tokens, ahora puede ocupar entre 1300 y 1500. El precio por millón de tokens no ha cambiado, pero en la práctica se consumen más tokens por el mismo trabajo.

«El resultado es una inflación oculta: los precios y los límites son los mismos que antes, pero en la práctica los gastos pueden aumentar», según la investigación del equipo de

Kodik.

Kodik, que desarrolla un editor de código compatible con varios modelos de IA, comprobó por su cuenta el comportamiento del tokenizador a través de la API. Anthropic no ha publicado datos comparativos oficiales, así que los desarrolladores hicieron las pruebas ellos mismos y compartieron sus conclusiones.

Qué contenido se ve más afectado

El aumento de tokens no es igual para todos los tipos de texto. Con los datos disponibles, el panorama es este:

• Código: un aumento apreciable, sobre todo en lenguajes con muchos caracteres especiales: operadores, corchetes, sangrías
• Cadenas técnicas (JSON, XML, YAML, SQL): los cambios varían según la estructura; las construcciones anidadas pueden crecer más
• Prompts de sistema: les afecta igual que a las solicitudes de usuario; es especialmente delicado en productos con instrucciones de sistema largas
• Texto normal: crecimiento moderado, menos visible en solicitudes cortas
• Contenido mixto (texto + código + JSON): el comportamiento es impredecible, conviene probar con cada escenario concreto

Hay que tener en cuenta la escala: si un prompt crece un 20 % y se hacen un millón de solicitudes al día, la factura real cambia de forma muy significativa.

Por qué es un problema sistémico

Opus 4.7 no es una excepción. El tokenizador puede cambiar en cualquier modelo de cualquier proveedor, y no siempre se menciona de forma explícita en las notas de la versión. Para los equipos que construyen productos sobre una API, esto crea varios riesgos.

Sorpresas presupuestarias. Los límites calculados con datos históricos pueden superarse de forma inesperada tras cambiar de modelo, incluso si las solicitudes no han cambiado.

Desbordar la ventana de contexto. Un sistema que antes cabía en 128k tokens puede empezar a truncar el contexto o a devolver un error tras la actualización.

Pruebas A/B injustas. Al comparar la calidad de dos versiones de un modelo con los mismos datos, un tokenizador distinto significa que los modelos reciben una entrada técnicamente diferente, lo que influye en la interpretación de los resultados.

Regresiones ocultas en pipelines RAG. Si empaquetas fragmentos según un límite de tokens, un cambio de tokenizador puede romper la lógica de división sin un solo error en los registros.

Qué significa esto

Los desarrolladores que ya usan Opus en producción o planean pasar a la 4.7 deberían pasar sus prompts reales por la API del tokenizador de ambas versiones antes de cambiar. Llevará unas horas, pero permite estimar con honestidad el aumento de costes y ajustar el presupuesto o la arquitectura.

El caso de Opus 4.7 es un buen recordatorio: al actualizar un modelo, conviene comprobar no solo la calidad de las respuestas, sino también la eficiencia de la tokenización.