Reducir los costos de tokens del agente: caché, enrutamiento e higiene del contexto.

Un agente inicial suele comenzar con un prompt del sistema de 500 tokens y dos herramientas, y ambos números tienden a aumentar rápidamente. Se dice que el prompt del sistema Claude que se filtró tenía unos 24,000 tokens de longitud. Los usuarios de OpenClaw han informado que en la primera sola interacción se enviaron más de 150,000 tokens de entrada a Gemini 3.1 Pro, para obtener una respuesta de 29 tokens. Si no se optimiza, un agente que procesa 100 mensajes al día con 166,000 tokens de entrada cada uno cuesta aproximadamente 996 dólares al mes en Gemini 3.1 Pro y unos 2,490 dólares en Claude Opus 4.6. Algunas decisiones de diseño pueden reducir ese costo a entre 50 y 100 dólares.

Las ideas que se tratan aquí son el caché de prompts, el caché semántico, las herramientas de carga diferida y los servidores MCP, el enrutamiento y la cascada entre modelos, la delegación a subagentes y mantener el contexto de trabajo limpio. Cada una ahorra dinero de manera diferente, y cada una tiene un costo en términos de complejidad o calidad. Ninguna de ellas es gratuita.

El material se divide en cuatro grupos. El primero consiste en reutilizar tokens cuando es posible, a través del caché de prompts y el caché semántico. El segundo es reducir los tokens que siempre están presentes, como la memoria y las definiciones de herramientas. El tercero consiste en encauzar el trabajo a modelos más pequeños o ascender a modelos más grandes, sopesando el riesgo para la calidad frente al ahorro. El último es mantener el contexto limpio, tanto por motivos de rendimiento como de costos, con una breve explicación sobre la compactación.

Deje de pagar dos veces por los mismos tokens

Los costos del modelo no provienen únicamente de llamar al modelo con demasiada frecuencia. También se deben a tener que pagar una y otra vez para procesar texto idéntico. Dos mecanismos muy diferentes ayudan en esto: el caché K/V es la base del caché de prompts, mientras que el caché semántico es un concepto separado. Para prompts largos del sistema, el caché de prompts ofrece beneficios sencillos; en cambio, el caché semántico requiere más esfuerzo y conlleva mayores riesgos.

Cómo funciona el caché K/V

Antes de que un modelo genere algo, debe procesar el prompt, lo cual requiere recursos computacionales, lo que a su vez genera latencia y costos. Tiene sentido no volver a procesar el mismo contenido repetidamente.

Cuando un modelo de lenguaje grande recibe un prompt, el texto se tokeniza, los tokens se convierten en vectores, y dentro de cada capa de atención esos vectores se proyectan en tensores K/V.

El caché consiste en conservar esos tensores para que no sea necesario volver a calcularlos. Un motor de inferencia ya mantiene los tensores K/V durante la generación, ya que de lo contrario las operaciones matemáticas no se ejecutarían a una velocidad razonable. El siguiente paso es conservar el caché después de que finalice la respuesta y no desecharlo.

En la siguiente solicitud, el sistema verifica si el inicio del prompt coincide con algo para lo cual ya cuenta con tensores. Si es así, los carga y omite el procesamiento.

Es fácil comprender las ventajas económicas con números redondos. Supongamos que procesar 2,000 tokens lleva un segundo y que el prompt del sistema tiene 10,000 tokens. Omitir ese nuevo cálculo ahorra 5 segundos en cada llamada, aunque el rendimiento real varía mucho según la configuración.

La comparación con la caché almacenada debe ser exacta. Si cualquier token cambia, los tensores correspondientes a esa parte del prompt ya no son aplicables y deben procesarse de nuevo. La gente se tropieza constantemente con esto: un espacio adicional, una definición de herramienta reordenada o una marca de tiempo en el lugar incorrecto rompen la coincidencia.

