Claude Sonnet 5: cómo medir el efecto de su nuevo tokenizador antes de migrar

Qué cambia y qué no demuestra la cifra de tokens

La documentación de migración de Anthropic señala que Claude Sonnet 5 utiliza un tokenizador nuevo. Para el mismo texto de entrada, el recuento puede ser aproximadamente un 30 % más alto que con Claude Sonnet 4.6, aunque el aumento concreto depende del contenido. El anuncio del modelo expresa la variación como un rango aproximado de 1,0 a 1,35 veces, también dependiente del tipo de texto. Son dos descripciones orientativas del mismo cambio, no una promesa de que todos los prompts crecerán en idéntica proporción.

La primera consecuencia es contable: un texto que antes generaba cierto número de tokens puede registrar más unidades en Sonnet 5. La segunda es operativa: si una aplicación llena casi toda su ventana de contexto, ese mismo material podría ocupar una fracción mayor del presupuesto. La guía también advierte que un valor de max_tokens calibrado para Sonnet 4.6 puede truncar una respuesta equivalente al usar Sonnet 5. Por tanto, no basta con cambiar el identificador del modelo y asumir que las mediciones anteriores siguen representando el comportamiento nuevo.

La cifra no permite concluir, por sí sola, que el coste aumentará en la misma proporción, que todas las entradas crecerán un 30 %, que el modelo tendrá peor rendimiento o que se reducirá el contexto máximo anunciado. El coste depende de las tarifas aplicables y de los tokens facturados de entrada y salida, además de cualquier tratamiento de caché. La utilidad de una respuesta requiere una evaluación aparte. Más tokens contabilizados describen una diferencia de representación, no la calidad del resultado.

La guía de novedades indica que Sonnet 5 admite una ventana de contexto de un millón de tokens y un máximo de salida de 128.000 tokens. Aunque el límite nominal de contexto pueda ser mayor que el de una configuración previa, la cantidad de texto que cabe bajo ese límite depende de cómo se tokenice el contenido. Conviene separar, por tanto, el límite del modelo de la capacidad efectiva de una aplicación para alojar sus documentos, instrucciones, historial y herramientas dentro de ese límite.

Qué medir en una integración real

Una comparación útil no se limita a enfrentar dos recuentos de entrada. Debe observar qué ocurre con el presupuesto completo de una solicitud: instrucciones del sistema, pregunta, documentos recuperados, historial, definiciones de herramientas y respuesta generada. En una tarea con contexto extenso, el aumento de tokens de los documentos puede ser más relevante que el de una pregunta breve; en una aplicación con salidas largas, los límites de generación y el valor de max_tokens también merecen una comprobación específica.

El recuento de tokens es una métrica intermedia. Para saber si el cambio afecta al producto hay que registrar, al menos, solicitudes que exceden el presupuesto previsto, respuestas truncadas, errores por límites, reintentos, respuestas que se descartan y resultados aceptados. Una tarea aceptada debe definirse antes de ejecutar la prueba: por ejemplo, una respuesta que supera los criterios de validez, formato y calidad establecidos por el equipo. Sin una definición previa, es fácil presentar como ahorro una ejecución más barata que sencillamente no completó el trabajo.

El coste por tarea aceptada puede expresarse como el gasto total de las ejecuciones incluidas dividido por el número de tareas que cumplen el criterio de aceptación. El numerador debe incluir las respuestas fallidas, los reintentos y las generaciones descartadas que hayan generado consumo facturable. Debe especificarse además cómo se contabiliza la caché, qué tarifa se ha aplicado y qué canal de acceso se utilizó. Esta métrica no es una tarifa oficial: es una medida operativa propuesta para comparar una integración.

También hay que distinguir entre un prompt repetido y uno nuevo. Si una parte del contexto se reutiliza mediante caché, el importe resultante puede diferir del de una entrada procesada sin ese tratamiento. Las páginas oficiales de precios describen tarifas y multiplicadores de caché, pero el equipo debe consultar los valores que estén vigentes para su modelo, región y plataforma en el momento de medir. No conviene trasladar una cifra histórica o de otra plataforma a una previsión actual.

