Cost receipts belong to the request
An agent cost record is useful only when it follows one user request through every model invocation and tool call.
Every user request needs one cost receipt that survives the full tool-use trajectory. A monthly token total can describe the bill, but it cannot show which request caused the spend, which model incurred it, or where repeated model invocations enlarged it. AWS makes the operational case plainly: understanding workload cost begins with per-request observability.
A token is a small unit of text that a model processes and providers use for billing. A tool call is a request the agent sends to another system, such as a search service or database, so it can gather information or take an action. The cost record has to follow the request across both. Otherwise the expensive part of an agent run disappears between rows.
One request can contain four model bills
The accumulation is easy to miss because a tool-using agent can send its growing conversation back to the model after each tool result. AWS gives a worked example with three tool calls and four model invocations. Its arithmetic is:
| Model invocation | Request trajectory | Input tokens billed | Running input total |
|---|---|---|---|
| 1 | Initial user request | 100 | 100 |
| 2 | After tool call 1 | 200 | 300 |
| 3 | After tool call 2 | 300 | 600 |
| 4 | After tool call 3 | 400 | 1,000 |
The first 100 tokens did not turn into 1,000 tokens inside one invocation. The request accumulated four separately billable input loads: 100 + 200 + 300 + 400 = 1,000. AWS describes that total as ten times the input tokens in the original request. A record attached only to the opening prompt would miss 900 of them.
The receipt needs the whole trajectory
The minimum useful receipt has five parts:
- Request identity. A stable identifier joins the user’s request to every later invocation, tool event, retry, and final answer.
- Selected model. Record the model used for each invocation, because one request may cross model boundaries.
- Per-invocation usage. Keep input and output token usage for every model call, including zero values, instead of retaining only a request-level token total.
- Tool-call sequence and count. Preserve the ordered tool events and the final count so an operator can reconstruct where the trajectory expanded.
- Total request cost. Sum the priced usage across the completed, failed, or stopped trajectory and attach the total to the same request identity.
AWS similarly recommends recording input tokens, output tokens, model ID, and tool-call number each time an agent requests a tool. The receipt above adds the join key and final cost that make those events accountable as one request. Partial and failed runs still need a total. They consumed resources even when no answer reached the user.
This is an observability rule, not a model-routing framework. The separate model-routing analysis asks how workload and serving evidence should influence model selection. A request receipt supplies some of that evidence, but its first job is simpler: keep the spend attributable through execution.
One author’s workload is not a price benchmark
AWS author Mike George reports a test of a social-services agent using expected prompts. In that author’s stated workload, requests cost about $0.006 with Claude Haiku 4.5 and $0.14 with Claude Opus 4.8, and the author reports equivalent results in his testing. Those figures are results from one AWS-authored example, not universal benchmarks, model rankings, or forecasts for another workload. Prompt mix, tool behavior, trajectory length, model pricing, and output requirements can all change the receipt.
AWS and Anthropic are neither Muniment customers nor endorsers. Their names identify the source and models in the example.
An aggregate bill still matters to finance. The request receipt is what lets an operator explain it before the next invoice has to do the explaining.