Por lo tanto, una caché almacenada acelera las solicitudes y, a su vez, las hace más económicas. Sin embargo, almacenarla no es gratis. Los datos en formato K/V en caché ocupan memoria en el lado del servidor, y por eso muchos proveedores hacen que las entradas caduquen después de unos 5 a 10 minutos.

Nadie tiene que crear esto desde cero, ya que los frameworks y proveedores de API se encargan de ello, cada uno con sus propias reglas. Los equipos que alojan un modelo de código abierto suelen utilizar un framework de servir como vLLM, que cuenta con una capa de caché integrada. Los usuarios de API, en cambio, siguen la política de cada proveedor.

Caché de prefijos en vLLM

La capa de caché en vLLM divide el prompt en bloques, calcula el hash de cada bloque a partir de sus propios tokens además de los tokens anteriores, y almacena las tensores K/V bajo esos hashes. Al igual que en la mayoría de las configuraciones, la parte estática que se va a cachear debe encontrarse al principio del prompt.

Tres parámetros son importantes:

• --enable-prefix-caching activa esta función.
• --block-size establece la cantidad de tokens por bloque. Con un tamaño de bloque de 16, el motor termina después de 16 tokens y comienza un nuevo bloque.
• --kv-cache-memory-bytes define explícitamente el tamaño del caché K/V por GPU. Más memoria permite que los bloques en caché duren más tiempo, pero muchas solicitudes largas al mismo tiempo lo llenan más rápido y los bloques antiguos son eliminados antes.

Existen otras opciones, como SGLang con RadixAttention para el caché de prefijos, y LMCache, diseñado para integrarse en motores de servicio. Su funcionamiento es similar al descrito anteriormente.

Caché a través de proveedores de API

La mayoría de los equipos utilizan proveedores de API, y cada uno tiene políticas que deben seguir para que las solicitudes lleguen al caché. La solicitud debe estar estructurada en consecuencia. OpenAI es un ejemplo claro: para cachear una parte de la solicitud se requiere una coincidencia exacta de prefijo, es decir, el mismo inicio estático. Por lo tanto, las instrucciones estables, los ejemplos y las herramientas van primero, mientras que el contenido variable lo hace después.

Al enviar un prompt-cache-key se pueden agrupar solicitudes similares, lo que aumenta las tasas de éxito. El caché se activa automáticamente para solicitudes de 1,024 tokens o más, pero los primeros 256 tokens se utilizan para dirigir las solicitudes al mismo caché, por lo que la parte estática debe tener más de 256 tokens.

Anthropic funciona de manera diferente: el caché debe activarse con el parámetro cache-control. La eliminación del contenido en caché suele ocurrir después de 5 a 10 minutos de inactividad en ambos proveedores, y se puede prolongar. Anthropic permite extender ese plazo a una hora por el doble del precio.

Al autohospedar, el tiempo ahorrado también se traduce en dinero ahorrado. Con los proveedores de API, la ventaja radica en tokens de entrada en caché más económicos. OpenAI reduce el precio de los tokens de entrada en caché hasta en un 90% con respecto al precio normal. Anthropic ofrece el mismo descuento en los tokens de entrada en caché, pero también cobra por mantener el caché, por lo que un uso inadecuado puede resultar más caro que no utilizarlo.

Cuando el 90% de un prompt es estático y se utiliza adecuadamente el caché, el costo disminuye drásticamente, como muestra el gráfico.

Se creó una calculadora interactiva para esta comparación, de modo que se puedan ajustar los números. En general, el caché rápido de comandos es una gran ventaja para quienes tienen un comando del sistema largo e invariable.

Caché semántico

El caché semántico es algo completamente distinto. Funciona comparando el significado: si una nueva solicitud es lo suficientemente similar a una anterior, se devuelve la respuesta almacenada. Eso suena sencillo, pero existen problemas evidentes.

La comparación de texto por significado utiliza embeddings, que son vectores cuya similitud se mide mediante la similitud de coseno. Una alta similitud debería indicar un significado similar, aunque eso depende del modelo de embeddings.