Diseñar un corpus que permita atribuir el cambio

El corpus de evaluación debe representar el uso real y permanecer congelado durante la comparación. Una muestra estratificada puede separar español, otros idiomas que utilice el producto, código, documentos extensos, texto breve y contenido repetido. La estratificación no supone que esas categorías vayan a cambiar siempre en la misma dirección; sirve precisamente para descubrir si el efecto varía entre ellas. Si el producto trabaja con conversaciones, incluya historiales representativos. Si emplea recuperación de documentos, conserve también las consultas y los fragmentos que realmente entrega al modelo.

Guarde el texto exacto de cada entrada, su composición, el recuento obtenido con cada modelo y el resultado de la tarea. Evite normalizar espacios, cambiar instrucciones o actualizar documentos entre ejecuciones, salvo que esa transformación forme parte explícita de la prueba. Registre también la configuración y la fecha, así como el canal de acceso. De ese modo, si los recuentos cambian, podrá investigar la diferencia en vez de atribuirla vagamente a la migración.

La comparación de calidad necesita criterios idénticos y una revisión consistente. Cuando sea posible, evalúe los resultados sin revelar al revisor qué modelo los produjo. El objetivo no es proclamar que una versión es superior en general, sino verificar si la sustitución conserva el resultado requerido para las tareas de ese equipo. Un recuento mayor puede coexistir con una calidad similar o mejor; un coste menor puede coexistir con más fallos. Por eso es importante leer conjuntamente consumo y aceptación.

Protocolo para comparar Sonnet 5 con Sonnet 4.6

Antes de ejecutar la prueba, fije la pregunta que quiere responder. Puede ser si los prompts actuales siguen cabiendo con margen, si hay que reajustar límites de salida o si el gasto por tarea aceptada varía de forma material. No combine esas preguntas en una sola conclusión: cada una necesita una métrica distinta. Defina asimismo qué se consideraría material para el producto, como una reducción del margen de contexto que obligue a retirar contenido necesario, o un cambio de coste que supere el umbral interno del equipo.

Ejecute las mismas entradas con las dos versiones y mantenga iguales, en la medida en que el acceso lo permita, las instrucciones, herramientas, parámetros de generación y reglas de aceptación. Si alguna característica no tiene un equivalente entre versiones, documente la diferencia y no atribuya automáticamente su efecto al tokenizador. Registre por separado el recuento de entrada, el de salida, los estados de terminación, los errores y el uso de caché. Para cada ejecución, guarde el coste calculado con la tarifa aplicable en ese canal.

Después, compare resultados por estrato, no solo mediante un promedio global. Un promedio puede ocultar que el español aumente poco mientras ciertos documentos extensos aumentan más, o que el problema solo aparezca en solicitudes cercanas al límite. Revise los extremos y las tareas fallidas. Si la tasa de aceptación cambia, examine muestras concretas para distinguir errores de contenido de cortes por límite, formatos inválidos o cambios introducidos por la configuración.

Repita la prueba cuando cambie una variable relevante. Si se actualizan las tarifas, la documentación, el corpus o el sistema de caché, una cifra anterior deja de describir exactamente las condiciones nuevas. Mantener una versión fechada del conjunto de prueba y del cálculo permite comparar resultados a lo largo del tiempo sin confundir cambios del modelo con cambios del entorno.

Separar tokenización, tarifas y canal de acceso

Para atribuir un cambio al tokenizador, no basta con comparar una factura antes y después de migrar. El precio puede cambiar, el uso de caché puede variar, el prompt puede haberse editado y las respuestas pueden tener distinta longitud. La comparación más clara mantiene separadas tres preguntas: cuántos tokens registra el mismo contenido, cuánto se factura bajo las condiciones vigentes y cuántas tareas aceptadas produce cada configuración. Una diferencia en una de esas medidas no explica automáticamente las otras.

