- Al medir el límite de la API con el mismo modelo, máquina y tarea, la sobrecarga fija de la primera solicitud en Sonnet 4.5 fue de unos 32,800 tokens en Claude Code y unos 6,900 tokens en OpenCode, una diferencia de 4.7 veces; en Fable 5 se redujo a unas 3.3 veces
- La mayor parte de la brecha proviene del esquema de herramientas. Claude Code usó unos 24,000 tokens para 27 definiciones de herramientas, mientras que OpenCode usó unos 4,800 tokens para 10 herramientas; incluso con todas las herramientas desactivadas, los prompts de sistema fueron de unos 6,500 y 2,000 tokens, respectivamente
- En configuraciones reales, un archivo de instrucciones de 72 KB agrega unos 20,000 tokens por solicitud, y un servidor MCP pequeño agrega unos 1,000~1,400 tokens, por lo que solo la primera solicitud puede llegar a 75,000~90,817 tokens
- En la misma tarea de resumir un archivo, Claude Code generó entre 5.9 y 54 veces más escrituras de caché que OpenCode; al distribuir el trabajo entre dos subagentes, el uso pasó de 121,000 tokens en ejecución directa a 513,000 tokens, 4.2 veces más
- No se puede juzgar el costo total solo por la sobrecarga fija. En tareas de varios pasos, Claude Code agrupó llamadas a herramientas en paralelo y usó unos 121,000 tokens en 3 solicitudes, mientras que OpenCode usó unos 132,000 tokens en 9 llamadas seriales
Método de medición en el límite de la API
- Se colocó un proxy de logging entre Claude Code y OpenCode para registrar las solicitudes JSON exactas enviadas por el arnés y los bloques de uso devueltos por la API
- El cuerpo de la solicitud incluye bloques de sistema, esquemas de herramientas y mensajes
- El uso incluye tokens de entrada, escrituras y lecturas de caché, y tokens de salida
- El cuerpo capturado de la solicitud se usó como el contenido realmente transmitido, y el bloque de uso de la API como la base de la facturación real
- Para la comparación base se usaron Claude Code 2.1.207 y OpenCode 1.17.18, ambos fijados a
claude-sonnet-4-5a julio de 2026- Parte de la sobrecarga fija, las operaciones de caché y las tareas de varios pasos se volvieron a ejecutar con
claude-fable-5 - Se aislaron los valores predeterminados con un directorio de configuración nuevo, sin servidores MCP, configuración de usuario ni memoria, y en un espacio de trabajo vacío sin archivos de comandos
- Parte de la sobrecarga fija, las operaciones de caché y las tareas de varios pasos se volvieron a ejecutar con
- Se midieron distintas estructuras de costo con tres tareas
- T1 aisló la sobrecarga fija con
Reply with exactly: OK, ejecutándose 3 veces por arnés - T2 hizo leer y resumir un archivo preparado de antemano
- T3 realizó un proceso de escribir, ejecutar, probar y corregir sobre FizzBuzz y un script de verificación
- T1 aisló la sobrecarga fija con
- Para comparar los prompts de sistema excluyendo esquemas de herramientas, se aplicó
--tools ""a Claude Code y"tools": {"*": false}a OpenCode - Una gateway LLM local agregaba una envoltura fija de unos 6,200 tokens por solicitud, que se corrigió y excluyó de las mediciones
- Las cifras por componente se calcularon a partir del cuerpo capturado de la solicitud, que la gateway no podía cambiar
- Para convertir caracteres a tokens se usó una proporción de 4.1~4.4 caracteres por token, medida por arnés con caché fría
Esquemas de herramientas que aumentan la sobrecarga base
- En la primera solicitud del prompt T1 de 22 caracteres, Claude Code envió unos 32,800 tokens, y OpenCode unos 6,900 tokens
- El prompt de sistema de Claude Code tenía 3 bloques y 27,344 caracteres, mientras que el de OpenCode tenía 1 bloque y 9,324 caracteres
- Los 27 esquemas de herramientas de Claude Code tenían 99,778 caracteres, y las 10 herramientas de OpenCode 20,856 caracteres
- Claude Code insertó antes del prompt real un bloque
<system-reminder>de 7,997 caracteres con tipos de agentes, skills disponibles y contexto de usuario - OpenCode envió el bloque de sistema, 10 herramientas de programación y el prompt de usuario sin andamiaje adicional en el primer mensaje
- En ambos casos, las definiciones de herramientas representaron la mayor parte
- De los aproximadamente 33,000 tokens de Claude Code, unos 24,000 eran definiciones de herramientas
- De los aproximadamente 6,900 tokens de OpenCode, unos 4,800 eran definiciones de herramientas
- Las herramientas de Claude Code incluyen no solo funciones de programación, sino también capacidades de agentes en segundo plano y orquestación como
CronCreate,Monitor, la familiaTask, gestión de árboles de trabajo y notificaciones push
- Al eliminar todas las herramientas, el prompt de sistema de Claude Code fue de 26,891 caracteres, unos 6,500 tokens, y el de OpenCode de 8,811 caracteres, unos 2,000 tokens
- En ambos arneses, el prompt se reduce un poco cuando se desactivan las herramientas
- La diferencia restante proviene de instrucciones de comportamiento como tono, directrices de seguridad, reglas de gestión de tareas e información del entorno
- En Fable 5, Claude Code redujo el prompt según el modelo y la brecha bajó a unas 3.3 veces
- Las instrucciones de sistema bajaron de 27,787 caracteres en Sonnet a 10,526 en Fable
- Manteniendo las mismas 27 herramientas, el esquema también se redujo de 99,778 a 82,283 caracteres
- Las solicitudes de OpenCode fueron idénticas byte a byte en ambos modelos
El uso total cambia según el tipo de tarea
- En T2, donde se leyó y resumió un archivo, ambos arneses produjeron resultados correctos, pero con estructuras de solicitud distintas
- Claude Code usó 6 solicitudes HTTP y una entrada acumulada de unos 199,000 tokens
- OpenCode usó 4 solicitudes y unos 41,000 tokens, además de 1 llamada a Haiku para generar el título de la sesión
- La mayor parte del uso correspondió a lecturas de caché, que se cobran a una décima parte del precio de entrada
- Aunque exista descuento de caché, la escritura de caché de la primera solicitud, la lectura de caché en cada turno y la ocupación de la ventana de contexto aumentan según el tamaño del payload
- Una línea base de 33,000 tokens ocupa alrededor de una sexta parte de una ventana de 200,000 tokens incluso antes de que entre código
- En T3, una tarea de escribir, ejecutar, probar y corregir, la forma de llamar herramientas compensó la diferencia de sobrecarga base
- Claude Code agrupó 2 escrituras de archivos y 2 ejecuciones de scripts en una sola ida y vuelta de herramientas en paralelo, registrando 3 solicitudes al modelo y una entrada acumulada de unos 121,000 tokens
- OpenCode llamó una sola herramienta por turno, registrando 9 solicitudes, 1 llamada de título y una entrada acumulada de unos 132,000 tokens
- La entrada total se determina aproximadamente como la línea base por solicitud multiplicada por el número de solicitudes, más el incremento de la conversación
- A medida que avanzó la conversación, Claude Code aumentó los
<system-reminder>de 3 en el primer turno a 4 en la primera ida y vuelta de herramientas - El payload adicional por turno de OpenCode fue de unos 400~2,200 caracteres, aumentando solo con el contenido de la conversación
Tokens agregados por configuraciones reales
- Al agregar un
AGENTS.mdde 72 KB de un repositorio de producción, ambos arneses aumentaron más de 20,000 tokens por solicitud- La medición de OpenCode pasó de 13,152 a 33,336 tokens
- Claude Code pasó de 39,005 a 59,243 tokens
- Claude Code 2.1.207 ignoró
AGENTS.md; hubo que renombrarlo aCLAUDE.mdpara que lo insertara en el primer mensaje de usuario - OpenCode lee ambos nombres de archivo y los inserta en el prompt de sistema
- Si no se verifica qué nombres de archivo reconoce realmente el arnés, un archivo de instrucciones puede ser ignorado silenciosamente
- Un servidor MCP público pequeño agrega unos 1,000~1,400 tokens por solicitud y por servidor
- Cinco servidores agregaron 4,900 tokens al payload de Claude Code y 6,967 tokens a la medición de OpenCode
- El número de herramientas aumentó de 27 a 69 en Claude Code y de 10 a 52 en OpenCode
- Los servidores de producción con APIs ricas pueden enviar esquemas más grandes
- El modo print de Claude Code ignoró silenciosamente
.mcp.jsonen el alcance del proyecto si no había un--mcp-configexplícito, por lo que hay que confirmar la conexión en el límite de la API
- Los frameworks de flujo de trabajo basados en historias, como BMAD, expanden con comandos slash plantillas grandes que contienen personas, protocolos y checklists
- La plantilla de 8,405 caracteres del experimento en sí equivale a unos 2,100 tokens, pero entra en el historial de conversación y se vuelve a enviar en todas las solicitudes posteriores
- En una sesión de 9 solicitudes, la misma plantilla se incluye 9 veces, por lo que el costo aumenta como tamaño de la plantilla × número de solicitudes
- La primera solicitud en configuraciones reales fue mucho mayor que la sobrecarga base
- OpenCode usó 11 servidores MCP para email y calendario, gestión de tareas, gestión de referencias, análisis de producto, etc., junto con un archivo de instrucciones de 72 KB, registrando 179 herramientas, un esquema de 277 KB y una escritura de caché fría de 90,817 tokens
- Claude Code usó 4 servidores MCP, plugins instalados y el mismo archivo de instrucciones, registrando 118 herramientas, un payload de 311 KB y unos 75,000 tokens
- La configuración de OpenCode fue unas 12 veces mayor que su valor predeterminado de unos 7,000 tokens si se excluye la envoltura de la gateway
Costo de subagentes y razonamiento extendido
- Cuando Claude Code distribuyó la tarea en paralelo entre dos subagentes, los 121,000 tokens de la ejecución directa aumentaron a 513,000 tokens, 4.2 veces más
- Se produjeron 9 solicitudes al modelo en total entre tres tipos de solicitud: sesión principal, llamadas a subagentes, etc.
- Cada una de las 5 llamadas a subagentes hizo su propio bootstrap con un prompt de sistema de 3,554 caracteres y 24 de las 27 herramientas base
- La estructura implica que cada subagente paga el costo inicial y luego el padre vuelve a leer su historial de ejecución
- Los subagentes de OpenCode envían un perfil reducido con un prompt de sistema de 1,379 caracteres y solo 5 herramientas
- Como la ejecución a través de la gateway no terminó correctamente, no se cuantificó el uso total de subagentes en OpenCode
- Solo se comparó la diferencia de diseño observada en los payloads capturados
- La salida de razonamiento extendido se cobra al precio de salida, que es 5 veces el de entrada, y los bloques de razonamiento se incluyen en el historial de conversación y se vuelven a enviar en solicitudes posteriores
- Debido a la propia política de razonamiento de la gateway, no se pudo confirmar si la configuración de ambos arneses se aplicó realmente, por lo que no se publican cifras medidas
- Solo se mantuvo como objeto de verificación la estructura de costo en la que los bloques de razonamiento pasan a formar parte del historial
Economía y estabilidad de la caché de prompts
- Ambos arneses configuran correctamente los puntos de corte de caché. El payload se escribe una vez con TTL de 5 minutos al 1.25× del precio de entrada base y luego se lee a una décima parte del precio
- Hay tres costos que la caché no reduce
- Si hay una pausa de más de 5 minutos, hay que volver a escribir toda la pila, por lo que el costo de escritura reaparece después de interrupciones como reuniones o comidas
- Las lecturas de caché también se repiten tantas veces como solicitudes haya, por lo que los bucles seriales de herramientas y la distribución entre subagentes aumentan el costo
- La ocupación de la ventana de contexto no se ve afectada por el descuento de caché: un bootstrap de 85,000 tokens ocupa más del 40% de una ventana de 200,000 tokens, y cuando empieza la compresión también se agrega el costo de resumir
- OpenCode mantuvo un prefijo idéntico byte a byte en todas las solicitudes y ejecuciones capturadas
- En tres sesiones T1, los bytes de herramientas, sistema y mensajes fueron idénticos, y las escrituras de caché en ejecuciones repetidas fueron 0
- La sesión T3 de 9 solicitudes también mantuvo un único prefijo estable
- Claude Code crea distintos tipos de solicitudes y entradas de caché entre calentamiento exploratorio, conversación principal y llamadas a subagentes
- Incluso en el mismo espacio de trabajo, los bytes de sistema y el andamiaje del primer mensaje cambiaron entre ejecuciones
- En la misma tarea de resumen de archivo escribió 53,839 tokens de caché en 5 solicitudes y reescribió una vez a mitad de la tarea todo un prefijo de unos 43,000 tokens
- La escritura de caché de OpenCode para la misma tarea fue de 1,003 tokens
- Las grandes reescrituras intermedias de caché de Claude Code también aparecieron en experimentos repetidos
- En las dos primeras ejecuciones reescribió 43,342 y 36,899 tokens respectivamente, y en una tercera ejecución con caché recién precalentada casi no escribió
- También en Fable 5 reescribió 50,053 tokens sin lectura de caché, generando una brecha de 52 veces, similar a las 54 veces de Sonnet
- Según la temperatura de la caché, la cantidad de escritura de caché de Claude Code fue entre 5.9 y 54 veces la de OpenCode
- El precio de escritura de caché es 1.25 veces el base en el nivel de 5 minutos y 2 veces en el nivel de 1 hora
- Una sola falta de caché podría deberse a expulsión por parte de la gateway, pero se reprodujo en varias ejecuciones y la inestabilidad del prefijo también se confirmó en los bytes capturados antes de la solicitud
- Si el prefijo es grande, hay muchos tipos, las reescrituras se repiten y además se suman subagentes, el contador de uso de Claude Code puede crecer más rápido
Calidad de resultados y logs de auditoría
- Ambos arneses completaron correctamente todas las tareas evaluadas
- Los resultados del resumen de archivo fueron correctos en todos los casos
- Las tareas de varios pasos pasaron los scripts de verificación escritos por cada arnés y terminaron normalmente
- Dentro de este alcance, fue posible comparar la diferencia en costo de tokens necesaria para obtener el mismo resultado
- No se midió si, en tareas reales de ingeniería más difíciles, los agentes en segundo plano, skills y orquestación de Claude Code elevan la calidad en proporción al costo adicional
- Para juzgarlo harían falta por separado un conjunto de pruebas adecuado, suficientes ejecuciones repetidas y una evaluación de tasa de aprobación
- También se identificó desperdicio independiente de la calidad
- Reescribir a mitad de sesión un prefijo de caché byte a byte idéntico equivale a recomprar el mismo contenido a precio premium
- Si un arnés ignora silenciosamente un archivo de instrucciones, no se obtiene ningún beneficio de ese archivo
- Los 185 registros de solicitudes y respuestas capturados se registraron en una cadena de hashes SHA-256 con la biblioteca open source
@systima/aiact-audit-log- La cadena se verificó completa sin interrupciones, con resultado de integridad
VALID - Con la misma estructura se puede reconstruir el contenido enviado y recibido, y proporcionar materiales de integridad a terceros
- Es el mismo enfoque de registros estructurados que se ofrece para el logging del EU AI Act Article 12
- La cadena se verificó completa sin interrupciones, con resultado de integridad
Limitaciones de la medición y método de reproducción
- Los resultados son una instantánea de julio de 2026 con una sola máquina, dos versiones de arnés y una muestra pequeña
- T1 y T2 se ejecutaron 3 veces cada una, y cada condición de multiplicación de configuración una vez
- Para valores predeterminados y condiciones de caché se usaron Sonnet 4.5 y Fable 5; para las condiciones de multiplicación de configuración se usó un solo modelo
- Los prompts de los arneses cambian con frecuencia, por lo que el método de medición en el límite de la API será más duradero que las cifras individuales
- Hubo una gateway local en la ruta de medición
- Las cifras por componente usaron el cuerpo de la solicitud, que la gateway no podía modificar
- Las mediciones corrigieron la envoltura fija usando una línea base con caché fría, y se excluyeron las cifras de ejecuciones cálidas cuya causa no podía separarse
- Hubo casos en los que la gateway reemplazó silenciosamente el modelo por un snapshot más nuevo que el fijado, por lo que también hay que verificar en el límite qué modelo respondió realmente
- En la ruta de Fable ocurrieron reanudaciones de sesiones antiguas del servidor y ejecución de herramientas del lado del host, por lo que se excluyeron los resultados de varios pasos de Claude Code con Fable
- La convergencia de costos de T3 es una sola observación de un tipo de tarea
- En tareas donde la ejecución secuencial sea indispensable, el número de solicitudes de Claude Code y el uso total podrían volver a aumentar
- Las condiciones de eliminación de herramientas y subagentes de OpenCode devolvieron streams incorrectos en la gateway, por lo que solo se usó el tamaño de los payloads capturados
- Las cifras de configuración real corresponden a la configuración de un usuario y pueden variar en otros entornos
- El dispositivo de reproducción es un proxy HTTP de unas 200 líneas de código Node
- Reenvía solicitudes al endpoint del modelo mientras registra en disco y en la cadena de auditoría el cuerpo de la solicitud y el bloque de uso de la respuesta
- Se configura
ANTHROPIC_BASE_URLhacia el proxy, se miden los valores predeterminados con un directorio de configuración nuevo y un espacio de trabajo vacío, y luego se agregan uno por uno archivos de instrucciones, servidores MCP y flujos de trabajo - Si se usa una gateway, primero hay que medir su propia envoltura con una solicitud mínima y confirmar qué modelo responde realmente
- Al disponer de logging en el límite de la API para reconstruir exactamente qué envió un agente de producción al modelo en un momento dado, también se obtiene la contabilidad de tokens
1 comentarios
Opiniones de Hacker News
Lo que realmente quema muchísimos tokens son los subagentes. Le encargué una tarea grande a Claude Code y de inmediato lanzó 7 subagentes; se agotó el presupuesto antes de que terminara siquiera uno. Lo intenté de nuevo 5 horas después y pasó lo mismo.
Si hacía que el agente principal ejecutara la misma tarea de forma secuencial, no había ningún problema. No sé si es tan ineficiente por el costo de comunicación y coordinación, o si Anthropic intenta aumentar sus ingresos porque los usuarios de subagentes suelen estar en cuentas empresariales y pagan por token.
En cambio, si se trata de aplicar en paralelo una tarea bien planificada a varios objetivos, hay que indicar explícitamente que los subagentes bajen de nivel a un modelo menos curioso. La consistencia de los resultados también puede mejorar.
Si se ejecuta en forma secuencial, los archivos se leen más o menos una sola vez y todas las solicitudes aprovechan la misma caché de prefijo.
En un entorno así, la mejor estrategia puede ser poner primero funciones nuevas en el plan de mayor nivel, recuperar costos y luego bajarlas a planes inferiores, o patear la escalera para que a los competidores les resulte difícil alcanzarlos.
Pero en la etapa de verificación intentó lanzar 41 agentes de verificación Fable. De algún modo encuentra un atajo.
Creo que Claude Code usa tantos tokens para que Anthropic gane más dinero y empuje a los usuarios hacia suscripciones. La política de no permitir usar los derechos de suscripción en otros agentes de programación también lo respalda. Yo uso pi.
API y enterprise representan el 75–85% de los ingresos totales, las suscripciones empresariales alrededor del 10–15% y las suscripciones personales cerca del 5%.
Como en la analogía válida de PUSH_AX, esto es como una situación en la que el contratista A pide 33 mil dólares y B pide 7 mil, así que hay que preguntarse si estamos midiendo el objetivo correcto.
En consecuencia, planeo agregar al artículo trabajos más profundos, una comparación cualitativa de resultados y materiales de reproducción de entradas y salidas lo más rápido posible.
No es solo un problema de prompts de sistema grandes. Los entornos de ejecución de agentes de programación también están usando herramientas de manera más agresiva incluso para solicitudes triviales. En las pruebas, prompts como “Hey” o “commit” a veces provocaban más de 30 llamadas a herramientas.
https://quesma.com/blog/the-true-cost-of-saying-hi-to-an-ai-...
Realmente se ve una inflación de tokens, donde las tareas simples consumen cada vez más tokens.
También es culpa mía por haber escrito en las reglas que todos los cambios deben verificarse con pruebas, pero si tanto se enfatiza la I de AI, uno espera el criterio suficiente para no poner tomate en una ensalada de frutas.
Después de usar Claude durante 6 meses, hace poco cambié a Codex. Codex es más abierto, es más fácil seguir el proceso de trabajo del modelo y la experiencia de usuario del flujo de aprobaciones también es mejor. En general tiene más transparencia, y el costo de cambio fue casi cero.
No me gusta que Claude se haya vuelto más opaco desde alrededor de febrero, incluido el prompt de sistema, y 33 mil tokens parece excesivo.
Últimamente OpenAI se volvió mucho más amigable con el consumidor.
El agente pi tiene un prompt de sistema más pequeño, y el contenido completo se puede ver aquí
https://github.com/earendil-works/pi/blob/main/packages%2Fco...
cmdcada vez que se invoca el prompt de sistema invalida la cachéSi solo se invalida cuando cambia la fecha o el directorio raíz, en la práctica sería algo bastante poco frecuente
Al final, lo importante no es el tamaño bruto del prompt. Si así fuera, Pi y sus variantes deberían tener el costo más bajo. La clave es la eficiencia del prompt, y el minimalismo de prompts y la eficiencia suelen confundirse. Aun así, Claude Code parece inflado para lo que hace
Más importante que eso es la calidad de las herramientas. Las herramientas malas o con bugs aumentan mucho las llamadas de ida y vuelta, borrando cualquier ventaja que se intentaba ahorrar al inicio
Hace unos meses hice un benchmark completo de 7 agentes en 8 tareas, y en https://github.com/dirac-run/dirac están los datos y los rastreos. Como estoy directamente relacionado con uno de ellos, no puedo afirmar neutralidad, pero el material es reproducible. Como la mayoría de las tareas estaban relacionadas con refactorización, Dirac, que destaca en anclaje por hash y análisis de árboles de sintaxis abstracta, ganó por amplia diferencia
En el trabajo me obligan a usar Claude Code, pero con
--system-prompt ""se soluciona fácilmente. Ojalá también permitieran otros entornos de ejecución--system-prompt "", ¿no desaparece incluso el prompt de sistema básico para que el modelo entienda las herramientas disponibles?Cuando empecé a experimentar con modelos locales, los conecté a Claude Code y funcionó muy bien, pero era lento
Con ayuda de Claude configuré mitmproxy y capturé completo el primer prompt de sistema de Claude Code; al volver a comprobarlo, era JSON de 162 KB. Eso me llevó a empezar a experimentar con Pi, OpenCode y Hermes
/context, usa solo 23 mil tokens del contexto de 1 millón de tokens de Opus 4.8. Aparece desglosado como prompt de sistema 3.9 mil, herramientas del sistema 13.9 mil, agente definido por el usuario 235, archivo de memoria 28, funciones 4.9 mil, mensajes 8 y búfer de compresión 3 mil tokensUn prompt de sistema de 4 mil tokens equivale aproximadamente a 15–20 KB. Me gustaría pedir que suban lo capturado a Gist, pero podría contener datos sensibles, y es muy probable que los 162 KB visibles no sean solo el prompt de sistema
Lo que hice envía menos: https://maki.sh
Pero resumir conversaciones anteriores en la práctica invalida la caché de contexto, así que aunque use menos tokens, ¿no termina consumiendo tokens más caros?