La propuesta consiste en emparejar solicitudes similares con respuestas que ya existen. Una pregunta como “¿Cuál es la capital de Francia?” y una urgente “Rápido, dame la capital de Francia” deberían dirigirse ambas a una misma respuesta almacenada, sin necesidad de volver a consultar a un modelo de lenguaje para generarla. Esto funciona bien cuando muchas personas hacen preguntas genéricas casi idénticas y los datos subyacentes se vuelven obsoletos gradualmente.

Entonces, ¿por qué no hacerlo en todas partes? Porque pueden ocurrir muchos problemas. El diseño debe resolver varias cuestiones:

• Qué umbral de similitud se considera como coincidencia.
• Por cuánto tiempo permanece válida una respuesta.
• Cómo se manejan las conversaciones de varias interacciones.
• Qué es lo que realmente se almacena.
• Si se debe utilizar un enrutador como intermediario.
• Cómo mantener separados a los usuarios.
• Qué sucede si se almacena una respuesta incorrecta.

El tiempo de vida merece una atención especial, ya que la información se vuelve obsoleta a diferentes velocidades según la pregunta. La mecánica es sencilla, pero su uso en producción requiere filtros y etiquetas de metadatos, como usuario, espacio de trabajo, versión del corpus, persona, alcance de la sesión, un TTL inteligente y alguna regla para determinar si una coincidencia devuelta es lo suficientemente buena. Esto se convierte en un pequeño proyecto.

Un diseño viable utiliza el índice semántico para encontrar una pregunta anterior y permite que diferentes preguntas apunten a la misma respuesta almacenada, lo que limita el crecimiento del almacenamiento. El TTL puede adaptarse al uso: conservar las entradas reutilizadas con frecuencia por más tiempo y descartar el resto. También es sensato desarrollarlo después de que los registros muestren repetición y no desde el principio, ya que algunos casos de uso simplemente no son adecuados para ello.

Muchas bases de datos pueden realizar esta tarea, y existen bibliotecas que se encargan de los detalles técnicos, entre ellas semanticcache, prompt-cache, GPTCache, vCache, Upstash semantic-cache y Redis con LangCache.

Los ahorros pueden ser reales. Redis afirma una reducción de hasta el 68,8% en las llamadas a la API y una mejora en la latencia del 40 al 50%, aunque esta cifra tiene un componente de marketing, ya que proviene de un escenario simple de preguntas y respuestas. Los resultados dependen completamente de la configuración: un bot de preguntas y respuestas con muchas llamadas redundantes ahorra más, mientras que un agente de programación cuyas llamadas son todas únicas ahorra menos.

El caché de prompts es útil cuando una pregunta que cambia está incluida dentro de un prompt estático grande, y el caché semántico es eficaz cuando las personas siguen reformulando la misma pregunta. Una tasa de coincidencia semántica del 15% solo genera ahorros modestos, pero una tasa superior al 45-50% comienza a resultar valiosa.

También difieren en cuanto a qué puede salir mal. Un fallo en la caché de prompts solo implica el costo normal, por lo que el error es económico y visible. Un fallo en la caché semántica también es inofensivo, pero un falso acierto no lo es: el usuario recibe una respuesta escrita para otra pregunta, con total confianza, y nada en los registros lo señala. Esa asimetría es la razón por la cual el caché semántico requiere umbrales de similitud conservadores, delimitación de usuarios y una forma de revisar los aciertos, mientras que el caché de prompts necesita principalmente un diseño disciplinado de las instrucciones.

También merece mención el caché ordinario. Los cálculos deterministas costosos, como los resultados de consultas SQL, las salidas de herramientas y los resultados de búsqueda, deben cachearse para que nunca se ejecuten más veces de lo necesario. Un ejemplo es una herramienta que recopila datos de palabras clave para resumir, los cachea hasta que se vuelven obsoletos y vuelve a ejecutarlos solo cuando se accede nuevamente a esa ruta.

El caché semántico es un concepto interesante que permite guardar tokens en ciertos casos de uso, pero hacerlo bien requiere habilidades técnicas especializadas.

