Multi-agent systems make cost tracking harder because calls, tools, hosting, data movement, and agent communication can compound across a run.
2
Teams can track costs with granular API logs and dashboards that break spending down by agent, model, task, user interaction, and token use.
3
Model tiering, prompt and task optimization, caching, structured agent communication, and evaluation can reduce spending without losing the required task performance.
Summary
Rashad explains why multi-agent systems are harder to cost than single-agent applications. A run may include several model calls, hidden calls caused by natural-language communication, paid external tools, self-hosted infrastructure, and data storage or network charges. These costs can compound as agents cascade and run in parallel. He recommends logging every call with its source, agent, task, model, tokens, duration, and latency, then building dashboards for cost by agent, model, task, and user interaction. His cost controls include routing tasks to different model tiers, reducing redundant prompt tokens, caching context and responses, using structured messages between agents, summarizing large contexts, and reducing the number of workflow steps. In the discussion, he says reliable evaluation is required before changing models, prompts, or tools in production. The talk is practical, though it does not provide a worked cost calculation or measured savings figure.
Multi-agent systems create more cost paths than single-agent systems
Rashad compares the shift from monoliths to microservices with the move from single-agent to multi-agent systems. Once several agents communicate with one another and with users, it becomes harder to see everything happening in a run. The first task is to understand the architecture and pipeline, then calculate cost across variable inputs, variable outputs, and multiple calls. He says even ordinary LLM costing is already difficult, so an agent system needs a more detailed view of where spending occurs.
The first cost driver is the LLM API call, including the number of calls, model tier, tokens, and call frequency. Inter-agent communication adds hidden calls when agents exchange natural language instead of programmatic messages. External tools such as search APIs add another charge per use. Self-hosted models bring server or platform costs, while systems handling very large message volumes must also account for data ingress, egress, storage, and networking. Parallel and cascading agents can make these costs compound.
Rashad recommends logging each API call with its origin, timestamp, agent, task, model, input tokens, call duration, and latency. This gives a team enough detail to connect spending to a particular part of a run. He then suggests a cost dashboard, built in-house or with an LLM operations tool, that shows total cost over time, cost per agent, cost per model, cost per task, cost per user interaction, and token-consumption trends. The purpose is to find changes and expensive paths rather than rely on a single total.
Model tiering routes simple work to cheaper models
Different tasks need different levels of model capability. Rashad gives summarization and intent prediction as examples of work that may not need the same model as code generation or a reasoning task. An orchestrator can choose a model from the task type instead of hard-coding one model throughout the system. He also describes a cascade in which a cheaper model handles early processing, such as data cleaning, and only the higher-value information reaches a more expensive model. This reduces the number of tokens sent to the expensive model.
Prompt changes can lower cost when they remove redundant instructions, examples, or output content. Rashad suggests limiting the output format, such as using JSON, when that reduces unnecessary tokens. The savings can matter when many prompts run across several agents and repeat throughout a task. He calls caching the hardest part of the approach, since teams may cache responses or inputs and avoid sending the full context or a previous result again. A basic team-managed cache can come first, followed by a specialized solution.
Structured communication keeps agents from passing expensive context
Rashad recommends using JSON for inter-agent messages and avoiding natural-language communication when it does not add value. When one agent must pass a large context to another, the system can summarize it, store it in a vector database, or put it in another form of memory. The goal is to avoid sending all of the same tokens in the neighboring agent's next request. This is a separate optimization from choosing a cheaper model because it changes how much information moves between agents.
Reducing workflow steps can cut the total number of requests
Rashad says many tasks use more calls than they need. Teams can reduce cost by changing the prompt and workflow structure so the same work happens in fewer steps. This is task-level optimization: rather than only making an individual call cheaper, it lowers the total number of requests made during the run. In a multi-agent system, reducing repeated or unnecessary steps can affect every downstream call, so the workflow design itself becomes part of the cost calculation.
Evaluation is required before switching models in production
In the discussion, Demetrios Brinkmann asks whether replacing a larger model with a smaller one can cause a performance cost that outweighs the savings. Rashad answers that proper evaluation is needed for any production agentic or multi-agent system. Evaluation supports model changes, prompt updates, and tool-calling changes, but he says correct LLM evaluation is difficult and differs from older machine-learning evaluation. Without a reliable task-specific evaluation layer, a team cannot know whether a cheaper model still performs accurately enough.
"The main thing that we are trying to figure out, after figuring out how to architect your agent or agents in this case, how to build the whole pipeline around it, is actually how can you calculate the cost correctly."Rashad00:52
Who should watch
You are building a multi-agent application and cannot explain which agents, tools, or workflows are driving its model bill.
Your team needs a practical cost dashboard and logging scheme before scaling an agent system.
You are considering smaller models or fewer workflow steps and need evaluation evidence before accepting a performance tradeoff.
