Todos dicen que Claude Code desperdicia tokens, ¿pero cuántos exactamente? Alguien finalmente lo ha calculado.
Recientemente, el equipo de Composio realizó un interesante experimento comparativo. Usaron el mismo modelo Kimi K3 y lo ejecutaron en tres plataformas ("harness") de agentes diferentes —Claude Code, Hermes y Kimi Code—, probando exactamente las mismas 28 tareas.
Los resultados mostraron que la tasa de éxito era similar entre las tres plataformas: Kimi Code completó 22 de 28 tareas, Hermes 21 y Claude Code 20. La diferencia no es grande.
La verdadera brecha la marcó el consumo de tokens. Para la misma tarea, ejecutada en diferentes plataformas, el uso de tokens podía variar hasta 30 veces.
En términos de mediana, Kimi Code usó aproximadamente 61 mil tokens, Hermes alrededor de 67 mil, mientras que Claude Code se disparó a 340 mil, aproximadamente 6 veces más que Kimi Code.
Considerando el precio de Kimi K3 (3 dólares por millón de tokens de entrada, que suelen representar alrededor del 95% del flujo de trabajo de un agente), el costo promedio por tarea sería aproximadamente: Kimi Code 0.22 dólares, Hermes 0.28 dólares y Claude Code hasta 2 dólares. La diferencia es evidente.
La velocidad también varió. En mediana de tiempo, Hermes fue el más rápido con 179 segundos; Kimi Code tardó 297 segundos; Claude Code, 348 segundos.
Por lo tanto, el más rápido fue Hermes, y el que más ahorró tokens fue Kimi Code, y estos dos no coinciden.
El equipo de Composio llegó a una conclusión directa: si quieres reducir el costo de tu agente, primero revisa qué plataforma estás usando, en lugar de apresurarte a cambiar de modelo. Según sus datos, la plataforma por sí sola puede multiplicar el costo por 9, mientras que el rendimiento del modelo es prácticamente similar.
Sebastian Raschka, al ver estos resultados, también publicó un comentario diciendo que esto es similar a lo que observó previamente con Qwen3.6: Claude Code, con una tasa de éxito comparable, a menudo consume entre 2 y 3 veces más tokens que muchas otras plataformas.
Él planteó varias posibles razones: ¿Falta de optimización? ¿Un error? ¿O un diseño intencional (porque podría ayudar en tareas más difíciles)? Dijo que necesitaría investigarlo más a fondo.
Luego agregó una observación de su artículo del mes pasado sobre un agente de codificación local. En ese momento, analizó por qué Claude Code usa más tokens y descubrió que la diferencia está principalmente en los tokens de entrada, no en los de salida. Es decir, Claude no escribe el doble de contenido. Los registros muestran que la plataforma de Claude reintroduce repetidamente más contexto en el modelo durante múltiples interacciones, incluyendo mensajes previos, llamadas a herramientas, salidas de comandos y contenido de archivos. Por ejemplo, en una ejecución, Claude usó alrededor de 578,000 tokens de entrada, pero solo produjo unos 4,500 tokens de salida, abarcando 25 rondas. Por lo tanto, es más probable que la plataforma de Claude acumule o contabilice un historial de "prompts" más grande durante la ejecución de un agente de múltiples pasos.
Estos resultados de prueba parecen revelar una tendencia innegable: La importancia de la plataforma ("harness") ya no es menor que la del modelo en sí.
Un artículo reciente (de Writer, una empresa que desarrolla una plataforma de agentes de IA empresarial) lo demuestra sistemáticamente: mediante experimentos controlados, muestra que cambiar la capa de la plataforma es más efectivo para reducir costos que cambiar el modelo, y todos los modelos se benefician.
Concretamente, llevaron a cabo un estricto experimento de "control de variables": manteniendo fijas 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 agente inteligente de nivel de producción tradicional por su propia plataforma, Writer Harness.
Los resultados mostraron: un costo promedio reducido en un 41% por tarea (de 0.21 a 0.12 dólares), una latencia mediana reducida en un 44% (de 48 a 27 segundos), un consumo de tokens reducido en un 38% (de 14.2k a 8.8k), mientras que la calidad de finalización de la tarea se mantuvo básicamente igual (de 0.78 a 0.81, considerada sin diferencia significativa debido al tamaño de muestra). En cuanto a relación costo-beneficio, la calidad obtenida por dólar aumentó en un impresionante 82%, y el número de tareas completadas por millón de tokens pasó de 54.9 a 92.0.
Entonces, ¿después de que los modelos se convirtieron en "servicios básicos", la plataforma es el "aire acondicionado" que determina tu factura de electricidad? En otras palabras: antes se decía "el modelo es el producto", ¿ahora es "la plataforma es el producto"?
Dado que la plataforma es tan importante, ¿no deberíamos comenzar a hacer cuentas más detalladas?
Alguien señaló que es necesario agregar un ítem de "impuesto de plataforma" a los benchmarks existentes. Especialmente considerando que, una vez que las llamadas a herramientas y los reintentos entran en un bucle, este "impuesto" no crece linealmente.
En otras palabras, la competencia futura de agentes, en la primera mitad se tratará de "quién puede hacerlo", y en la segunda mitad será "quién puede hacer lo mismo gastando menos" — y el secreto para ahorrar no está en el modelo, sino en la plataforma.
¿Has tenido una experiencia similar al ejecutar un Agente? Te invitamos a discutirlo en la sección de comentarios.
Este artículo proviene del WeChat Official Account "机器之心" (ID: almosthuman2014), autor: 机器之心.