No precargue tokens inactivos

Un prompt de sistema puede volverse voluminoso debido a definiciones de herramientas excesivas o al aumento de la memoria. Los agentes pequeños no lo notan, pero las especificaciones de los agentes que siguen creciendo pueden reducirse obteniendo información bajo demanda, o al menos intentándolo.

Mantenga la capa siempre cargada pequeña

Cuando el prompt de un agente supera cierto tamaño, la capa que siempre está cargada debe permanecer pequeña y estable, con los detalles adicionales almacenados por separado. Cargar unos cientos de herramientas o enviar descripciones completas del servidor MCP que siguen cambiando hace que todo sea caótico.

El problema radica tanto en el rendimiento como en el costo. Cuando cualquier capa sigue cambiando, resulta mucho más difícil acceder al caché de instrucciones. La capa superior debe ser compacta y estable, lo suficiente como para indicarle al modelo dónde se encuentra y a dónde dirigirse a continuación, sin tener que cargar todo de antemano.

Se dice que Claude Code sigue este patrón para gestionar la memoria. Siempre se carga un archivo de índice que no debe superar las 200 líneas, mientras que los archivos detallados de cada tema se almacenan en otro lugar. Cómo se comporta el agente en la práctica en comparación con lo que pretende el sistema es una cuestión aparte. Un razonamiento similar se observa en la configuración de herramientas avanzadas de Claude, en el diseño por capas de las habilidades de Claude y en los intentos por cargar de forma diferida las herramientas MCP en lugar de incluir todas las definiciones del servidor desde el principio.

¿Funciona?

El principio sigue siendo el mismo: cuando el contexto se vuelve grande, al modelo le resulta más difícil elegir la acción correcta. Este campo aún es incipiente, por lo que una herramienta concreta demuestra cómo puede funcionar.

Hace unos meses, Anthropic lanzó una función avanzada de búsqueda de herramientas, cuyo objetivo es reducir el volumen del contexto incluso cuando el modelo puede acceder a cientos de herramientas. La empresa indica haber observado entre 55K y 134K tokens de definiciones de herramientas antes de la optimización, y que elegir la herramienta incorrecta es un error común cuando el contexto alcanza ese tamaño.

Una herramienta de búsqueda optimiza el contexto al permitir que el LLM busque las herramientas en lugar de definirlas todas de antemano. Una configuración se ve así:

tools=[
        {
            "type": "tool_search_tool_bm25_20251119",
            "name": "tool_search"
        },
        {
            "name": "search_contacts",
            "description": "Find a contact by name or email.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "query": {"type": "string"}
                },
                "required": ["query"]
            }
        },
        {
            "name": "send_email",
            "description": "Send an email to one or more recipients.",
            "input_schema": {
                "type": "object",
                "properties": {
                    "to": {"type": "string"},
                    "subject": {"type": "string"},
                    "body": {"type": "string"}
                },
                "required": ["to", "subject", "body"]
            },
            "defer_loading": True
        }
    ]

Se define una herramienta llamada tool_search, utilizando una opción lista para usar: BM25 o Regex, o una personalizada. Luego se marca una sola herramienta como diferida, a modo ilustrativo. Esto solo tiene sentido con 10 o más herramientas. Anthropic realiza la búsqueda, por lo que la forma en que inserta el esquema de la herramienta en el prompt del sistema y la búsqueda en sí permanecen ocultas. Una vez que una herramienta coincide, su definición se agrega directamente en la conversación como un bloque tool_reference.

La idea es interesante, ya que ofrece un contexto inicial más reducido a cambio de un paso adicional en la búsqueda. Las pruebas realizadas con 4,000 herramientas arrojaron resultados bastante mediocres, por lo que hay espacio para más pruebas. Las herramientas también deben describirse de manera suficientemente clara para poder encontrarse, y depurar se vuelve más difícil cuando el paso intermedio es invisible.

