Token Cost Governance for Multi-Agent Coding

Why Multi-Agent Systems Consume So Many Tokens

The cost of a single-turn Q&A interaction is roughly proportional to input length, output length, and number of calls. Once a task is split across planning, retrieval, coding, review, and testing roles, the same requirement gets loaded into context repeatedly: upstream conclusions are passed back, and downstream roles insert code, logs, and failure information again. Add long sessions, automatic retries, and parallel exploration, and the number of calls often does not grow linearly. It scales as “number of roles × number of rounds × number of branches.”

For developers, the pain point is usually not that the model is insufficiently smart. It is that the bill cannot be attributed. A seemingly simple change may trigger file reads, code search, test runs, and further edits based on errors. Every hop pays a context tax. On the enterprise side, two concerns matter more: whether spending may approach or even exceed the marginal cost of equivalent human labor, and whether free or low-cost quotas can still support production-grade usage. A clear industry trend is already visible: as agents move from demos into daily delivery, usage-based pricing replaces the expectation of unlimited use, and free tiers mostly cover lightweight trials.

Where Costs Leak

An agent task can be broken down into four categories of expense, which makes it easier to attribute costs against logs.

1. Context bloat. System prompts, repository conventions, conversation history, and whole-file pastes are billed repeatedly in every round. Long context is not always more accurate; irrelevant passages dilute attention and increase latency.
2. Tool round trips. If the results of file reads, retrieval, and command execution are fed back verbatim, build logs and irrelevant stack traces can easily be carried into the next round in full.
3. Parallelism and retries. Running competing approaches or blindly rerunning after failure consumes tokens repeatedly without adding new information. Without stop conditions, agents tend to spin idle.
4. Model and output mismatch. Simple retrieval or format cleanup is sent to the strongest model, or the agent is asked to generate an extremely long patch in one pass and then rewrite the whole thing after failure.

These mechanisms do not depend on any specific product form. As long as the workflow is “multiple roles + long memory + tool loop,” it should be designed for high consumption by default rather than having a budget added after launch.

Start with Explainable Metering

Without metering, there is no governance. At minimum, record: task identifier, calling role, model tier, input and output size, whether cache was hit, tool name and result summary length, retry count, and associated requirement or merge request. Aggregate bills by project, repository, and person rather than looking only at the account total.

In practice, use “budget envelopes”:

• Per-task hard limit: stop the automatic loop when exceeded and require human confirmation before continuing.
• Daily or per-iteration soft limit: when approaching the threshold, downgrade the model, shorten context, or disable parallel branches.
• Anomaly alerts: sudden spikes in calls per unit time, repeated retries on the same error, and abnormal output length should all trigger monitoring alerts.

General cloud capabilities are sufficient to support this chain: logging services store call details, object storage archives raw traces, and monitoring alerts connect to budget thresholds. There is no need to bind to a proprietary interface; the key is stable fields and traceability. If a team uses a cloud platform such as Baidu AI Cloud, agent calls should still be managed as ordinary observable workloads rather than bypassing existing cost centers.

A sample single-call record can be simple:

task_id, role, model_tier, input_tokens, output_tokens,
cache_hit, tool, retry, stop_reason

Field meanings can be defined by internal conventions. Avoid inventing a unified API that does not exist.

Reduce Consumption Without Sacrificing Correctness

The goal of governance is to reduce invalid tokens, not to blindly shorten prompts and cause rework.

Context should be layered. Stable coding standards and directory conventions can go into a cacheable prefix; for the current round, inject only relevant file snippets, function signatures, and failing test cases instead of a whole-repository snapshot. Summarize conversation history in a rolling way: keep decisions and open questions, and drop outdated intermediate drafts. Trim tool results before feeding them back. For logs, keep the error signature, key line numbers, and the shortest reproduction rather than the full console output.

Route by difficulty, not by habit. Use smaller models for classification, extraction, unit-test naming, and comment cleanup; use high-capability models for architecture tradeoffs, cross-module defects, and security-sensitive changes, with narrow-scope review. Limit the number of parallel exploration branches, and require each branch to state how it differs from existing options. Discard duplicate approaches directly.

Stop conditions should be written into the loop rather than relying on someone watching. For example, exit and provide a human-readable status when two consecutive test results show no change, when the patch scope exceeds the authorized directory, or when the same error reaches the retry limit. The review role should not rewrite the entire implementation again; it should output diff comments and must-fix points only.

Caching should distinguish what can be reused. The same prefix, the same retrieval question, and passed static-check conclusions can be reused; content involving secrets, personal data, or one-off experiment logs should not enter a shared cache. Cache hits should be reflected in metering; otherwise, there is no way to prove that savings are real.

Evaluate Quality and Cost Together

Squeezing tokens alone creates false optimization: saving money but increasing rework. Compare against the same set of internal tasks: pass rate, number of human-modified lines, first-pass success rate, average number of call rounds, and tokens per task. If cost decreases while rework increases, add budget back to the critical path instead of continuing to downgrade.

Free quotas are suitable for smoke tests and teaching, not as a delivery assumption. Teams should assume the production path is paid, capped, and auditable by default. Write “stop when quota is exhausted” as a runtime policy to prevent agents from maxing out an account unattended. Procurement should compare cost per effective result, such as the average spend per merged qualified change, rather than comparing advertised unlimited quotas.

Rollout Order

In the first week, add logging and hard limits to stop idle loops. In the second week, implement context layering and tool-result trimming; this is usually the highest-return step. In the third week, introduce model routing and caching, and validate with a fixed task set to confirm that the pass rate remains stable. Organizationally, assign a cost owner and treat abnormal calls like code defects: reviewable, reproducible, and fixable through process changes.

Multi-agent systems do not automatically become cheaper just because the interaction interface changes. Costs come from repeated context, unbounded loops, and overly heavy models. Once metering, budgets, trimming, routing, and stop conditions become engineering standards, token spending can move from an uncontrollable bill to a delivery cost that is as plannable as labor and compute.