Resultados de la medición del costo del tokenizador de Claude 4.7

• Claude 4.7 genera en promedio entre 1.3 y 1.45 veces más tokens que la versión anterior, lo que provoca un aumento de costos por sesión de 20 a 30% bajo el mismo esquema de precios
• El aumento de tokens es especialmente notable en contenido en inglés y código, mientras que en contenido CJK (chino, japonés y coreano) casi no hay cambios
• Debido a una tokenización más detallada, la adhesión a instrucciones (Instruction Following) mejora en alrededor de 5 pp, especialmente con menos errores de formato
• Como aumenta la cantidad de tokens del prefijo en caché y del historial de conversación, también suben los costos de caché y la velocidad de consumo del rate limit
• En conclusión, Claude 4.7 se evalúa como una estructura en la que se obtiene mayor precisión y ejecución más detallada de instrucciones a cambio de asumir un costo adicional de tokens

---

Resultados de la medición del tokenizador de Claude 4.7

• Claude Opus 4.7 de Anthropic indica que usa entre 1.0 y 1.35 veces más tokens que la versión anterior 4.6, pero en mediciones reales se confirmó un nivel de 1.45 a 1.47 veces
• Con el mismo precio y las mismas cuotas, el aumento de tokens provoca efectos como mayor velocidad de consumo de la ventana máxima, incremento del costo del prefijo en caché y alcance anticipado del rate limit
• El experimento se compuso de dos partes: medición de costos y medición de adhesión a instrucciones

Método de medición de costos

• Se usó el endpoint POST /v1/messages/count_tokens de la API de Anthropic para ingresar el mismo contenido a los modelos 4.6 y 4.7, comparando solo la diferencia pura del tokenizador
• Se utilizaron dos conjuntos de muestras
  • 7 muestras reales enviadas por usuarios reales de Claude Code
  • 12 muestras artificiales con inglés, código, datos estructurados, CJK, emoji, símbolos matemáticos, etc.

• Resultados con contenido real de Claude Code

  • Promedio ponderado de 1.325 veces en las 7 muestras reales (8,254 → 10,937 tokens)
  • Ejemplos principales
  • Archivo CLAUDE.md: 1.445 veces
  • Prompt de usuario: 1.373 veces
  • Post de blog: 1.368 veces
  • Diff de código: 1.212 veces

• Resultados por tipo de contenido (12 muestras artificiales)

  • Promedio de contenido en inglés y código: 1.345 veces
  • Promedio de contenido CJK (chino, japonés y coreano): 1.01 veces
  • Ejemplos detallados
  • Documentación técnica: 1.47 veces
  • Shell script: 1.39 veces
  • Código TypeScript: 1.36 veces
  • Prosa en inglés: 1.20 veces
  • JSON: 1.13 veces
  • Prosa en japonés y chino: 1.01 veces

Patrones de cambio del tokenizador

• El contenido CJK, emoji y símbolos se mantiene casi sin cambios, en el rango de 1.005 a 1.07 veces
  • Parece que el vocabulario no latino no fue modificado de forma importante
• El contenido en inglés y código aumenta entre 1.20 y 1.47 veces, y el código se ve más afectado que la prosa
  • Las cadenas repetitivas del código (keywords, import, identificadores, etc.) se fragmentan con más detalle y se dividen en más tokens
• La proporción de tokens por carácter en inglés baja de 4.33→3.60, y en TypeScript de 3.66→2.69
  • El mismo texto se representa al separarse en unidades más pequeñas

Por qué usa más tokens

• Anthropic destacó en 4.7 una “tendencia a seguir las instrucciones de forma más literal”
• Unidades de token más pequeñas refuerzan la atención a nivel de palabra (attention) y ayudan a mejorar la ejecución precisa de instrucciones, tareas a nivel de carácter y precisión en llamadas a herramientas
• Socios como Notion, Warp y Factory reportaron menos errores en la ejecución de herramientas
• Sin embargo, además de la tokenización, también cambiaron los pesos del modelo y el post-training, por lo que no es posible aislar la causa

Prueba de adhesión a instrucciones

• Se usó el benchmark IFEval (2023, Google): se probaron 20 muestras entre 541 prompts como “responde con exactamente N palabras” o “escribe sin comas”
• Resultados
  • Por prompt en modo estricto: 4.6 → 85%, 4.7 → 90% (+5 pp)
  • Por instrucción en modo estricto: 86% → 90% (+4 pp)
  • En modo flexible no hubo diferencia