Este patrón se repite en otros contextos bajo la simple denominación de buena ingeniería de IA. No exponga al agente a un contexto enorme y desordenado. Déle una forma de reducir las opciones y permítale inspeccionar o cargar una herramienta solo cuando sea necesario.

El ahorro obtenido depende de cuántos tokens se envíen inicialmente. Una segunda calculadora compara la búsqueda de herramientas con el caché de instrucciones.

La muestra anterior muestra los ahorros estimados al combinar el caché de instrucciones con herramientas cargadas de forma perezosa. Ambos métodos generan ahorros, pero su combinación no supone un cambio significativo respecto al uso de cualquiera de ellos por separado. La búsqueda de herramientas no se refiere solo al costo económico, ya que también mantiene el contexto limpio para mejorar el rendimiento. Si solo se busca ahorrar, adoptar al menos uno de los dos métodos representa la mejor opción.

Use modelos económicos para tareas económicas

Esta sección trata sobre la redirección de solicitudes a diferentes modelos y el uso de subagentes más económicos para tareas específicas. Ambos métodos pueden reducir los costos por token, pero también ponen en riesgo la calidad. Muchos sostienen que el 60 % o más de las preguntas recibidas son sencillas y no requieren el modelo más potente, y ciertamente no uno capaz de razonar.

Los productos comerciales ya realizan parte de esto. Se informa que ChatGPT redirige las solicitudes según indicadores como el tipo de conversación, la complejidad, las necesidades de herramientas e intenciones explícitas como “pensar detenidamente”, mientras que Claude depende de la delegación basada en descripciones además de subagentes integrados como Explore. El concepto es fácil de comprender; lo difícil es hacerlo sin afectar la calidad. Lo que sigue aborda la redirección predictiva y enfoques de verificación de resultados como las cadenas de procesamiento y los subagentes, mientras que un tercer apartado explica los ahorros obtenidos.

Redirigir según la dificultad

El enrutamiento a nivel de solicitud estima la dificultad y la intención antes de que exista cualquier salida. Las ventajas son significativas, pero una mala elección puede arruinar toda la sesión, por lo que la calidad es un problema real. Algún tipo de modelo de enrutador debe decidir a dónde va cada solicitud.

Las señales de enrutamiento de OpenAI no son públicas, y los usuarios a menudo sienten que han sido trasladados a un modelo menos potente en un momento molesto. El mundo de código abierto ofrece más opciones para analizar. RouteLLM, desarrollado por LMSYS, el grupo de Berkeley detrás de Chatbot Arena, aprende a partir de datos reales de preferencias recopilados en la plataforma. Combina embeddings estándar con una pequeña estructura de enrutamiento, lo que debería mantener bajos los costos de hospedaje; sus creadores informan grandes reducciones en costos manteniendo la mayor parte del rendimiento de GPT-4. Esa afirmación aún no ha sido verificada de forma independiente aquí.

El artículo LLMRouterBench añade una observación preocupante: muchos routers aprendidos apenas superan a lineamientos simples como el enrutamiento por palabras clave o heurísticas, así como los métodos de enrutamiento basados en vecinos más cercanos y kNN.

Los routers sofisticados pueden no ofrecer una gran ventaja sobre soluciones simples. La gente sigue utilizando métodos tradicionales de enrutamiento y continúa experimentando, pero los ahorros no están garantizados cuando la calidad de las respuestas no es suficiente. También existen opciones alojadas en la nube, como OpenRouter Auto y Switchpoint, aunque ningún recurso público describe sus mecanismos internos de enrutamiento ni su precisión. La calculadora compara LLMRouter, heurísticas, un clasificador autoalojado, LLM-as-router, RouteLLM y OpenRouter Auto. La calidad en el mundo real requiere pruebas adecuadas con cifras claras, algo que este campo merece por sí mismo.

Comience con lo económico y aumente la complejidad cuando haya poca confianza

