Hoy, 31 de agosto, expiraba el precio promocional con el que se lanzó Claude Sonnet 5, y llevamos días viendo circular la advertencia de que mañana todo sube. No va a ocurrir. La documentación oficial de precios de Anthropic incluye una nota explícita: la tarifa de 2 dólares por millón de tokens de entrada y 10 por millón de salida, anunciada en su día como introductoria hasta el 31 de agosto de 2026, es ya el precio estándar, y la subida prevista a 3 y 15 dólares para el 1 de septiembre no se va a producir. Dicho esto, hay un cambio que sí afecta a tu factura y que casi nadie está mirando: el tokenizador.
La tarifa que era temporal se queda como estándar
El movimiento es poco habitual y merece la pena leerlo bien: no es una prórroga de la promoción, es la eliminación del precio antiguo. Sonnet 5 se queda en 2 y 10 dólares por millón sin fecha de caducidad, cuando Sonnet 4.6 y Sonnet 4.5 siguen listados a 3 y 15. Es decir, la generación nueva es un tercio más barata por token que la anterior en la lista de precios.
Los precios asociados al almacenamiento en caché acompañan a esa tarifa: 2,50 dólares por millón para escribir en la caché de cinco minutos, 4 dólares para la de una hora y 0,20 dólares por lectura de caché. Y con la API de lotes, para tareas que no necesitan respuesta inmediata, todo se queda en la mitad: 1 y 5 dólares por millón.
Estos multiplicadores importan más de lo que parece cuando trabajas con contextos largos y repetidos. Una escritura de caché de cinco minutos cuesta 1,25 veces el precio de entrada y una lectura cuesta el 10%, así que la caché corta empieza a salir rentable a partir de la primera lectura; la de una hora, que cuesta el doble escribirla, necesita dos lecturas para compensar. Si tienes un prompt de sistema grande que se repite en cada ejecución de un workflow, esa es la diferencia entre pagarlo una vez o pagarlo cien.
El tokenizador nuevo mete un 30% más de tokens
Aquí está el dato que descoloca las estimaciones. Los modelos 4.7 y posteriores, Sonnet 5 incluido, usan un tokenizador nuevo que contribuye a su rendimiento pero que produce alrededor de un 30% más de tokens para el mismo texto. Sonnet 4.6 y los anteriores usan el tokenizador previo. El incremento exacto depende del contenido y de la forma de la carga de trabajo, y los análisis del cambio apuntan a que el impacto es mayor en código, datos estructurados y textos que no están en inglés, que es exactamente el tipo de material con el que trabajamos la mayoría.
La consecuencia práctica es que el precio por token y el precio por tarea han dejado de moverse juntos. Puedes tener una bajada en la lista de precios y una subida en el consumo real de la misma llamada. Cualquier hoja de cálculo hecha con datos de Sonnet 4.6 y trasladada tal cual a Sonnet 5 está mal, aunque el número de la tarifa sea más bajo.
El precio por token bajó, pero el número de tokens subió: solo cuenta lo que sale de multiplicar los dos.
La cuenta con los dos efectos a la vez
Vamos a hacer el cálculo, porque es la única forma de saber si has ganado o has perdido. Supongamos una tarea cuyo texto de entrada equivalía a un millón de tokens con el tokenizador antiguo, ejecutada con Sonnet 4.6 a 3 dólares por millón: son 3 dólares. Ese mismo texto, con el tokenizador nuevo, pasa a contar unos 1,3 millones de tokens, que a 2 dólares por millón salen a 2,60 dólares.
El resultado es que sigues ganando, pero no lo que anunciaba el titular. La lista de precios sugiere un ahorro del 33% y la realidad, con el conteo nuevo, se queda en torno al 13%. En salida ocurre lo mismo: 15 dólares por ese millón de tokens antiguos frente a unos 13 con el modelo nuevo. Sigue siendo más barato; simplemente no es la mitad de barato que parecía.
💡 Cómo medirlo en tu caso en cinco minutos
No estimes: cuenta. Coge un prompt real de tu flujo —uno con código o JSON dentro, no un texto de ejemplo en inglés— y pásalo por el endpoint de conteo de tokens antes de lanzar nada. Compara ese número con el que registraba tu ejecución equivalente en Sonnet 4.6. Ese cociente, y no el 30% genérico, es el que debes aplicar a tus previsiones de coste.
Qué revisar hoy si disparas la API desde n8n
Para quien tiene automatizaciones corriendo sin supervisión, esta noticia tiene tres consecuencias muy concretas. La primera: no hay que hacer nada urgente esta noche. Si habías planificado migrar workflows a otro modelo antes del 1 de septiembre para esquivar la subida, puedes cancelar esa tarea.
La segunda: revisa los límites de tokens que tengas puestos a mano en los nodos. Si en su día fijaste un tope de contexto o un max_tokens calculado con el conteo antiguo, ese margen se te ha estrechado un 30% sin que nadie te avise, y el síntoma no es un error claro sino una respuesta cortada a mitad o un rechazo por longitud en la peor ejecución posible, la nocturna.
Y la tercera, la que más dinero mueve a final de mes: si tus workflows repiten el mismo bloque de contexto en cada ejecución —instrucciones de estilo, esquema de la base de datos, plantilla del cliente—, ese bloque es el candidato natural a la caché de prompts. Con lecturas a 0,20 dólares por millón, un prompt de sistema pesado deja de ser el coste fijo de cada ejecución para convertirse en calderilla. Y si el trabajo admite esperar, la API de lotes recorta otro 50% sobre todo lo anterior.
La conclusión, en una línea: la tarifa de Sonnet 5 ya no tiene fecha de caducidad, y tu estimación de coste tampoco puede seguir teniendo la del tokenizador viejo. Mide una vez con tus propios prompts y ajusta las previsiones antes de que lo haga la factura.