• La mejora proviene principalmente de la reducción de errores relacionados con formato
• Solo se confirmó una diferencia clara en un único prompt (change_case:english_capital)
• Como el tamaño de muestra es pequeño (+5 pp es estadísticamente incierto), se evalúa como una mejora pequeña pero consistente

Cálculo del costo por sesión en Claude Code

• Supuesto de una sesión de conversación de 80 intercambios
  • Prefijo estático: 6K tokens (CLAUDE.md 2K + definición de herramientas 4K)
  • Historial de conversación: crece 2K por turno, llegando a 160K en 80 turnos
  • Entrada/salida: 500 / 1,500 tokens por turno
  • Tasa de acierto de caché: 95%

• Costo por sesión con 4.6

  • | Ítem | Cálculo | Costo |
  • | --- | --- | --- |
  • | Primera escritura en caché | 8K × $6.25/MTok | $0.05 |
  • | Lectura de caché (79 veces) | 79 × 86K × $0.50/MTok | $3.40 |
  • | Nueva entrada | 79 × 500 × $5/MTok | $0.20 |
  • | Salida | 80 × 1,500 × $25/MTok | $3.00 |
  • | Total | | aprox. $6.65 |

• Costo por sesión con 4.7

  • CLAUDE.md: 1.445 veces → 2K → 2.9K
  • Definición de herramientas: 1.12 veces → 4K → 4.5K
  • Historial de conversación: 1.325 veces → 160K → 212K
  • Entrada del usuario: 1.325 veces → 500 → 660
  • Prefijo promedio en caché: aprox. 115K tokens
  • | Ítem | Cálculo | Costo |
  • | --- | --- | --- |
  • | Primera escritura en caché | 10K × $6.25/MTok | $0.06 |
  • | Lectura de caché (79 veces) | 79 × 115K × $0.50/MTok | $4.54 |
  • | Nueva entrada | 79 × 660 × $5/MTok | $0.26 |
  • | Salida | 80 × 1,500–1,950 × $25/MTok | $3.00–$3.90 |
  • | Total | | aprox. $7.86–$8.76 |
  • Aumento de costo de 20 a 30% por sesión, sin cambios en el precio por token
  • Para usuarios del plan Max, el final de la sesión llega más rápido dentro de la misma ventana de tiempo

Impacto en la caché de prompts

1. Debido a la separación de caché por modelo, al cambiar a 4.7 se invalida la caché existente de 4.6
   • La primera sesión comienza sin caché aplicada, con un costo mayor de prefijo
2. El volumen de caché en sí aumenta entre 1.3 y 1.45 veces, por lo que lectura y escritura suben en la misma proporción
3. Incluso con el mismo log de conversación, cambia la cantidad de tokens, lo que genera una discontinuidad frente al pasado en facturación y métricas de monitoreo

Objeciones e interpretación

• “Como la mayor parte de la entrada es lectura de caché, el impacto es mínimo”

  • Si la tasa de acierto de caché es alta, el impacto en costo puede ser pequeño, pero con vencimiento de TTL, invalidación de caché o cambio de modelo, el costo aumenta en la proporción total

• “1.35 veces no es un límite superior, sino un rango”

  • Los valores medidos reales se concentraron cerca del límite superior (1.325 veces), y algunos archivos lo superaron
  • En uso real, lo más seguro es planear con base en el límite superior

Conclusión

• En trabajos centrados en inglés y código, el uso de tokens aumenta entre 1.3 y 1.45 veces
• La adhesión a instrucciones mejora alrededor de +5 pp, una mejora pequeña pero real
• El costo por sesión sube entre 20 y 30%, con el mismo precio por token
• En consecuencia, se evalúa como una estructura en la que se paga un costo adicional para obtener mayor precisión y ejecución más detallada de instrucciones

[kaydash]

No es Claude 4.7, sino Opus 4.7.

[GN⁺]

Comentarios en Hacker News