Omitiendo cualquier intento de predecir la dificultad de una solicitud a partir de su prompt, el modelo económico puede responder primero y luego un verificador decide si mantiene esa respuesta o procede a escalarla. La descripción de “Speculative Cascades” de Google explica este equilibrio: se utilizan modelos pequeños primero por su costo y velocidad, y solo modelos más grandes cuando es necesario.

El modelo económico genera la respuesta, y posteriormente un verificador ligero analiza indicadores como las probabilidades logarítmicas, la entropía o la incertidumbre de tipo margen, así como el alineamiento semántico.

Este enfoque resulta atractivo porque es difícil predecir la dificultad del prompt y la mayoría de los routers no son perfectos, mientras que la calidad es más fácil de evaluar una vez que existe una respuesta. Solo tiene sentido si la mayoría de las preguntas pueden ser respondidas por el modelo más simple, ya que las solicitudes escaladas implican dos llamadas. Los equipos que lo utilizan afirman que la latencia de validación entre llamadas puede mantenerse por debajo de 20 ms.

Una implementación de código abierto llamada CascadeFlow afirma lograr un ahorro del 69% manteniendo un 96% de calidad en comparación con GPT-5. Sin embargo, las instrucciones con las que se probó contaban con respuestas verdaderas verificables, como soluciones matemáticas y preguntas de opción múltiple. La principal preocupación es que los modelos pequeños a menudo se equivocan con certeza, por lo que puede ser sensato comenzar con umbrales conservadores y aumentarlos con mayor frecuencia, lo que eleva los costos. La adición de un sistema en cascada basado en opciones económicas a la calculadora sugiere ahorros cercanos al 50%, siempre y cuando para algunas solicitudes sea necesario utilizar modelos más grandes.

Delegar a subagentes

Los subagentes delegan tareas a agentes aislados, que a veces utilizan modelos más pequeños, por lo que también constituyen una forma de enrutamiento. Los ahorros en este caso son menores. El valor radica además en mantener el contexto limpio para que cada agente pueda concentrarse plenamente en su propia tarea.

Claude Code viene con subagentes integrados. El subagente Explore es explícitamente un trabajador Haiku para explorar y buscar en una base de código, lo cual aplica la idea de utilizar modelos menos costosos para tareas menos complejas. La sesión principal también delega tareas de forma invisible mediante la coincidencia de descripciones, y el usuario solo ve una factura total más baja. Dado que el orquestador normalmente sigue involucrado en la planificación, síntesis y reintentos, el ahorro resultante es menor que el que ofrece el enrutamiento.

Según las cifras del calculador, los subagentes reducen aproximadamente un 11% el costo en comparación con la opción sin enrutamiento, por lo que no son el principal factor para reducir costos por sí solos.

Mantener el contexto limpio

Una buena ingeniería de contexto se trata principalmente de rendimiento, pero también puede afectar los costos. Con el tiempo, los agentes acumulan desorden: intentos obsoletos, planes antiguos, estado duplicado, registros, observaciones repetidas y salidas brutas de las herramientas. Quienes crean agentes por primera vez son especialmente propensos a esto, ya que siguen introduciendo resultados en el estado de trabajo del agente principal.

Esto ocurre en todas partes. Los usuarios de OpenClaw se quejan del acúmulo de contexto, al igual que los usuarios de Claude Code, porque añadir contenido es más fácil que limpiarlo.

La parte difícil es el pipeline de estado

Se trata de un problema en dos niveles. No se trata solo de comprimir el chat; el nuevo material también debe mantenerse limpio al entrar en el estado de trabajo, y eso requiere una ingeniería tediosa. Un patrón deficiente se ve así, donde el agente sigue introduciendo salidas brutas en el contexto:

bad state:
agent does work
→ dumps tool output into context
→ reads files
→ dumps files into context
→ runs tests
→ dumps logs into context
→ retries
→ keeps everything

La tarea real es mantener el estado correcto mientras se elimina lo innecesario en el proceso. La salida bruta puede ir a un archivo, quedando solo lo necesario en el contexto activo. El problema habitual es la sobrecarga generada por las herramientas, por lo que reducir su ruido de forma predeterminada forma parte del trabajo. Un contexto activo más saludable se ve así:

Good active context

[system rules]
[project rules]
[user task]
[current working state]

Keep:
+ auth flow lives in auth.ts + session.ts
+ bug only happens on refresh path
+ failing test: session_refresh_keeps_user
+ likely overwrite during refresh
+ files in scope: auth.ts, session.ts, auth.test.ts

Drop:
- raw grep results
- full test logs
- duplicate file dumps
- dead-end retries

Ciertos fragmentos de contexto también pueden tener un ciclo de vida o una fecha de vencimiento. Una vez que se hace necesaria la compresión, resulta más sencillo determinar qué es lo que realmente necesita el LLM.

Las notas de Anthropic sobre tareas a largo plazo indican que la compresión debe preservar las decisiones arquitectónicas, los errores sin resolver y los detalles de implementación. La compresión autónoma de LangChain permite al agente decidir cuándo comprimir, sin esperar a que el contexto ya esté sobrecargado, lo cual parece ser el enfoque de Anthropic. Los equipos están comenzando a tratar la compresión como un problema de sistemas, con pruebas de rendimiento y políticas específicas para cada agente, y ya no como un simple truco de resumen genérico.

Un artículo reciente de Jia y colaboradores sostiene que con una compresión 6 veces mayor se logró una reducción del 51,8 al 71,3 % en el presupuesto de tokens, junto con una mejora del 5,0 al 9,2 % en la resolución de problemas en SWE-bench Verified. Por lo tanto, no se trata solo de costos; también ayuda al rendimiento en general.

Eliminar el contenido no esencial puede liberar razonablemente del 30 al 70% de un contexto, lo que ahorra una cantidad similar en dólares. Para una ventana de contexto de 10k, limpiar del 30 al 50% en 100k ejecuciones podría ahorrar hasta 1,500 dólares, y en 40k esa cifra asciende a 6,000 dólares. Los agentes de compresión que ya utilizan modelos muy pequeños y económicos pueden costar más de lo que ahorran. Aun así, un contexto limpio no sacrifica la calidad de la misma manera que el caché semántico o la enrutación, por lo que, si se hace bien, representa una clara ventaja. El problema radica en el esfuerzo necesario para llevarlo a cabo.

Elegir entre ellos

Existen cuatro formas de reducir los costos de los tokens, y la combinación adecuada depende del caso de uso:

• Utilizar caché de prompts con prompts del sistema grandes que permanezcan sin cambios en las llamadas repetidas al LLM.
• Usar caché semántico para un bot de preguntas y respuestas genérico que debe mantenerse económico.
• Probar la enrutación cuando el agente debe manejar tanto preguntas fáciles como difíciles.

Mantenga el contexto lo más limpio posible para evitar enviar tokens innecesarios.

Leer más

• Orquestación de Multi-Agentes en Bedrock y LangGraph: Cuatro patrones — Patrones supervisor-trabajador, pipeline, fan-out y debate con LangGraph en AWS Bedrock, además de mecanismos de transferencia, protecciones de presupuesto, seguimiento y modos de fallo en producción.
• Un diseño de memoria de cuatro capas para agentes de IA con trazabilidad — División de memoria a corto y largo plazo, cuatro capas (búfer, episódica, semántica, procedural), opciones de almacenamiento, escrituras asíncronas y medidas de protección contra envenenamiento de la memoria.
• Modo Video Agente de Gemini: Diseño de Esquema y Desviación de Marcas de Tiempo — Pruebas de los modos de video agente y estático de Gemini en una película china: cómo el diseño del esquema influye en la precisión de las marcas de tiempo, su desviación, las citas y los rangos de tiempo.
• Ingeniería de Contexto Agente: Una Guía Paso a Paso para Ingenieros de ML — Cómo diseñar lo que ve un agente LLM en cada paso: recuperación de información, contexto estructurado, memoria, compresión y evaluación, con un ejemplo práctico de un agente de depuración de ML.