Article 1 · AI agent costs
Same model.
A smaller API bill.
Your agent finishes the task. The answer is useful. The trace shows the same instructions sent again, a document loaded for one fact, a large tool response copied into another call.
That is where to start looking for savings.
Keep the model you chose for its quality. Examine what it reads, generates and repeats. Aim for a lower bill with results that pass the same checks.
Decide what “the same result” means
For an order lookup, it might mean the correct order, delivery status and supporting record. For a document review, it might mean every required finding, with evidence. Record these requirements before changing the agent.
Hold the model version and generation settings fixed. Compare both workflows on the same tasks and source data. Identical wording is a separate requirement: using the same model does not by itself guarantee an identical response.
A shorter answer that leaves out a required finding fails the comparison. So does a cheaper call that creates another round of corrections.
Two ways to shrink the bill
You can send and generate fewer tokens, or pay a lower rate for repeated input that qualifies for the provider’s prompt cache. Your measurements should separate these mechanisms.
Caching can reduce the bill while the input token count stays the same. Filtering a large tool response can reduce the input token count itself. Both deserve a test; neither justifies a savings percentage before you have measured your workload.
Keep reusable context reusable
In its context engineering article, Manus explains why a stable prompt prefix matters. A changing timestamp near the start, inconsistent serialization or edits to earlier observations can break cache reuse.
Keep shared instructions and tool definitions consistent. Put request-specific material after the reusable portion where the API permits. Check cache requirements and expiry, then inspect reported usage.
Measure warm and cold requests. Include cache creation charges where they apply. A cache that expires between your requests may deliver very little benefit.
Let code carry the data
Anthropic’s article on code execution with MCP describes processing intermediate data in an execution environment before returning selected information to the model. It shows the cost of copying large payloads through model input and output.
Consider an illustrative order-status task: has the order shipped? The source returns a large record with line items, addresses, internal events and delivery updates.
A tool can select the order identifier, shipment status, relevant timestamp and source reference. The model receives what it needs to answer. Keep the full record accessible for exceptions, conflicting updates or follow-up questions.
That selection must follow the task. If the question concerns partial shipment, dropping line items may remove the evidence that decides the answer. Send enough evidence for the required decision.
For a transfer between systems, code can pass the original payload directly and return a confirmation. The model need not reproduce every character. The same model still directs the task; ordinary data movement happens in the execution environment.
Load tools carefully
Anthropic describes discovering tool definitions as needed. Manus highlights a competing concern: changing definitions early in a running conversation can invalidate a reusable prefix and make previous tool references harder to interpret.
Test whether a compact discovery interface saves more than it costs in extra calls and lost cache reuse. Keep definitions stable where that helps. Measure the full task, including discovery.
Preserve a route back to the evidence
Manus describes moving material out of active context while keeping it recoverable through files or source references. Remove repeated bulk while preserving access to the original.
An agent reviewing a report may need selected passages now and another section later. Retain a stable reference to the source version used in the test, so a later read can recover the same evidence.
Keep useful failure evidence too. If a tool rejected a request, the next step needs enough information to avoid repeating it. Erasing every error can make the trace look tidy while leaving the agent to rediscover the same problem.
Count the cost of finishing
Use one measure alongside quality and response time:
Total API spend ÷ accepted tasks = API cost per accepted task.
Include failed attempts, retries, discovery calls and any summarization calls. Reconcile uncached input, cache reads and writes, output and any other billed usage against your provider’s records without counting overlapping categories twice.
Also record execution and storage costs introduced by the change. They affect whether the change is worth keeping.
Track tokens per call alongside total cost per accepted task.
Run one controlled comparison
This is the first experiment we recommend from these mechanisms:
- Select a representative set of real tasks, including difficult cases and failures. Fix the source data, model version, settings and acceptance criteria.
- Record the existing workflow’s accepted results, billed usage, retries and end-to-end response time.
- Change one thing: stabilize the prefix, filter one oversized tool response, or remove one unnecessary payload copy.
- Replay both versions under comparable conditions. Repeat enough runs to see variability, and account for cold and warm caches at the frequency your product uses them.
- Inspect quality failures individually. Keep the change only if the comparison supports the required quality and response time at a lower total cost.
The first trace to inspect is one from a task your agent already completes well. Find the repeated work inside it. That gives you a concrete savings hypothesis with a result you can check.