• Asumiendo que la curva de rendimiento/costo de los LLM existe en forma logarítmica, no está claro si Opus 4.5+ representa un nuevo punto sobre esa curva, o si simplemente está en una zona donde el costo se dispara para obtener un poco más de rendimiento
  Que Anthropic esté subiendo los precios rápidamente podría ser una señal de que está reflejando un fuerte aumento en los costos operativos
  Creo que la costumbre de mostrar el eje x de los gráficos de evaluación del modelo como logaritmo del costo oculta esa realidad

  • Tomó como referencia el análisis del costo por hora de agentes de IA de Toby Ord. Su concepto de frontera de rendimiento/costo debería recibir más atención
  • Creo que ya llegó el momento de que los desarrolladores dimensionen correctamente (right-sizing) el tamaño del modelo y el nivel de esfuerzo según la tarea
    Ya terminó la época de usar siempre el mejor modelo. Se necesitan opciones para elegir distintos puntos según el trabajo
    Para tareas complejas, me parece bien usar un modelo más grande y gastar de una vez 5 horas de tokens
    Pero a mucha gente no le gustará esa complejidad de elección, y espero que en adelante aumenten los intentos de enrutamiento inteligente
  • Anthropic se está acercando a una IPO, así que tiene mucha presión para aumentar los ingresos por usuario. Al final, se está moviendo hacia una estructura de precios que refleje el costo real de operar los modelos
  • Si el modelo se implementa directamente en silicio, el costo bajará y la velocidad aumentará. Vale la pena revisar intentos como Taalas
  • Si los clientes están dispuestos a asumir un costo mayor, creo que también se podrían ofrecer modelos mucho más potentes
    Por ejemplo, así como existe un segmento que quiere opciones ultracaras como las de Apple, también podría existir un mercado de LLM de ultraalto rendimiento

• Mucha gente se enfoca en el costo de los modelos de IA, pero en realidad el tiempo que los humanos dedican a coordinar y revisar agentes de codificación con IA es mucho más caro
  $200/mes es caro para un hobby, pero desde una perspectiva de negocio es insignificante
  Lo importante es qué tan bien hace el trabajo el modelo, y a los precios actuales lo clave es la eficiencia en relación con el tiempo

  • Nuestro equipo lanzó tres productos este año con Claude. En particular, un proyecto estimado para 9 personas durante 6 meses lo terminamos con 2 personas en 2 meses
    Creo que el valor económico de la suscripción a Claude está entre 10 mil y 40 mil euros.
    Lo compraría incluso si el precio subiera 100 veces. Eso sí, si llegara a 20 mil euros/mes, evaluaría alternativas, pero por ahora la mejora de productividad es abrumadora
  • $200 casi no representan una carga para una empresa, pero son difíciles de justificar para un hobby personal
  • Mi instancia de Openclaw recibió cargos de $200 por día al usar Opus. El problema mayor es la optimización del enrutamiento. Cuando costaba $1/hora estaba bien, pero a $15/hora ya pierde competitividad

• Creo que la mejora en la calidad de los modelos eventualmente llegará a una zona de rendimientos decrecientes
  Como con las pantallas 8K vs 16K, la mayoría de los usuarios no percibe la diferencia
  Si hay un aumento de costo de 20~30%, también debería haber un aumento visible de valor en esa misma proporción

  • Por eso creo que la mayoría de la investigación se concentra en el área de codificación. La dificultad sigue aumentando y el valor económico se mantiene
    En cambio, las consultas conversacionales generales ya están saturadas, así que es difícil diferenciar modelos
  • Aunque parezca tener 99% de precisión, cuando se toman 100 mil decisiones al día, un pequeño error acumulado puede convertirse en un gran problema
  • Si aparece un modelo 4K que pueda ejecutarse de forma local, los grandes laboratorios van a sufrir. Aun así, Google probablemente resistirá gracias a sus ingresos publicitarios
  • Depende del tipo de tarea. Por ejemplo, en diseño de medicamentos, la diferencia entre 95% completado y 100% completado genera una diferencia de decenas de veces en valor
  • Para búsqueda web o resúmenes, ya se llegó al límite, pero la complejidad de la programación puede expandirse infinitamente

• El multiplicador de modelo de GitHub Copilot subió de 3 a 7.5
  Parece un intento de Microsoft por reducir pérdidas
  Véase la documentación oficial

  • Por eso recomendamos dentro de nuestra organización “nunca activen Opus 4.7”. 4.6 (3x) y 4.5 (3x) están bien, pero 4.7 (7.5x) no ofrece ninguna buena relación costo-beneficio
  • Últimamente Opus 4.6 muestra una caída en la calidad de razonamiento. Se apresura a sacar conclusiones y omite la lógica. Si no hay un gran avance, parece que se viene una fuerte degradación de calidad (en**)**

