Empezaste con un solo agente de programación. Ahora Claude Code corre en una terminal, Codex en otra y Gemini CLI en una tercera. Cada uno factura según sus propias reglas: una suscripción aquí, una clave de API medida allá, y un nivel gratuito que la semana pasada se convirtió silenciosamente en uso de pago. A fin de mes tienes tres facturas y ninguna respuesta a una pregunta sencilla: ¿cuánto costó realmente construir la funcionalidad de la semana pasada?
La gestión de costes de los agentes de programación es la práctica de atribuir el gasto de los agentes al trabajo que lo generó y, después, mantener ese gasto visible y revisable en todas las herramientas que usa tu equipo. La parte difícil no es el precio por token de un agente concreto. Los precios cambian, y cada proveedor los publica. La parte difícil es que el gasto se fragmenta entre sistemas de facturación distintos en cuanto usas más de un agente, de modo que nadie puede vincular una cifra concreta a una tarea, un repositorio o una persona.
Este artículo repasa de dónde vienen realmente los costes de cada herramienta, las palancas que sí controlas y cómo una capa de gestión como Sharkly mantiene visible el gasto por tarea sin pedirte que abandones las herramientas que ya usas. Sharkly se sitúa por encima de los agentes. Conservas tus suscripciones de Claude Code, Codex y Gemini, y el registro de cada ejecución vuelve a la Task a la que pertenece.
Qué significa gestionar costes cuando usas tres agentes
Con un solo agente, el coste es un número que puedes leer en un panel. Con tres, el coste se convierte en un problema de coordinación. El gasto es real, pero vive en tres sitios que nunca cuadran entre sí: el uso de Claude Code de Anthropic, una página de facturación de OpenAI para Codex y un proyecto de Google Cloud para Gemini.
Conviene dejar clara una frontera. Gestionar costes no es lo mismo que reducir costes. Reducir el gasto significa usar menos tokens. Gestionar el gasto significa saber adónde fueron los tokens y decidir si mereció la pena. Puedes tener un mes caro a propósito, publicando tres funcionalidades en paralelo, y seguir teniendo el control, siempre que puedas atribuir el gasto y alguien lo haya aprobado.
Esa atribución es la capa que falta. La mayoría de los equipos que usan varios agentes pueden decirte su factura total de IA y nada más granular. No pueden decir qué repositorio, qué ingeniero o qué tarea lo provocó. Cuando el gasto es invisible a nivel de tarea, las conversaciones sobre costes se convierten en conjeturas, y la reacción habitual es limitar la herramienta que resulta más fácil de ver en lugar de la que realmente se está comiendo el presupuesto.
De dónde vienen realmente los costes de las tres herramientas
Cada agente cobra más o menos por lo mismo, tokens de entrada y tokens de salida, pero el modelo de facturación difiere lo suficiente como para cambiar la forma de presupuestar. Comparadas en su mejor versión, ninguna es simplemente más barata que las demás. Son más baratas para distintos tipos de trabajo.
| Herramienta | Modelo de facturación habitual | Qué dispara la factura |
|---|---|---|
| Claude Code | Plan de suscripción o clave de API de Anthropic | Sesiones agénticas largas, ventanas de contexto grandes, lecturas de archivos repetidas |
| Codex | Plan de suscripción o clave de API de OpenAI | Tareas con mucha carga de razonamiento, alta concurrencia, bucles de llamadas a herramientas |
| Gemini CLI | Nivel gratuito y, después, una clave de API de Google Cloud | Tareas de contexto grande una vez superada la asignación gratuita, llamadas de imagen y multimodales |
Los modelos de suscripción ocultan el coste marginal. Un plan mensual de tarifa plana se siente gratis en el margen, así que los ingenieros recurren a él constantemente, y la pregunta real pasa de “cuánto costó esto” a “estamos alcanzando los límites del plan”. Los modelos de clave de API medidas hacen lo contrario: cada ejecución tiene un precio visible, lo que simplifica el presupuesto, pero tienta a los equipos a infrautilizar un agente capaz para ahorrar céntimos.
Usa un plan de suscripción cuando una o dos personas ejecutan un agente de forma constante a lo largo del día y la facturación predecible importa más que el detalle por tarea. Usa una clave de API medida cuando necesites atribuir el gasto con precisión, ejecutar en automatización o repartir el trabajo entre un equipo en el que alguien tenga que responder del total. Muchos equipos acaban teniendo ambas cosas, que es justo por lo que importa una única vista conciliada. Si estás eligiendo qué agente se encarga de cada trabajo, emparejar los modelos con las tareas hace más por tu factura que cambiar de proveedor.
Las tres palancas que sí controlas
Los precios de los proveedores no son una palanca; no puedes negociarlos desde una terminal. Hay tres cosas que están genuinamente en tus manos, y importan más que el precio de etiqueta.
Disciplina de contexto. El mayor coste evitable es reenviar contexto que el agente ya tenía. Un agente que vuelve a leer todo el código base en cada turno paga por ese código base en cada turno. Persistir el contexto entre ejecuciones, de modo que el agente arranque desde el estado actual en lugar de reconstruirlo, suele ser el mayor ahorro de todos. Es el mismo mecanismo que hay detrás de la memoria del código base y su coste en tokens: lo que conservas, no lo vuelves a comprar.
Emparejar el modelo con la tarea. Enrutar un cambio de nombre de una línea a un modelo de razonamiento pesado es tirar el dinero, y enrutar una refactorización arquitectónica a un modelo pequeño y rápido es tirar una tarde. El ahorro viene de ajustar el modelo a la tarea en lugar de asignar por defecto cada trabajo a tu agente más capaz.
Límites del paralelismo. Ejecutar agentes en paralelo es donde está la verdadera ganancia de productividad, y también donde el gasto se multiplica más rápido. Cinco agentes trabajando a la vez cuestan aproximadamente cinco veces más por unidad de tiempo real. Eso está bien cuando hay cinco tareas listas y merece la pena, y sale caro cuando tres de ellas eran especulativas. La palanca no es “ejecutar menos agentes”. Es decidir, antes de lanzarlos, qué trabajo merece una plaza en paralelo. Monitorizar agentes que se ejecutan en paralelo es lo que convierte esa decisión en una apuesta defendible en lugar de una conjetura.
Una tabla de decisión según el tamaño del equipo
La ecuación de costes cambia según cuántas personas y agentes estés coordinando. Lo que vale para un desarrollador en solitario se convierte en un lastre para un equipo de plataforma.
| Forma del equipo | Dónde vive el coste | Qué optimizar |
|---|---|---|
| Desarrollador en solitario, uno o dos agentes | Uno o dos paneles que puedes leer directamente | Facturación predecible; un plan de suscripción suele bastar |
| Equipo pequeño, varios agentes | Fragmentado entre suscripciones y claves por persona | Atribución: saber qué trabajo provocó el gasto |
| Equipo de plataforma o de ingeniería | Muchos repositorios, muchos agentes, presupuestos compartidos | Visibilidad, revisión y coste por tarea que se consolida en un responsable |
Si trabajas en solitario y te apañas en una terminal con un solo agente, no necesitas una capa de gestión para controlar el coste. Tu panel ya te dice lo que necesitas. La ecuación cambia cuando el gasto supera una única vista: varios agentes, varios repositorios y un presupuesto del que alguien distinto de ti tiene que responder. En ese momento la pregunta deja de ser “qué agente es más barato” y pasa a ser “quién puede ver el conjunto y decidir”.
Hacer visible el gasto por tarea
Esta es la capa para la que está construido Sharkly, y conviene ser preciso sobre lo que hace y lo que no hace. Sharkly no es una herramienta de facturación ni sustituye a Claude Code, Codex o Gemini. El uso del modelo sigue produciéndose a través de las suscripciones o claves de API configuradas en esas herramientas; tú aportas tu propia suscripción. Lo que añade Sharkly es el registro compartido en torno a ellas: cada ejecución de un agente ocurre dentro de una Task, y la ejecución, el progreso, los bloqueos y los resultados vuelven a esa Task donde el equipo puede verlos.
Ese registro compartido es lo que hace legible el coste. Cuando cada ejecución va asociada a una Task con un responsable y un repositorio, el gasto deja de ser un total mensual anónimo y pasa a ser un conjunto de decisiones que puedes señalar. Puedes ver qué trabajo se está ejecutando, en el Computer de quién y contra qué presupuesto, desde la petición hasta el lanzamiento. Un panel de agentes de programación que te muestre qué se está ejecutando es la diferencia entre gestionar el gasto y descubrirlo después de recibir la factura.
El contrato entre humanos y agentes también se aplica aquí. Los agentes investigan, ejecutan, prueban e informan. Las personas marcan la dirección, conceden autoridad y deciden si el gasto mereció el resultado. La automatización se detiene donde hace falta el criterio del equipo, lo que en materia de costes significa que una persona, no un script, decida que una ejecución en paralelo de cinco agentes está justificada antes de que empiece.
Si quieres seguir usando varios agentes de programación en lugar de comprometerte con un único ecosistema para simplificar la facturación, ese es el problema en torno al cual está diseñado Sharkly. Ejecuta tus agentes de programación actuales a través de Sharkly y deja que el coste de cada ejecución vuelva a la tarea que lo provocó.
