Guía · Intermedio · 11 min
Reducir el costo de un agente de IA: modelo, caché, contexto, enrutamiento y presupuestos
Reduzca el costo de sus agentes de IA midiendo las tareas completadas con éxito y ajustando modelos, caché, contexto y límites de gasto sin perder calidad.

Para reducir el costo de un agente de IA, mida primero cuánto cuesta completar una tarea con éxito. Después, reduzca las llamadas innecesarias, el contexto enviado y los reintentos antes de cambiar de modelo. La caché, el enrutamiento y los límites de gasto completan este enfoque, siempre que se mantenga un nivel de calidad comprobado.
Medir las tareas completadas con éxito, no solo los tokens
El precio de una llamada representa solo una parte del costo. Un agente puede consultar documentos, acceder a servicios de pago, generar una respuesta, comprobar el resultado y volver a intentarlo. Una respuesta barata que exige una larga corrección humana puede encarecer todo el proceso.
Elija una unidad de trabajo vinculada a su actividad: un expediente procesado y aceptado, un cambio validado o una extracción de datos utilizable. Defina los criterios de aceptación antes de comparar configuraciones. De lo contrario, una reducción aparente del costo podría deberse simplemente a que se ha eliminado una comprobación.
El costo completo incluye el consumo de los modelos, las herramientas, el alojamiento, el almacenamiento, la observabilidad y las intervenciones humanas. Separe los gastos variables de los costos fijos: una infraestructura ya pagada no es gratuita, aunque su costo marginal sea distinto de su costo total.
Para cada ejecución, registre:
- el identificador de la tarea y si el resultado se ha aceptado o rechazado;
- el modelo y los parámetros utilizados;
- los volúmenes de entrada, de caché y de salida;
- las llamadas a herramientas, los reintentos y los errores;
- la duración y las correcciones humanas necesarias.
Un token es una unidad de procesamiento del modelo, no una unidad universal de trabajo facturable. La guía para entender los precios de las API de LLM explica estas unidades; aquí, el objetivo es relacionarlas con el resultado obtenido.
Reconstruir la factura sin contar dos veces el mismo consumo
En cada llamada, distinga las categorías que realmente se facturan: entrada ordinaria, lectura de caché, posible escritura en caché y salida. Añada los cargos de las herramientas y los servicios asociados. Compruebe si los contadores del proveedor incluyen los tokens en caché dentro de la entrada total o los presentan como una categoría independiente.
La fórmula de trabajo es sencilla: sume los volúmenes facturables multiplicados por sus respectivas tarifas y añada los demás gastos. Aplíquela a cada llamada cuando los modelos o las tarifas cambien durante una tarea. No multiplique todo el consumo por una tarifa media elegida de forma arbitraria.
Ejemplo de cálculo ficticio, sin valor de cotización. Supongamos una tarea que consume en total 100 000 tokens de entrada ordinaria y 10 000 tokens de salida. Las tarifas siguientes proceden del índice del sitio y no incluyen caché, herramientas ni otros cargos.
| Modelo | Entrada por millón de tokens | Salida por millón de tokens | Costo calculado del ejemplo |
|---|---|---|---|
| Claude Haiku 5.5 | 0,10 $ | 0,50 $ | 0,015 $ |
| Claude Sonnet 5.5 | 2 $ | 10 $ | 0,30 $ |
Tarifas: registro del sitio, octubre de 2026, disponibles en las fichas enlazadas. Estos cálculos suponen volúmenes idénticos; no demuestran que la calidad ni el número de pasos sean equivalentes.
Para elaborar su propia estimación, utilice la calculadora de precios de LLM y contraste el resultado con el consumo realmente facturado. El artículo ¿Cuánto cuesta realmente un agente de IA al mes? amplía este enfoque al presupuesto global.
Elegir el modelo según las tareas que importan
Un modelo más barato por token solo resulta interesante si su comportamiento sigue siendo adecuado. Compare su capacidad para respetar instrucciones, producir los datos esperados, elegir herramientas y detenerse cuando corresponde. Un error que pasa inadvertido puede costar más que un rechazo explícito.
Prepare un conjunto representativo de casos: entradas cortas y largas, documentos incompletos, herramientas no disponibles, solicitudes ambiguas y situaciones que exijan rechazar una petición. Mantenga los mismos criterios en todas las configuraciones. La guía Evaluar un agente de IA explica cómo organizar esta comparación.
Mida el costo total de las pruebas, incluidas las que fallan, y divídalo entre el número de resultados aceptados. Observe también las tareas más costosas: una media satisfactoria puede ocultar bucles prolongados con determinados documentos.
Las fichas de modelos de lenguaje permiten preseleccionar candidatos según sus características. No sustituyen una evaluación de su proceso concreto, con sus instrucciones y sus herramientas.
Puede ser razonable mantener un modelo más costoso para una etapa difícil y simplificar las demás. A su vez, cambiar sistemáticamente de modelo en cada operación añade una lógica que deberá mantener. Empiece por una configuración comprensible y añada complejidad solo cuando pueda medir el ahorro.
El artículo El LLM más barato para cada uso aborda la elección por tipo de necesidad; esta guía se centra en la ejecución completa.
Reducir las decisiones que se delegan en el modelo
El primer ahorro puede consistir en eliminar una llamada. Un programa convencional puede comprobar una fecha, sumar importes, aplicar un filtro o verificar que existe un campo. Pedir al modelo que repita estas operaciones añade una decisión probabilística y un gasto.
Trace el recorrido de una tarea: recepción, recuperación de datos, interpretación, acción y validación. Identifique qué etapas son deterministas y cuáles requieren interpretación. Reserve el modelo para estas últimas y utilice comprobaciones explícitas en las primeras.
Esta distinción coincide con la recomendación de Anthropic en Building effective agents: empezar por la solución más sencilla y añadir complejidad cuando la necesidad lo justifique. El documento distingue entre los recorridos predefinidos y los agentes que deciden por sí mismos qué camino seguir.
Evite, en particular, que un agente tenga que redescubrir un procedimiento estable en cada ejecución. Proporcione los requisitos previos, las herramientas pertinentes y una definición del resultado esperado. Una instrucción precisa puede evitar búsquedas exploratorias sin imponer cada detalle del razonamiento.
Los subagentes requieren la misma disciplina. Delegarles tareas independientes puede reducir la espera, pero cada rama consume recursos y genera un resultado que después debe integrarse. El paralelismo, por sí solo, no supone un ahorro.
Antes de añadir una rama, especifique qué debe aportar, qué datos necesita y en qué condiciones debe detenerse. Si nadie utiliza su resultado, elimínela.
Mantener un contexto útil y verificable
La ventana de contexto indica lo que el modelo puede recibir, no lo que conviene enviarle. Un historial con registros voluminosos, documentos repetidos y búsquedas abandonadas puede aumentar el consumo sin mejorar la siguiente decisión.
Organice los datos según su función: instrucciones estables, estado actual, pruebas útiles y archivos consultables. El estado actual debe indicar el objetivo, las acciones ya realizadas, las restricciones y los asuntos pendientes. Los archivos deben seguir disponibles sin volver a incluirse sistemáticamente en el contexto.
Para los resultados de las herramientas, solicite los campos necesarios. Una consulta específica, la paginación o un fragmento alrededor de una coincidencia permiten evitar la recuperación de todo un conjunto de datos. Conserve una forma de volver a la fuente cuando el fragmento no sea suficiente.
La búsqueda documental selectiva también añade costos de búsqueda, indexación y, en ocasiones, clasificación por relevancia. Compare ese costo con el volumen de contexto que evita enviar. Un documento corto utilizado de forma puntual no justifica necesariamente una infraestructura adicional.
La compresión del historial también merece una evaluación. Un resumen puede omitir una restricción, una referencia o una acción ya ejecutada. Conserve por separado los datos estructurados que deben seguir siendo exactos: identificadores, validaciones, importes y estado de las operaciones.
Por último, no resuma indefinidamente un resumen anterior. Cuando el estado deje de ser fiable, reconstrúyalo a partir de las fuentes de referencia. Un pequeño ahorro de contexto no debería provocar que se repita toda la ejecución.
Aprovechar la caché sin dar por hecho el ahorro
La caché de prompts permite reutilizar el procesamiento de una parte de la entrada. No garantiza que el agente responda sin generar contenido nuevo. Su utilidad depende de la repetición efectiva de los contenidos y de las reglas del servicio.
Coloque los elementos estables al principio del contexto y los datos variables después cuando el mecanismo se base en un prefijo común. Evite insertar una marca de tiempo cambiante antes de unas instrucciones idénticas. Aun así, no modifique instrucciones necesarias con el único propósito de conservar la caché.
La documentación de caché de Anthropic, consultada el 24 de octubre de 2026, describe una caché de prefijos, automática o explícita, con condiciones de duración y facturación. Mida por separado la creación, la lectura y la entrada ordinaria; las solicitudes muy espaciadas o los cambios en los prefijos pueden impedir su reutilización.
Los mecanismos varían entre API. La documentación de caché de Google, actualizada el 23 de octubre de 2026, describe, entre otros mecanismos, una caché implícita y precisa que la caché explícita no está disponible en todas las interfaces ni para todas las generaciones. No traslade automáticamente una configuración de un proveedor a otro.
Compare el costo total con y sin caché sobre un tráfico representativo. Incluya las escrituras, el almacenamiento cuando se facture y las solicitudes que no reutilizan contenido. La tasa de aciertos de caché, por sí sola, no indica cuánto se ha ahorrado.
Una caché de respuestas implica otra decisión: devolver un resultado anterior. Su clave debe incluir los permisos de acceso, la versión de los datos y los parámetros pertinentes. Una respuesta antigua o destinada a otro usuario puede resultar inutilizable, aunque recuperarla cueste poco.
Enrutar según reglas observables
El enrutamiento consiste en elegir un modelo o un recorrido según la tarea. Empiece por reglas verificables: tipo de documento admitido, presencia de los archivos necesarios, longitud de la entrada o resultado de una validación. Una regla explícita permite entender por qué una solicitud sigue un recorrido costoso.
| Estrategia | Activación | Costo que debe medirse | Principal limitación |
|---|---|---|---|
| Modelo único | Todas las solicitudes | Ejecución y reintentos | Gasto elevado en tareas sencillas |
| Enrutamiento previo | Categoría o restricción conocida | Clasificación y recorrido elegido | Asignación inicial incorrecta |
| Escalamiento tras una comprobación | Resultado rechazado o incompleto | Primer intento, comprobación y reintento | Trabajo duplicado cuando hay fallos |
| Recorrido determinista | Las reglas son suficientes | Ejecución y mantenimiento | Capacidad limitada ante ambigüedades |
Para escalar una tarea, defina una señal concreta: un campo ausente, una referencia que no se encuentra, un formato inválido o una prueba fallida. La confianza que declara el modelo no sustituye una comprobación del resultado.
El cálculo debe incluir todos los intentos: costo del primer modelo, de la comprobación, de los escalamientos y de la coordinación. Compararlo con el recorrido directo permite determinar si el ahorro existe realmente.
Transmita al siguiente modelo las pruebas útiles y el motivo del escalamiento. Evite presentar la respuesta anterior como un hecho confirmado. En las acciones sensibles, el enrutamiento no debe modificar las obligaciones de validación.
Por último, limite las alternativas de respaldo. Una interrupción del servicio no debe desencadenar una cadena de intentos con servicios más caros o incompatibles con las restricciones de tratamiento de datos.
Controlar las salidas, el razonamiento y los reintentos
Pida una salida adecuada para quien vaya a utilizarla. Una etapa interna puede producir campos estructurados y un estado, mientras que la respuesta final explica el resultado al usuario. Generar un comentario extenso en cada etapa añade contenido que debe producirse y, posiblemente, volver a leerse.
Un límite de salida sirve como medida de control, pero una respuesta truncada puede quedar inutilizable. Compruebe el motivo de la detención y defina cómo tratar las salidas incompletas. Reducir arbitrariamente la longitud puede trasladar el costo a los reintentos.
Cuando el modelo permita ajustar el esfuerzo de razonamiento, compare los niveles disponibles con sus tareas. Una explicación visible breve no demuestra que el cálculo interno sea reducido. Utilice los contadores y la facturación de la API empleada para evaluarlo.
Distinga también los tipos de error. Una entrada inválida requiere una corrección; una indisponibilidad temporal puede justificar otro intento. Repetir una solicitud idéntica sin diagnosticar el problema consume recursos sin resolver su causa.
En una acción externa, compruebe su estado antes de repetirla. Que se agote el tiempo de espera no significa necesariamente que la operación haya fallado. Un identificador de operación y un mecanismo de idempotencia, cuando el servicio lo permita, evitan tratar un reintento como una acción nueva.
Posponer lo que pueda esperar
El procesamiento por lotes puede ser adecuado para extracciones documentales, evaluaciones y enriquecimiento de datos que no exijan una respuesta inmediata. Resulta más difícil integrarlo en un ciclo interactivo en el que cada etapa depende de la anterior.
A fecha del 24 de octubre de 2026, la documentación de la API Batch de Google anuncia una facturación del 50 % del costo estándar y un plazo objetivo de 24 horas. Ese plazo objetivo no constituye una garantía universal de entrega. Compruebe los modelos y la interfaz compatibles antes de planificar el procesamiento.
Compare el ahorro de consumo con las exigencias operativas: cola de espera, seguimiento de resultados, errores parciales y asociación con los expedientes de origen. Debe ser posible reintentar los elementos fallidos de un lote sin volver a procesar los ya aceptados.
La ejecución local plantea una decisión diferente. Calcule el costo del hardware o de su alquiler, de la electricidad y de la operación, y relaciónelo con el trabajo útil realizado. Una máquina poco utilizada puede resultar cara por tarea; una máquina saturada puede imponer una espera incompatible con el servicio.
En ambos casos, evalúe la calidad con los mismos criterios. Trasladar un gasto a la infraestructura o posponer el procesamiento no basta para demostrar una reducción del costo completo.
Establecer presupuestos que realmente detengan el gasto
Defina límites por tarea, usuario, proyecto y período. Añada límites de pasos, llamadas a herramientas, duración y concurrencia. Estos controles cubren distintas causas de gasto excesivo: multiplicación de solicitudes, bucles sin avances o delegación excesiva.
El control debe estar en el código que autoriza las llamadas. Una instrucción que pida al modelo respetar un presupuesto no sustituye un contador externo. Una notificación informa de un consumo; un bloqueo impide un gasto nuevo.
Con solicitudes paralelas, reserve el costo máximo estimado antes de iniciarlas y después ajuste esa reserva al costo observado. Sin una reserva compartida, varias tareas pueden considerar, cada una por su cuenta, que el mismo saldo sigue disponible.
Una pasarela como LiteLLM puede centralizar estos controles. Su documentación de presupuestos, consultada el 24 de octubre de 2026, especifica que los presupuestos descritos requieren una base de datos y expone las limitaciones de las reservas, especialmente para los lotes. Compruebe los requisitos previos y el comportamiento ante fallos antes de considerar que el límite se aplica de forma efectiva.
Pruebe el rechazo de una llamada, la concurrencia y la indisponibilidad del contador. Prevea también una detención ordenada: guardar el estado, indicar qué queda pendiente y evitar anunciar que la tarea se ha completado con éxito cuando se ha interrumpido.
Aplicar cambios sin perder calidad
Empiece por un período de medición representativo y después clasifique las causas del gasto: contexto, salidas, herramientas, reintentos o recorridos innecesarios. Modifique un factor identificable cada vez para poder atribuirle el efecto observado.
Conserve una configuración de referencia y compare los resultados con los mismos casos. Después, compruebe el comportamiento con una cantidad limitada de tráfico real y la posibilidad de volver atrás. Un ahorro medido fuera de producción puede desaparecer cuando cambian las entradas o la concurrencia.
La comprobación final puede ser breve:
- El costo incluye los fallos, los reintentos, las herramientas y las correcciones humanas.
- Los criterios de aceptación son los mismos en todas las configuraciones.
- El ahorro de la caché y del enrutamiento se mide sobre el costo total.
- Los presupuestos bloquean de forma efectiva las llamadas nuevas.
- La detención conserva un estado utilizable e identifica las tareas incompletas.
Una reducción duradera depende de un proceso que complete el trabajo solicitado con menos procesamiento innecesario. Revise esta medición cuando cambien las tarifas, los modelos, los documentos o los requisitos de calidad.
Páginas relacionadas
Preguntas frecuentes
¿Qué modelo conviene elegir para un agente de IA económico?
Empiece por definir cuándo considera aceptable una tarea: precisión, uso correcto de las herramientas y ausencia de acciones indebidas. Después, compare varios modelos con los mismos casos e incluya también los reintentos. El precio por token, por sí solo, no permite identificar la opción más económica.
¿La caché evita pagar por el contexto de un agente?
Una parte del contexto puede tener una tarifa distinta cuando se reutiliza. Los datos nuevos y la generación siguen facturándose según las condiciones del servicio. Revise los registros de consumo en lugar de dar por hecho un ahorro por la mera existencia de una caché.
¿Una suscripción a un asistente incluye las llamadas a la API?
No dé por hecho que ambas formas de facturación cubren lo mismo. Compruebe qué autenticación utiliza su agente y qué contrato cubre ese consumo. Una suscripción, los créditos y una clave de API pueden tener alcances diferentes.
¿Un agente alojado en infraestructura propia cuesta menos?
Depende del uso y de los recursos necesarios para mantenerlo en funcionamiento. Compare el hardware o su alquiler, la electricidad, el mantenimiento y la capacidad disponible en los momentos de mayor demanda. Incluya también el tiempo necesario para alcanzar una calidad comparable.
¿Cómo se impide que un agente supere su presupuesto?
El control debe actuar antes de cada nuevo gasto, en el programa o la pasarela que autoriza las llamadas. Reserve un margen para las solicitudes ya iniciadas y comparta el contador entre las tareas paralelas. Una alerta enviada después del consumo no equivale a un límite de gasto.