Why does one agent task make multiple model requests?
Planning, parallel tool calls, tool results, evaluation, and the final reply each participate in an iterative request loop.
Loading the calculator. If it does not appear, refresh the page or check that JavaScript is enabled.
Input is the new or rewritten content triggering this request; Context is the full prompt billed by the model. Output includes reasoning.
| Turn | # | Request | Input | Response | Output | Context | Fresh input | Cache read | Cache write | Cost |
|---|
An agent can make several model requests for one user task. Each request can resend the growing conversation, add tool results, and receive a new response. The simulator models that request loop instead of multiplying one prompt by a token price.
These boundaries matter most when interpreting the estimate.
Models standardized agent tool cycles using representative token averages rather than mirroring any proprietary agent framework verbatim.
All turns run on the selected primary model rather than routing planning, summarization, or background tasks to cheaper satellite models.
Actual cloud invoices vary with retrieved-content size, cache hit distributions, tool argument verbosity, and vendor rounding policies.
Planning, parallel tool calls, tool results, evaluation, and the final reply each participate in an iterative request loop.
Cache read is a reused prompt prefix billed at the provider's cache-hit rate instead of the ordinary input rate.
Some providers populate caches automatically. Their cache misses bill as Fresh input rather than through a separate Cache write meter.
The agent resends prior messages and adds tool results or other new content until compaction reduces the retained history.
It is a request-level scenario estimate. Actual bills depend on real token sizes, cache behavior, retries, routing, and vendor pricing rules.