Tampoco debe suponerse que todos los canales ofrecen condiciones idénticas. La documentación de Amazon Bedrock proporciona información específica de ese servicio sobre disponibilidad, endpoints, regiones, APIs y facturación del modelo. La documentación de la plataforma de Anthropic es la referencia correspondiente para la API directa. Las fuentes verificadas disponibles no permiten afirmar que todos los detalles de conteo, caché, límites o facturación sean iguales entre canales. Si la aplicación accede a través de un tercero, mida allí y consulte su documentación y condiciones vigentes en vez de extrapolar los resultados de la API directa.

Aplique la misma cautela a los precios comparativos publicados en anuncios. Un precio anunciado o una comparación histórica no necesariamente describe lo que se factura hoy en cada plataforma y región. Use la documentación de precios vigente para convertir el uso medido en coste, y conserve la fecha y el canal de la tarifa usada. Si no puede mantener equivalentes las condiciones, describa la comparación como una evaluación del sistema completo y no como una medición aislada del tokenizador.

Decidir si migrar, ajustar o mantener temporalmente la versión anterior

Una migración está mejor respaldada cuando la prueba muestra que las tareas requeridas siguen pasando los criterios de aceptación, que los prompts caben con margen suficiente y que el coste por tarea aceptada se mantiene dentro del límite definido por el equipo. Si los recuentos suben pero no producen truncamientos ni un cambio material en el presupuesto, el aumento puede ser una variación contable que no exige rehacer la arquitectura. Aun así, conviene actualizar las previsiones y los paneles que dependían de recuentos anteriores.

Si el problema aparece solo en solicitudes cercanas al límite, puede bastar con revisar esos casos: reducir contexto redundante, ajustar la selección de documentos o recalibrar max_tokens cuando la aplicación requiera respuestas más largas. Estos cambios deben validarse con las mismas tareas de prueba, porque modificar prompts o contenido introduce una nueva variable. No se debe reducir contexto importante únicamente para compensar un recuento: el resultado tiene que continuar siendo aceptable.

Si la comparación revela fallos frecuentes, aumento del coste por tarea aceptada o resultados no concluyentes por diferencias entre canales, la respuesta razonable puede ser posponer la migración de esa integración, dividirla por tipos de tarea o hacer un despliegue controlado. Mantener temporalmente Sonnet 4.6 no implica que Sonnet 5 sea peor en general; significa que la evidencia del equipo aún no respalda un cambio para ese uso concreto. La decisión debe considerar también la disponibilidad y las condiciones vigentes de ambas versiones.

Documente tanto la decisión como las condiciones que podrían invalidarla. Una conclusión como «migrar» solo es útil si se acompaña de la versión evaluada, el corpus, el canal, la tarifa y la fecha. Sin esos datos, las cifras dejan de ser reproducibles y una futura modificación de precios o documentación puede convertir una comparación razonable en una referencia obsoleta.

Límites de la conclusión

La información publicada por Anthropic ofrece una referencia para iniciar la prueba, no un sustituto del corpus de cada organización. El rango aproximado de tokens varía según el contenido; por ello, una muestra dominada por texto breve puede no representar documentos largos, código, español u otros materiales de producción. Tampoco es posible inferir a partir de ese rango el coste final de una tarea, porque faltan la mezcla de entradas y salidas, la tarifa que se aplica y el tratamiento de caché de cada integración.

Las condiciones pueden variar con el tiempo. El anuncio de un modelo, una página de migración y una página de precios pueden actualizarse en fechas diferentes. Antes de desplegar, compruebe la documentación oficial vigente y anote qué versión y canal fueron evaluados. Las fuentes consultadas no establecen una equivalencia universal de recuentos, límites y facturación entre la API de Anthropic y los servicios de terceros; cualquier conclusión en ese sentido requiere verificar el canal concreto.

En consecuencia, la pregunta útil no es si Sonnet 5 consume siempre un porcentaje fijo más de tokens, sino cuánto cambia el uso de recursos en la carga de trabajo que se quiere migrar y si ese cambio altera el resultado aceptable. Un experimento controlado permite responderlo con menos riesgo que extrapolar una cifra general. Para comparar otras opciones disponibles en el catálogo, el punto de partida puede ser el índice de modelos, pero una evaluación de migración debe conservar las mismas condiciones y criterios para cada caso.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.