• El título del artículo lleva a confusión. El número de tokens aumentó, pero el costo por tarea puede ser distinto
  Asumo que Opus 4.7 no usa la misma ruta de razonamiento que Opus 4.6
  Habrá que esperar los resultados del Intelligence Index de Artificial Analysis

  • En benchmarks internos, Opus 4.7 fue 50% más barato y obtuvo una puntuación de rendimiento de 80% (vs 60%)
  • El título del artículo fue corregido de “Claude Opus 4.7 costs 20–30% more per session” a una versión más neutral
  • Según los resultados de un experimento comparativo de 28 tareas, 4.7 tiene un costo similar al de la versión antigua 4.6 y es aproximadamente 20% más caro que la nueva versión 4.6
  • Según mis datos personales, 4.7 tuvo un costo más alto que 4.6, y la mejora de rendimiento no estaba clara
  • También confirmé en el gráfico del anuncio oficial la base de la afirmación de “strictly better”

• Ayer, al usar Opus, estaba sorprendentemente bueno, pero hoy sigue fallando incluso en tareas simples
  Tuve que señalar el mismo problema por tercera vez, la sesión se corta seguido y ocurre demasiada compactación (compaction)
  Al final decidí volver a Sonnet

  • Esto no es un bug, sino una política para reducir cómputo. Y en adelante va a empeorar
  • Un LLM no es una personalidad. Cuando se muestrea desde una distribución de probabilidad, la probabilidad de que salgan sesiones malas es del 100%. Hay que reiniciar el contexto e intentarlo de nuevo
  • Yo también últimamente, usando Opus 4.7, veo con frecuencia resultados desastrosos. Fue amargo ver al modelo reconocer sus propios errores e intentar de nuevo

• Últimamente pienso mucho: “¿de verdad necesitamos modelos más potentes?”
  La industria está demasiado concentrada en la competencia por rendimiento y está dejando de lado la eficiencia y la sostenibilidad
  En adelante, creo que será importante ir hacia modelos de 0.5B~1B parámetros optimizados para tareas específicas

  • Yo también estaría totalmente satisfecho si pudiera correr Sonnet 4.6 en local
    Como muestra el artículo CPUs Aren’t Dead, el modelo Gemma 4 E2B de Google puede funcionar incluso en un teléfono y supera a GPT-3.5-turbo
    Según el Intelligence Index de Artificial Analysis, los modelos recientes de 2B ofrecen un rendimiento similar al de modelos de 175B de hace 3~4 años
    Gemma 4 E4B incluso llega a superar a GPT-4o
    Si esta tendencia sigue así, pronto podremos correr modelos de primer nivel incluso en laptops
  • Muchos esperaban que Sonnet 4.6 tuviera un rendimiento al nivel de Opus 4.5, pero la realidad no fue así
  • La eficiencia no da dinero. A las grandes empresas de LLM les conviene mantener caro el costo de inferencia
    La promoción del tipo “este modelo está loco” al final no es más que marketing de FOMO
  • No todo el mundo necesita una calculadora avanzada. Lo importante es elegir la herramienta al nivel necesario
  • Pero no podemos conformarnos con un “modelo flojo e impreciso”. El laboratorio que resuelva este problema tendrá una ventaja decisiva

• Los vendedores de dulces en Calcuta, India, al no poder subir los precios pese al aumento de las materias primas, respondieron reduciendo el tamaño
  Así es como funciona la adaptación psicológica de la gente

  • Pasa algo parecido en todo el mundo. El empaque de los snacks sigue igual, pero el contenido se redujo. Incluso el envase de Pringles se ha vuelto más delgado y más corto
  • A este fenómeno se le llama Shrinkflation

• Anthropic introdujo un nuevo modo xhigh en 4.7
  Como el modo max usa muchos tokens y puede provocar razonamiento excesivo, recomiendan xhigh en la mayoría de los casos
  Véase la documentación oficial

  • Agregar el nivel xhigh y empujar max más hacia el extremo da la sensación de “esto llega hasta 11”

• En código real, Opus 4.7 mostró un aumento de alrededor de 30% en tokens
  Lo importante es “qué capacidad nueva ofrece 4.7 frente a 4.6”
  Todavía es pronto para juzgar, y si aporta valor, se puede aceptar el aumento de costo

  • Un punto interesante en la discusión es que mucha gente persigue el modelo nuevo, pero solo con Sonnet 4.6 ya se puede trabajar con suficiente eficiencia
    Si se acota el alcance de la tarea, es más fácil revisar y gestionar, y se puede corregir rápido con diffs pequeños
    Si el consumo de tokens de Copilot aumenta 7 veces, más bien parecería generar una ruptura del flujo de trabajo
  • Últimamente hay muchas quejas de que 4.6 empeoró en rendimiento
  • No sé cuánto tiempo mantendrán 4.6. En empresas quizá dure algo más, pero para suscriptores individuales parece que pronto desaparecerá la posibilidad de elegir