Todos dicen que Claude Code gasta tokens, ¿cuánto gasta realmente? Por fin alguien ha calculado el número.
Recientemente, hubo un experimento comparativo bastante interesante del equipo de Composio. Utilizaron el mismo modelo Kimi K3, ejecútalo en tres marcos de agente diferentes (harness): Claude Code, Hermes y Kimi Código—— Se probaron un total de 28 tareas completamente idénticas.
Como resultado, la tasa de éxito de los tres harness para completar la tarea es aproximadamente la misma: Kimi Code logró 22 de 28, Hermes 21 y Claude Code 20. La diferencia no es grande.
Lo que realmente marca la diferencia es el consumo de tokens. ¡Para la misma tarea, ejecutada con diferentes harnesses, el uso de tokens puede variar hasta 30 veces!
En términos de la mediana, Kimi El código utiliza aproximadamente 61.000 tokens, Hermes alrededor de 67.000, mientras que Claude Code se dispara directamente a 340.000, casi Kimi Seis veces el código.
Presione Kimi El costo se calcula a razón de 3 dólares por millón de tokens de entrada (en los flujos de agentes, los tokens de entrada suelen representar alrededor del 95%), por lo que el costo promedio por tarea es aproximadamente: Kimi Code cuesta 0.22 dólares, Hermes 0.28 dólares, y Claude Code llega a 2 dólares. La diferencia es clara.
También difieren en velocidad. El tiempo mediano, Hermes es el más rápido, con 179 segundos; Kimi Código 297 segundos; Claude Código 348 segundos.
Por lo tanto, el más rápido es Hermes, y el que menos tokens consume es Kimi Código, ambos no coinciden.
El equipo de Composio llega a una conclusión directa: si deseas reducir el costo de los agentes, primero revisa qué harness estás utilizando, en lugar de cambiar rápidamente el modelo. Sus datos muestran que el harness solo puede diferenciar los costos hasta en 9 veces, mientras que el rendimiento de los modelos es realmente similar.
Sebastian Raschka también publicó un mensaje tras ver este resultado, diciendo que es similar a sus observaciones anteriores con Qwen3.6: Claude Code utiliza entre 2 y 3 veces más tokens que muchos otros harnesses, con tasas de éxito similares.
Propuso varias posibles razones: ¿fue poco optimizado? ¿tiene errores? ¿o fue diseñado así intencionalmente (porque podría ser útil en tareas más difíciles)? Indicó que necesita dedicar más tiempo a revisarlo detenidamente.
Luego añadió sus observaciones al escribir el artículo sobre agentes de codificación local el mes pasado. En ese momento, analizó por qué Claude Code utilizaba más tokens y descubrió que la diferencia radicaba principalmente en los tokens de entrada, no en los de salida. Es decir, Claude no escribió el doble de contenido. Los registros muestran que el harness de Claude vuelve a insertar repetidamente más contexto en el modelo durante interacciones múltiples, incluyendo mensajes anteriores, llamadas a herramientas, salidas de comandos y contenido de archivos. Por ejemplo, en una ocasión, Claude utilizó aproximadamente 578.000 tokens de entrada, pero solo generó alrededor de 4.500 tokens de salida, distribuidos en 25 rondas. Por lo tanto, la explicación más probable es que el harness de Claude acumula o incluye un historial más extenso en el extremo del prompt durante la ejecución de agentes en múltiples pasos.
These test results appear to reveal a trend that cannot be ignored: the importance of harness is now on par with the model itself.
Un reciente artículo de investigación (de Writer, una empresa que desarrolla una plataforma de agentes de IA empresarial) revela sistemáticamente esto: demuestra mediante experimentos con variables controladas que cambiar la capa de harness reduce más los costos que cambiar el modelo, y todos los modelos se benefician.
Específicamente, llevaron a cabo un experimento riguroso de «variables controladas»: manteniendo fijos 22 tareas empresariales y 6 modelos base (Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1, Palmyra X6), solo reemplazaron la capa de orquestación: sustituyendo el ciclo de agentes productivos tradicional por el Harness propio de Writer.
Los resultados del experimento muestran: una reducción promedio del 41% en el costo por tarea (de $0.21 a $0.12), una disminución del 44% en la latencia mediana (de 48 segundos a 27 segundos), y una reducción del 38% en el consumo de tokens (de 14.2k a 8.8k), mientras que la calidad de finalización de las tareas se mantuvo prácticamente constante (0.78 a 0.81, considerándose sin diferencia significativa debido al tamaño muestral pequeño). En términos de relación calidad-costo, el aumento en la calidad por dólar gastado alcanzó un 82%, y el número de tareas completadas por millón de tokens aumentó de 54.9 a 92.0.
Entonces, después de que el modelo se convirtiera en "agua, electricidad y gas", ¿es harness el acondicionador de aire que determina tu factura de electricidad? En otras palabras: antes decían "el modelo es el producto", ¿ahora es "harness es el producto"?
Since harness is so important, shouldn't the subsequent accounting be more detailed?
Alguien señaló que es necesario incorporar el "impuesto harness" a los benchmarks existentes. Especialmente teniendo en cuenta que, una vez que las llamadas a herramientas y los reintentos entran en un bucle, este impuesto no crece linealmente.
En otras palabras, en la competencia de agentes del futuro, la primera mitad se trata de “si se puede hacer”, y la segunda mitad será sobre “quién lo hace con menos gastos” — y el secreto para ahorrar no está en el modelo, sino en el harness.
¿Has tenido una experiencia similar mientras ejecutabas el Agent? ¡Bienvenido a discutirlo en los comentarios!
Este artículo proviene del canal de WeChat "Machine Heart" (ID: almosthuman2014), autor: Machine Heart