que trabajar con IA en producción es bastante caro. Todos sabemos esto y sabemos que la mayoría de los proveedores están trabajando muy duro para descubrir cómo hacer que los agentes sean más baratos.
Es por eso que pensé que era una buena idea repasar algunos principios de diseño a tener en cuenta al construir, que pueden ayudarlo a comprender dónde puede obtener algunos ahorros.
Analizaremos cómo funciona el almacenamiento en caché rápido y por qué es una ganancia rápida, el almacenamiento en caché semántico, las herramientas de carga diferida y los MCP, el enrutamiento y la conexión en cascada, la delegación a subagentes y un poco sobre cómo mantener limpio el contexto.
Incluyo gráficos interactivos a lo largo de este artículo, que le ayudan a visualizar los ahorros de costos que cada principio puede brindarle en función de la cantidad de tokens que esté utilizando.
Sí, obviamente me mantendré sincero en todo momento, cada ahorro conlleva compensaciones.
Los agentes se vuelven caros a medida que crece el contexto
Su primer agente podría enviarse con un mensaje de sistema de 500 tokens y dos herramientas, pero una vez que crece, esos números aumentan rápidamente.
Solo para ilustrar, el mensaje del sistema Claude filtrado ejecutó alrededor de 24,000 tokens, el GPT-5 alrededor de 15,000. La gente se ha quejado de que un simple "hola" en Claude Code con una carpeta vacía consumía aproximadamente 31.000 tokens. Los usuarios de OpenClaw han informado que se enviaron más de 150.000 tokens de entrada a Gemini 3.1 Pro para 29 tokens de salida en el primer turno.
Agregue herramientas y servidores MCP y los números se vuelven realmente ridículos. Las definiciones de herramientas por sí solas pueden llegar a decenas de miles de tokens. Evite limpiar los resultados de las herramientas y las conversaciones antiguas y también pagará por esa basura en cada turno.
Sin optimización, 100 mensajes al día con 166.000 tokens de entrada cuestan alrededor de $996 al mes en Gemini 3.1 Pro y aproximadamente $2,490 en Claude Opus 4.6.
Existen trucos para mantener estos costos bajos, aunque muchas configuraciones de producción no los usan correctamente, así que repasémoslos todos en detalle.
Cuatro principios de diseño a tener en cuenta
En este artículo analizaremos cuatro principios diferentes con cuatro calculadoras interactivas diferentes.
Primero, veremos cómo reutilizar tokens cuando sea posible, analizando el almacenamiento en caché rápido y el almacenamiento en caché semántico. Luego veremos cómo minimizar los tokens estables y siempre agregados, como la memoria y las definiciones de herramientas.
También se analizará cómo pasar a modelos más pequeños o escalar a un modelo más grande, analizando los riesgos de calidad y los ahorros de los mismos.
La última sección hablará sobre mantener limpio el contexto por razones económicas y de rendimiento, mientras menciona brevemente la compactación.
Reutilizar tokens cuando sea posible
El costo del LLM no proviene simplemente de llamar al modelo con demasiada frecuencia. También proviene de pagar repetidamente para procesar los mismos tokens una y otra vez.
Entonces, en esta sección cubriremos el almacenamiento en caché K/V, el mecanismo del almacenamiento en caché de avisos y el almacenamiento en caché semántico, que son dos cosas muy diferentes. Repasaremos qué son, qué hacen y qué puedes salvar.
El almacenamiento en caché rápido es una ganancia rápida para mensajes largos del sistema, mientras que el almacenamiento en caché semántico requiere un poco más de trabajo y conlleva un poco más de riesgo.
Almacenamiento en caché K/V y almacenamiento en caché de prefijos
Antes de que un modelo pueda generar algo, primero debe procesar el mensaje. Este paso se llama prellenado. Se calculan los costos de precarga, lo que significa latencia y dinero. Entonces, para ser eficientes, no deberíamos seguir reprocesando el mismo contenido.
Cuando se utiliza un modelo de lenguaje grande, el mensaje primero se tokeniza, luego esos tokens se convierten en vectores y luego, dentro de cada capa de atención, esos vectores se proyectan en tensores K/V.
El motor de inferencia tiene que almacenar en caché los tensores K/V durante la generación; de lo contrario, las matemáticas no funcionan a una velocidad razonable. Una vez que ha terminado, tira ese caché.
Pero en lugar de tirar el caché cuando finaliza la respuesta, podemos almacenarlo y etiquetarlo de manera que nos permita encontrarlo nuevamente.
La próxima vez que llegue una solicitud, comprobaremos si esa misma parte del mensaje coincide con algo para lo que ya tenemos tensores. En caso afirmativo, cargamos esos tensores y omitimos el reprocesamiento.
Para tener una idea de por qué esto es importante desde el punto de vista económico: digamos que se necesita un segundo para procesar 2000 tokens y que el sistema le indica 10 000 tokens.
Eso supone un ahorro de 5 segundos en cada llamada de LLM, simplemente al no volver a calcular el mismo inicio del mensaje a través del modelo una y otra vez (aunque el rendimiento de precompletar varía mucho según la configuración).
Es importante tener en cuenta que debemos hacer coincidir el texto exactamente con el caché K/V almacenado.
Si los tokens cambian, ya no tenemos tensores K/V precalculados para esa parte exacta del mensaje, por lo que debe procesarse nuevamente. Aquí es donde la gente sigue tropezando: se agrega un nuevo espacio, se reordena la definición de una herramienta, se coloca una marca de tiempo en el lugar equivocado.
Por lo tanto, almacenar el caché tiene un valor real en términos de acelerar la solicitud y, a su vez, abaratarla.
Tenga en cuenta que almacenar estos tensores no es gratuito. K/V en caché ocupa memoria en el lado de servicio.
Ahora, no tenemos que construir esto nosotros mismos, esto fue solo para pensar en la mecánica. Existen marcos que ayudan con esto y los proveedores de API tienen sus propias reglas de almacenamiento en caché, y analizaremos ambas.
Almacenamiento en caché de prefijos para inferencia autohospedada
Si aloja un modelo de código abierto, lo ideal sería utilizar un marco de servicio LLM, como vLLM. Aunque existen otros marcos que ayudarán con la capa de almacenamiento en caché, vLLM tiene una función complementaria que podemos ejecutar.
Para ayudar con esto, vLLM divide el mensaje en bloques, aplica un hash a cada bloque en función de sus tokens (más los tokens anteriores) y almacena los tensores K/V contra esos hashes.
Como la mayoría de las configuraciones, la parte estática que debe almacenarse en caché debe ir en la primera parte del mensaje.
Para habilitar el almacenamiento en caché en vLLM use la bandera –enable-prefix-caching
Otras banderas te permiten ajustar –block-size y luego creo que te permite establecer explícitamente el tamaño de caché KV por GPU con algo como –kv-cache-memory-bytes
Los tamaños de bloque significan tokens por bloque. Si el tamaño del bloque es 16, entonces tienes 16 tokens por bloque antes de que se corte y comience otro.
Cuanta más memoria le des, más tiempo podrá conservar los bloques almacenados en caché. Pero si tiene muchas solicitudes largas diferentes al mismo tiempo, esa memoria se llena más rápido, por lo que los bloques antiguos se eliminan más rápido.
Existen otras soluciones, pero ya entiendes la idea. Es la misma mecánica de la que hablamos en el apartado anterior.
También puede consultar SGLang y RadixAttention para el almacenamiento en caché de prefijos, así como LMCache que debería conectarse a los motores de servicio.
Sin embargo, la mayoría de las personas usan los proveedores de API y tienen sus propias políticas sobre cómo usar el almacenamiento en caché rápido, así que repasémoslas.
Almacenamiento en caché rápido a través de proveedores de API
Al utilizar los proveedores de API, debe asegurarse de estructurar sus indicaciones para que lleguen al caché. Hay cosas que debes seguir para que esto se haga correctamente.
Usaré OpenAI primero aquí como ejemplo.
Para OpenAI, son explícitos; para almacenar en caché parte del mensaje, requieren una coincidencia exacta de prefijo. Es decir, la misma entrada estática al inicio del mensaje.
Esto significa que siempre coloca primero las instrucciones, los ejemplos y las herramientas estables, y luego el contenido variable.
También puede enviar una clave de caché rápida que puede ayudar a enrutar solicitudes similares juntas y mejorar las tasas de aciertos de caché.
También hay más detalles sobre esto. El almacenamiento en caché se habilita automáticamente para solicitudes de 1024 tokens o más, pero utilizan los primeros 256 tokens para enrutar las solicitudes de regreso al mismo caché. Entonces, esa parte estática del mensaje debe tener más de 256 tokens.
Para Anthropic tienes que habilitar el almacenamiento en caché con el parámetro cache-control.
Vale la pena mencionar también que normalmente los desalojos (TTL) ocurren entre 5 y 10 minutos de inactividad, pero pueden extenderse. Es lo mismo para Anthropic, pero puedes extenderlo a una hora (pero te costaría más al doble).
Anteriormente hablé del tiempo que ahorras y, si eres autohospedador, esto también ahorra dinero. Con los proveedores de API, los ahorros se manifiestan como tokens de entrada almacenados en caché más baratos.
Con OpenAI, la entrada en caché tiene hasta un 90% de descuento sobre la entrada base.
Anthropic le ofrece el mismo descuento en las entradas almacenadas en caché, pero también paga por almacenar ese caché. Entonces, si no lo usas correctamente, Anthropic será más caro.
Sin embargo, en general, si el 90% de su mensaje es estático, puede ahorrar hasta un 80% en llamadas en caliente.
Decidí crear un gráfico interactivo para esto con Claude aquí, para que puedas jugar con él.
Por lo tanto, el almacenamiento en caché de avisos es una buena ventaja para todos si utiliza avisos del sistema más largos que permanecen iguales y es algo a considerar para ahorrar en tokens.
Pasemos al almacenamiento en caché semántico, que es algo completamente distinto.
Almacenamiento en caché semántico
El almacenamiento en caché semántico coincide con el significado, es decir, si es una solicitud lo suficientemente similar, devuelve el resultado almacenado en caché. Aunque parezca bastante fácil, existen claros obstáculos a los que hay que prestar atención.
Para hacer coincidir textos semánticamente, utilizamos incrustaciones. Puede investigar un poco aquí si la palabra es nueva para usted. Escribí sobre ello hace unos años.
En esencia, las incrustaciones son vectores que podemos comparar entre sí mediante la similitud del coseno. Si la similitud es alta, el significado debería ser similar, aunque depende del modelo.
Lo que propone el almacenamiento en caché semántico es hacer coincidir solicitudes similares con respuestas que ya existen. Preguntando "¿Cuál es la capital de Francia?" y "Rápido, dame la capital de Francia" deberían conducir a la misma respuesta.
No es necesario utilizar un LLM para responder lo mismo una y otra vez.
Esto funciona bien si muchas personas hacen preguntas genéricas casi idénticas y los datos no se vuelven obsoletos demasiado rápido.
Entonces, ¿por qué no hacerlo en cada caso? Hay un montón de trampas aquí.
Justo en la parte superior de mi cabeza, es necesario considerar qué umbral usar para la similitud, cuánto tiempo la respuesta debe permanecer válida, qué sucede en las preguntas de varios turnos, qué se almacena realmente, si también se debe implementar un enrutador, cómo separar a los usuarios y qué sucede si se almacena en caché la respuesta incorrecta.
También debe considerar (Tiempo de vida – TTL), como cuándo la información se vuelve obsoleta y para qué preguntas.
Entonces, aunque la mecánica es bastante simple, aún necesita etiquetas y filtros de metadatos, como usuario, espacio de trabajo, versión del corpus, persona, alcance de sesión/usuario, TTL inteligente y alguna regla para "¿es suficiente el retorno?"
Esto luego se convierte en una especie de proyecto.
Entonces, si quieres hacerlo, quizás uses el índice semántico para encontrar una pregunta anterior. Diferentes preguntas pueden apuntar a la misma respuesta almacenada, lo que significa menos explosión de almacenamiento. Sea inteligente con el TTL según el uso; si algo se reutiliza con frecuencia, consérvelo por más tiempo; de lo contrario, elimínelo.
También te sugiero que lo hagas después de que veas repeticiones en los registros en lugar de al principio. Puede ser que el caso de uso simplemente no sea bueno para ello.
En cuanto a cómo hacerlo, muchas bases de datos pueden hacerlo por usted. Pero también hay bibliotecas como semanticcache, fast-cache, GPTCache, vCache, Upstash semantic-cache, Redis + LangCache, que ayudan con la plomería.
Obviamente, aquí se pueden hacer ahorros. Redis afirma tener hasta un 68,8% menos de llamadas API y una mejora de la latencia entre un 40% y un 50%, aunque tenga en cuenta que esto es un poco de marketing, ya que aquí utilizan casos de uso claros de preguntas y respuestas.
Entonces depende completamente de tu configuración. Si tiene un agente de preguntas y respuestas con muchas llamadas redundantes, puede ahorrar más. Si tienes un robot de codificación con llamadas únicas, ahorrarás menos.
El almacenamiento en caché de mensajes funciona bien cuando la pregunta cambiante se encuentra dentro de un mensaje estático grande. El almacenamiento en caché semántico funciona bien cuando la gente sigue preguntando lo mismo con diferentes palabras.
Puede jugar con esta herramienta interactiva para ver los ahorros de costos con ambos.
Antes de continuar con esta sección, solo quisiera señalar que también se pueden lograr muchos ahorros con el almacenamiento en caché estándar.
Recuerde almacenar en caché los costosos elementos deterministas, como los resultados de las consultas SQL, los resultados de las herramientas y los resultados de la recuperación. Nunca ejecute esto más veces de las necesarias.
Hago esto para una de mis herramientas. Recopila datos de palabras clave para resumirlos y luego los almacena en caché hasta que esos datos estén obsoletos. Si está obsoleto, lo vuelve a ejecutar cuando se llega a esa ruta.
Por lo tanto, el almacenamiento en caché semántico es una idea interesante y podría ahorrarle tokens para ciertos casos de uso, pero se necesita ingeniería para hacerlo bien.
No precargue tokens inactivos
Esta parte trata sobre lo que sucede cuando el indicador del sistema comienza a crecer debido a cosas como herramientas voluminosas o memoria en crecimiento.
Para los agentes más pequeños, esto no es realmente un problema, pero si trabaja con especificaciones de agentes que siguen creciendo, hay formas de reducirlas y obtener información a pedido (o al menos intentarlo).
Mantenga el contexto reducido y obtenga detalles bajo demanda
Una vez que el mensaje de su agente crece más allá de cierto punto, puede ser bueno mantener la capa siempre cargada lo más pequeña y estable posible, y mantener separados los detalles en crecimiento.
Esto es importante porque una vez que estas capas comienzan a crecer, como cuando carga unos cientos de herramientas o envía descripciones completas del servidor MCP que siguen cambiando, se vuelve ruidoso.
Evidentemente, el problema no es sólo el coste, sino también el rendimiento. Y si una de estas capas sigue cambiando, el almacenamiento en caché rápido se vuelve mucho más difícil de lograr correctamente.
Entonces, la idea es mantener la capa superior lo más compacta y estable posible. La capa superior debería ayudar al modelo a comprender dónde está y hacia dónde ir a continuación, pero no es necesario que lleve todo el mundo al frente.
Si ha revisado el código fuente de Claude Code, habrá visto que usan algo como esto para su sistema de memoria.
Tienen un archivo de índice siempre cargado que no debería exceder las 200 líneas, con archivos de temas detallados en otros lugares. Aunque lo que hace el agente en la práctica versus lo que quiere el sistema es un tema para otro momento.
También puede ver la misma idea aparecer en otros lugares, como en la configuración de herramientas avanzadas de Claude, la configuración en capas de Claude Skills y los intentos de cargar de forma diferida las herramientas MCP en lugar de volcar cada definición de servidor en el mensaje desde el principio.
Dónde se hace esto y si funciona
La idea es buena. Cuando el contexto crece, a un LLM le resulta más difícil elegir la acción correcta. Pero este espacio aún es temprano, por lo que analizaremos una herramienta como ejemplo para ver cómo puede funcionar.
Hace unos meses, Anthropic lanzó algo llamado búsqueda de herramientas avanzada. Esto entra en el espacio de cómo mantener el contexto delgado y al mismo tiempo darle al modelo acceso a cientos de herramientas.
Anthropic dice que han visto entre 55.000 y 134.000 tokens de definiciones de herramientas antes de la optimización, y que la selección incorrecta de herramientas es un modo de falla común cuando el contexto crece tanto.
Entonces, una herramienta de búsqueda optimizaría el contexto haciendo que el LLM la use para encontrar herramientas, en lugar de definirlas todas por adelantado.
tools=[ { "type": "tool_search_tool_bm25_20251119", "name": "tool_search" }, { "name": "search_contacts", "description": "Buscar un contacto por nombre o correo electrónico.", "input_schema": { "type": "object", "properties": { "query": {"type": "string"} }, "required": ["query"] } }, { "name": "send_email", "description": "Enviar un correo electrónico a uno o más destinatarios.", "input_schema": { "type": "object", "properties": { "to": {"type": "string"}, "subject": {"type": "string"}, "body": {"type": "string"} }, "required": ["to", "subject", "body"] }, "defer_loading": True } ]
Lo que ves arriba es que definimos una herramienta llamada tool_search. Puede elegir una de las opciones listas para usar, BM25 o Regex, o crear la suya propia. Luego ponemos una herramienta como ejemplo.
Sin embargo, sólo harías esto si tuvieras más de 10 herramientas.
Anthropic hace la búsqueda por usted, por lo que no ve cómo agrega este esquema de herramienta en el indicador del sistema, ni ve cómo se realiza la búsqueda bajo el capó.
Dicen que una vez que hay una coincidencia de herramienta, su definición se agrega en línea como un bloque de referencia de herramienta en la conversación del LLM.
La idea es clara: un contexto inicial más pequeño, pero aún así estás agregando un paso de búsqueda adicional. La gente también ha probado esta herramienta con resultados algo mediocres, pero eso fue con 4000 herramientas, por lo que hay más espacio para realizar pruebas.
También depende de nosotros definir las herramientas lo suficientemente bien como para poder buscarlas. Pero resulta más difícil depurar lo que sucede cuando no se puede ver el paso intermedio.
Esta idea también aparece en otros lugares, pero la gente generalmente la llama simplemente buena ingeniería de IA. No exponga al agente a un contexto enorme y desordenado. En su lugar, déle una forma de limitar las cosas y solo entonces déjelo inspeccionar o cargar la herramienta cuando sea necesario.
En esta parte, también se pueden hacer grandes ahorros, aunque depende de cuántos tokens envíe en primer lugar.
Creamos esta calculadora adicional que compara la búsqueda de herramientas y el almacenamiento en caché de mensajes.
Lo que vemos es que tanto el almacenamiento en caché rápido como el contexto de carga diferida le brindan ahorros, pero juntos no representan un gran cambio. Sin embargo, la búsqueda de herramientas como esta no se trata solo de ahorrar, ya que ayuda a mantener el contexto limpio en cuanto al rendimiento.
Pero si solo busca ahorros, la mayor ganancia es elegir al menos uno.
Utilice modelos baratos para trabajos baratos
Esta sección trata sobre el enrutamiento de mensajes a diferentes modelos, además del uso de subagentes con modelos más baratos para ciertas tareas, y cómo esto puede disminuir los costos simbólicos pero también el riesgo de calidad.
Este espacio es interesante porque la mayoría de la gente sostiene que el 60% o más de las preguntas entrantes son tareas fáciles y, por lo tanto, no necesitan el modelo más sólido, especialmente uno pensante.
ChatGPT hace esto utilizando señales como el tipo de conversación, la complejidad, las necesidades de herramientas y la intención explícita (“pensar mucho”). Claude utiliza delegación basada en descripciones y subagentes integrados como Explore.
La idea es sencilla de entender, pero poder hacerlo bien sin arriesgar demasiado la calidad es la parte difícil.
Entonces, repasemos los enfoques de enrutamiento predictivo y de verificación de salida, como cascadas y subagentes, para que pueda tener una idea de lo que puede probar por su cuenta.
Los ahorros que se pueden lograr aquí son muy reales. Creé otro gráfico interactivo para esta parte que puedes encontrar aquí. Tenga en cuenta que está codificado por vibraciones, por lo que es más bien una especie de verificación de dos veces por favor.
Ruta a modelos según la dificultad de la tarea.
El enrutamiento a nivel de solicitud significa intentar estimar la dificultad y la intención antes de ver cualquier resultado. Las ventajas son altas, pero una mala elección puede envenenar toda la sesión, por lo que hay que tener en cuenta algunos inconvenientes de calidad.
Para hacer esto, necesita algún tipo de modelo de enrutador que decida dónde enrutar la solicitud.
No sabemos exactamente qué utiliza OpenAI como señales para enrutar a diferentes modelos, pero no sé ustedes, con frecuencia siento que me están delegando a un modelo menos competente y eso puede ser exasperante.
Sin embargo, todavía hay formas de recopilar información, observando la comunidad de código abierto. Podemos mirar RouteLLM de LMSYS, el grupo de Berkeley detrás de Chatbot Arena. Esta solución aprende de datos de preferencias reales de Chatbot Arena.
RouteLLM utiliza incrustaciones estándar y luego un pequeño enrutador, por lo que alojarlo no debería ser tan costoso.
No he probado RouteLLM yo mismo, pero informan grandes reducciones de costos manteniendo la mayor parte del rendimiento de GPT-4.
Sin embargo, investigué el artículo de LLMRouterBench, que prácticamente decía que muchos enrutadores aprendidos apenas superan líneas de base simples, como el enrutamiento heurístico/por palabras clave, la incorporación del vecino más cercano o el enrutamiento estilo kNN.
Esto significa que es posible que los enrutadores sofisticados que existen no le brinden mucho impulso en comparación con el uso de algo simple.
En cuanto a usar un LLM más grande como enrutador, como Haiku, eso simplemente consumirá sus ahorros, por lo que parece inútil. Un clasificador pequeño y ajustado conlleva costos de alojamiento, y un enrutador hecho a mano, como el ejemplo anterior, aún es frágil.
La gente no ha abandonado el enrutamiento debido a esto, pero todavía está jugueteando con ello, por lo que no es un fracaso en términos de ahorro si la calidad de las respuestas no puede mantener el ritmo.
Ahora, también hay soluciones listas para usar en este espacio, como OpenRouter Auto y Switchpoint. Sin embargo, no hay nada público en sus componentes internos de enrutamiento ni en los números de precisión públicos de la forma que yo quería.
Pero para esta sección, consulte también la calculadora que hicimos para LLMRouter, heurística, clasificador autohospedado, LLM-as-router, RouteLLM, OpenRouter Auto.
En cuanto a la calidad y cómo funciona para proyectos del mundo real, no puedo decirlo antes de hacer mejores pruebas por mi cuenta, por lo que este espacio realmente merece su propio artículo en el futuro.
También deberíamos cubrir brevemente la cascada y luego los subagentes antes de continuar.
Comience con barato y aplique cascada con baja confianza
En lugar de adivinar a partir del mensaje si una solicitud es “fácil” o “difícil”, también podemos dejar que el modelo barato lo intente primero y luego decidir si conservar esa respuesta o escalarla.
El artículo “Cascadas especulativas” de Google enmarca esta compensación: utilice primero modelos más pequeños por razones de costo y velocidad, y opte por modelos más grandes sólo cuando sea necesario.
Para hacer esto, primero genere el modelo barato y luego use un verificador liviano que analice cosas como logprobs/probabilidades de tokens, entropía o incertidumbre de estilo de margen y/o alineación semántica.
Esta idea es bastante atractiva, ya que la dificultad inmediata suele ser difícil de predecir y la mayoría de los enrutadores no funcionan a la perfección. Además, la calidad es más fácil de juzgar una vez que se tiene una respuesta.
Además, solo tiene sentido si cree que la mayoría de las preguntas se pueden responder con un modelo más simple, ya que debe pagar dos llamadas para las que se derivan.
Pero de las personas que implementan esto, escuché que es una opción atractiva ya que la latencia de validación entre llamadas puede permanecer por debajo de 20 ms.
Investigué algunas implementaciones de código abierto como CascadeFlow, que afirma un ahorro del 69 % y una retención de calidad del 96 % en comparación con GPT-5. Pero es bueno notar que las indicaciones que probaron tenían verdades verificables, como respuestas matemáticas y de opción múltiple.
Una cuestión importante a considerar es que los modelos pequeños a menudo son “seguramente equivocados”, por lo que podría tener sentido comenzar con umbrales conservadores y escalarlos con mayor frecuencia. Eso inevitablemente aumentará los costos.
También agregué Cascade (barato primero) en el gráfico interactivo, para que pueda comparar los ahorros con las otras opciones. De ser cierto, puede reducir los costos en un 50% usando esta técnica, es decir, si necesita modelos más grandes para ciertas solicitudes.
Delegar trabajo a subagentes
Los subagentes consisten en delegar trabajo a agentes aislados. A veces utilizan modelos más pequeños, por lo que podemos decir que también es una forma de enrutamiento. Los ahorros no son tan grandes aquí, pero vale la pena mencionarlo.
Delegar en subagentes no se trata sólo de costos. También se trata de mantener limpio el contexto para que cada agente pueda concentrarse plenamente en la tarea que debe completar.
Anthropic envía Claude Code con subagentes incorporados, como muchos han visto. El subagente Explore es explícitamente un trabajador Haiku para la búsqueda y exploración de la base de código. Entonces, el principio de diseño está ahí: utilizar modelos más pequeños para tareas más económicas.
La sesión principal de Claude también delega mediante la coincidencia de descripciones, pero no lo vemos. Simplemente obtenemos un costo agregado más barato.
Pero debido a que el orquestador a menudo permanece al tanto de la planificación, la síntesis y los reintentos, no se ahorra tanto como vimos con el enrutamiento.
Puede mirar los gráficos que creamos anteriormente y ver que los subagentes pueden reducir alrededor del 11% de la opción "sin ruta" según nuestros cálculos, por lo que no es lo principal si solo busca reducir costos.
Mi próximo artículo profundizará en los subagentes, pero más como una forma de delegar el trabajo y aislar tareas cuando se trabaja con agentes profundos.
Repasemos la última sección antes de terminar.
Mantenga limpio su contexto
Una buena ingeniería de contexto suele tener que ver con el rendimiento, pero también puede tener que ver con la rentabilidad. Entonces, repasemos la compactación del contexto y hablemos sobre cómo mantener el contexto limpio puede ahorrar tokens.
El problema es que los agentes siguen acumulando basura: resultados de herramientas, registros, observaciones repetidas, planes antiguos, intentos obsoletos y estados duplicados.
Esto es especialmente cierto para las personas que crean agentes por primera vez, donde siguen volcando los resultados en el estado de trabajo para el agente principal.
Mal contexto activo [reglas del sistema] [reglas del proyecto] [tarea del usuario] salida grep: 2000 líneas lectura de archivos: 900 líneas registros de prueba: 1300 líneas registros de reintentos lecturas duplicadas antiguo razonamiento sin salida más registros más registros más registros
Naturalmente, yo también he hecho esto, especialmente con un agente de draft, para ver primero “cómo funciona”.
Pero también he visto gente quejarse de la acumulación del contexto de OpenClaw, por lo que sucede en todas partes. La gente también se queja de esto en Claude Code, porque en general, es más fácil simplemente agregarle cosas que trabajar para limpiarlo.
Hablemos brevemente de esto sin entrar demasiado en el aspecto del rendimiento, que es también el motivo por el que deberías hacerlo.
Lo difícil es construir un oleoducto estatal.
Este es un problema de dos niveles. No sólo estás “comprimiendo el chat”, sino que también necesitas mantener las cosas limpias a medida que las agregas al estado de funcionamiento, y esto se convierte en un tedioso trabajo de ingeniería.
Primero, para mantener limpio el contexto, no queremos que este tipo de resultado comience a devorar el contexto.
Mal estado: el agente funciona → vuelca la salida de la herramienta en contexto → lee archivos → vuelca archivos en contexto → ejecuta pruebas → vuelca registros en contexto → reintenta → mantiene todo
Entonces, el verdadero trabajo es primero preservar el estado correcto mientras se eliminan los gases de escape a medida que avanza.
Los resultados sin procesar como este pueden archivarse y solo lo que se necesita pasa al contexto activo. En general, el enemigo aquí probablemente sea el exceso de salida de herramientas, por lo que el trabajo es hacer que las herramientas sean menos ruidosas de forma predeterminada.
Buen contexto activo [reglas del sistema] [reglas del proyecto] [tarea de usuario] [estado de trabajo actual] Mantener: + el flujo de autenticación se encuentra en auth.ts + session.ts + el error solo ocurre en la ruta de actualización + prueba fallida: session_refresh_keeps_user + probablemente se sobrescribe durante la actualización + archivos en el alcance: auth.ts, session.ts, auth.test.ts Eliminación: – resultados grep sin procesar – registros de prueba completos – volcados de archivos duplicados – reintentos sin salida
También creo que ciertas partes del contexto pueden tener un ciclo de vida o una caducidad determinada.
Luego, una vez que llegues al punto en el que necesites comprimirlo, será más fácil saber qué es útil para el LLM.
Si hacemos una pequeña lectura antrópica sobre tareas de largo plazo, notan que es necesario encontrar una manera de preservar las decisiones arquitectónicas, los errores no resueltos y los detalles de implementación para la compresión una vez que también se llega a ese punto.
Para la compresión autónoma de LangChain, hacen que el agente decida cuándo compactar, en lugar de hacerlo solo después de que el contexto ya esté inflado, como creo que es el caso de Anthropic.
Es interesante que los equipos también estén empezando a evaluar la compresión como un problema del sistema, con puntos de referencia y políticas específicas de cada agente, no como un truco de resumen genérico.
También podemos consultar un artículo reciente aquí para tener una idea de los resultados que podemos obtener. Este de Jia et al. argumentó que con una compresión de 6x, se obtuvo una reducción del presupuesto simbólico de entre un 51,8% y un 71,3%, mientras que se logró una mejora de entre un 5,0% y un 9,2% en las tasas de resolución de problemas en SWE-bench Verified.
Por tanto, no se trata sólo de costes, sino también de rendimiento en general.
En cuanto a los costos, obviamente hay mucho trabajo para construir un buen contexto en sí mismo, pero eliminar la basura probablemente pueda limpiar entre el 30% y el 70% del contexto, lo que luego ahorra la misma cantidad en dólares.
A modo de ejemplo, para una ventana de contexto de 10k, si limpia entre un 30% y un 50% en ejecuciones de 100k, podría ahorrar hasta $1500. En una ventana de contexto de 40k, ese número sube a $6000.
También hicimos un cálculo para esto aquí para que puedas visualizarlo. Es bueno tener en cuenta que los agentes compresores que se utilizan en modelos baratos y muy pequeños pueden resultar más caros.
Sin embargo, lo bueno de intentar mantener el contexto limpio es que no se sacrifica la calidad, como puede suceder con el almacenamiento en caché semántico o el enrutamiento, por lo que si se hace bien, es una clara ganancia.
La cuestión es obviamente el trabajo para hacerlo.
Completando la conversación
Este es un artículo muy extenso que presenta cuatro formas diferentes de reducir los costos simbólicos al crear agentes.
Depende en gran medida de su caso de uso, use el almacenamiento en caché de mensajes cuando trabaje con mensajes de sistema grandes que permanecen sin cambios a medida que realiza un bucle de llamadas de LLM, use el almacenamiento en caché semántico si está tratando con un robot de preguntas y respuestas genérico que necesita ser económico.
Pruebe el enrutamiento si necesita poder responder preguntas fáciles y difíciles, y si quiere asegurarse de no enviar tokens innecesarios, mantenga el contexto lo más limpio posible.
Puede que valga la pena en el futuro hacer un artículo más breve y más centrado en la economía para centrarse en ciertas configuraciones.
Sin embargo, espero que haya sido informativo, conéctese conmigo en LinkedIn, Medium o a través de mi sitio web, si desea trabajar juntos en agentes o simplemente desea leer más de lo mismo.