1. The Cost Structure Changes Because the Work Changes, Not Just Because User Numbers Grow

In traditional conversational applications, a user asks a question, the model generates an answer, and one round of interaction is largely finished. Even with multi-turn dialogue, the pace is usually controlled by the human: read, judge, add information, and ask again.

Agentic applications change this process. The user provides only a goal, and the system may decompose the task, read materials, call tools, modify files, run checks, and continue based on the results. Multi-agent systems add division of labor, with planning, execution, and review roles handling different parts of the workflow.

As a result, one user request no longer maps to one model call. It may map to an execution graph that keeps expanding. The interface shows only a single instruction such as “complete this task,” while the backend may already have performed dozens of inference steps and tool interactions.

The source material mentions extreme costs for some high-intensity users and peak-period limit adjustments after subscriber growth. However, the statistical basis for those amounts is incomplete: it is unclear whether they use public prices or include internal resource consumption. They should not be treated directly as typical real-world bills, and they certainly should not be used to infer the operating condition of the entire industry.

The core issue worth discussing is this: when an application shifts from “answering questions” to “continuously working,” the method of understanding cost by conversation count no longer works.

2. Why Multi-Agent Systems Easily Amplify Token Consumption

A token is the basic unit a model uses to process text. There is no fixed conversion ratio between tokens and character count. Different languages, symbols, and code structures can produce different token counts.

To analyze agent costs, looking only at how many characters appear in the final output is not enough. You also need to examine what is repeatedly fed into the model throughout the execution process.

2.1 Historical Context Re-enters the Model

In common stateless inference APIs, the application must assemble the necessary context for each request. If the system keeps appending historical messages without trimming them, later calls will repeatedly carry earlier content.

Assume the initial context is B, each round adds an average of d tokens, and the system executes n rounds. Under a simplified condition that ignores caching, compression, and context-window truncation, cumulative input can be approximated as:

Cumulative input tokens ≈ n × B + d × n × (n − 1) ÷ 2

This formula shows that a small amount of new content per round does not necessarily mean low cumulative cost. In an implementation that continuously resends full history, input consumption may grow approximately quadratically.

This is not an inevitable law for all agent systems. It is an implementation risk that must be actively avoided.

2.2 Multi-Role Collaboration Creates Additional Communication

Assigning planning, execution, and review to separate agents can improve clarity of responsibility, but it also increases handoff costs.

For example, after an executor generates a long report, a reviewer needs to read the report, the task requirements, and relevant evidence. Review comments then need to go back to the executor. A final aggregator may read all the content again.

If every role shares the full history, a multi-agent system can easily degrade from “specialized division of labor” into “repeated reading.” Adding roles is valuable only when it improves task quality, reduces error rates, or shortens the critical path. More roles do not automatically make a system more advanced.

2.3 Tool Results Become Hidden Input

Directory listings, retrieval snippets, runtime logs, and query results are often much longer than user instructions. Once they enter the next model request, they also consume context and incur cost.

A common problem is that a tool only needs to return an error location but outputs a complete log. To locate the problem, the model then requests more logs. The system enters a loop of “information overload—difficult judgment—further retrieval.”

Tool output should be organized around decision needs rather than passing all raw information to the model by default.

2.4 Retries and Reviews Need Explicit Boundaries

Automatic retries can recover from temporary failures, but they cannot guarantee repair of incorrect reasoning. If the input information has not changed, repeatedly executing the same path may simply pay similar costs again.

Likewise, without a final arbiter among multiple agents, they may keep questioning, supplementing, and reworking each other for a long time. Reliability mechanisms must define trigger conditions, maximum attempts, and termination criteria. Otherwise, “checking one more time” becomes an execution chain without an upper bound.

3. Why a Fixed Subscription Price Does Not Mean Unlimited Compute

A fixed subscription fee provides a predictable purchase experience, but the underlying compute resources still have marginal costs.

The service provider must cover model inference, runtime environments, network transmission, storage, operations, and maintenance, while reserving capacity for peak traffic. Usage intensity can also vary widely: some users ask occasional questions, while others continuously run multiple autonomous tasks.

This difference creates a mismatch between fixed pricing and actual resource consumption. If a small number of heavy users consume a large share of resources, the provider usually needs usage quotas, concurrency limits, dynamic scheduling, or additional metered charges to maintain service.

Therefore, three concepts need to be distinguished:

• Subscription eligibility: which features and service permissions a user has.
• Usage quota: how many resources can be consumed within a given period.
• Service capacity: how much concurrent work the system can support at a given moment.

These three are not equivalent. Having remaining quota does not mean a user can obtain the same throughput at any moment. Being able to access a feature does not mean it can be called without limit.

It is not rigorous to conclude directly from current phenomena that “free services will inevitably disappear entirely.” A more reasonable judgment is that high-consumption, long-running, highly autonomous tasks are difficult to support long term through free supply without boundaries. Free entry points can exist, but they usually need to be paired with resource quotas, task scope, or service priority.

4. Why Limits Cannot Be Explained Only by “How Many Chats”

Users often want a simple answer: how many more messages can I send?

But agentic tasks vary greatly in resource consumption. A short question-and-answer exchange and a task involving a long document, multiple retrieval rounds, and code execution may both appear as one user message, but their underlying costs are completely different.

As a result, practical scheduling may need to consider:

• input and output size;
• context length;
• number of concurrent tasks;
• tool runtime;
• resource requirements of different models;
• current system load.

These are general scheduling dimensions. They do not imply that any specific service uses a particular billing rule.

For developers, the key is not to guess some hidden quota, but to treat capacity shortage as a normal system state. Tasks should support queuing, pausing, resuming, and cancellation. After a failed call, the system should use capped backoff retries. Important tasks need checkpoints so that recovery does not restart from the beginning.

5. Build a Cost Ledger Before Discussing Optimization

Looking only at a monthly total makes it difficult to determine where the budget is actually consumed. Effective cost governance requires linking a business task to all of its model calls, tool calls, and retries.

Record the following information by task:

Dimension	What to Record	Primary Use
Task attributes	Task type, business owner, priority	Compare input and output across scenarios
Model calls	Input and output tokens, call count, actual cost	Locate inference expense
Tool execution	Runtime, result size, failure reason	Identify tool-side bottlenecks
Workflow state	Steps, retry count, termination reason	Detect runaway loops
Business result	Acceptance status, manual edits, completion time	Judge whether the cost is worthwhile

If the service distinguishes normal input, cached input, and other billing items, account for them separately according to the actual bill. Do not replace them with a single uniform price.

A more important metric is:

Cost per effective result = total cost in the measurement period ÷ number of results accepted by the business.

A cheap call that frequently fails is not necessarily more economical than an expensive call that reliably completes the task. Cost analysis must be performed together with quality, latency, and manual rework.

6. Design Bounded Agent Execution Mechanisms

6.1 Set Multi-Dimensional Budgets for Tasks

Limiting only token count is insufficient because tool execution can also incur significant costs. Set limits on cost, call count, tool count, runtime, and concurrency at the same time.

Budget checks should happen before calls, not only after settlement. Practical implementations also need a safety margin, because before a request completes, the final output volume and total cost usually cannot be known precisely.

For parallel tasks, use a unified budget ledger. Reserve budget before dispatching subtasks and settle according to actual consumption after completion. This prevents multiple executors from simultaneously believing that “the balance is sufficient.”

When the budget is exhausted, the system should save progress and explain what has been completed and why the task cannot continue, rather than returning only a failure message.

6.2 Set Verifiable Stop Conditions for Loops

“Until the result is good enough” is not a reliable termination criterion.

More suitable conditions include: all predefined checks pass, necessary evidence is available, several consecutive attempts produce no meaningful progress, or the budget boundary is reached.

For open-ended research tasks, define the delivery scope clearly. For modification tasks, define which objects may be changed and what acceptance rules apply. The clearer the task boundary, the fewer invalid explorations are usually required.

6.3 Add Approval for High-Risk Actions

Reducing manual involvement does not mean removing human control. Operations that delete data, send information externally, or incur significant costs should have independent approval points.

This is not only a security requirement but also a cost-control measure: preventing an incorrect action from spreading is usually more economical than repeatedly repairing it afterward.

7. Reduce Invalid Context, Not Blindly Shorten Prompts

The goal of context governance is to retain the information useful for the current decision.

First, store the task goal, current state, evidence materials, and full history separately. When the model handles the current step, it reads a curated state summary and necessary evidence. Raw materials remain in external storage and are retrieved on demand.

Second, prioritize deterministic trimming. For example, filter successful logs, return only necessary fields, and remove duplicate fragments before considering model-generated summaries. Summarization itself has a cost and may omit critical constraints.

Third, multi-agent handoffs should use structured records containing at least the conclusion, evidence location, uncertainty, pending items, and stop reason. Do not copy an executor’s entire history directly to another executor.

For repeated and stable context, caching mechanisms can be evaluated. However, whether a cache hits, how it is billed, and whether it meets isolation requirements must be based on the actual service rules.

8. Parallelism and Model Tiering Must Prove Value Through Evaluation

Parallelism can shorten waiting time, but it usually increases peak resource usage and may amplify duplicate work.

Tasks suitable for parallelism should have clear boundaries, be independent of one another, and be separately acceptable. If multiple executors keep modifying the same object, coordination and conflict handling may offset the benefits of parallelism.

Model tiering follows the same principle: simple classification and format cleanup tasks can try models with lower resource requirements, while complex planning and high-risk judgments can use stronger capabilities based on evaluation results.

However, if a low-cost model causes more retries and manual rework, the overall cost may be higher. The right approach is to compare completion rate, total cost, elapsed time, and edit volume on a representative task set before deciding how to route work, rather than comparing only the price per call.

9. From “More Calls Means More Intelligence” to “More Effective per Result”

The value of multi-agent systems lies not in how many roles are started or how many tokens are consumed, but in whether the system can complete business goals at an acceptable cost, time, and risk.

Enterprise adoption can follow four steps: first select a scenario with clear acceptance criteria, then establish observability for calls and costs; next run a small-scale pilot under a hard budget; finally use real results to decide whether to increase parallelism and automation.

The pressure on free-access and fixed-subscription models essentially comes from the conflict between continuous execution capability and limited resources. Developers cannot simply wait for unit prices to fall. They need to incorporate budgets, context, retries, and acceptance into system design.

A truly mature agent not only knows what to do next, but also knows when to stop, when to ask for help, and whether continuing execution is worthwhile.