You Don’t Pay for the Answer: Bedrock Agent Request Costs
A 100-token question to a Bedrock agent costs 30 times more than the question plus the answer. I measured where the tokens go and which two levers cut the bill by 70%.
Ask most teams what a Bedrock request costs and they multiply the question and the answer by the token price. For a 100-token question and a 500-token answer on Claude Sonnet 5.5, that is half a cent.
The real number for an agent that uses six tools to answer is $0.15. Thirty times more. The answer is only 13% of that bill. The rest is the model re-reading the same conversation seven times.
Why an agent request is not one request
A chatbot sends one prompt and gets one answer. An agent works in a loop: the model decides to call a tool, the tool returns a result, and the model is called again with everything so far, until it is ready to answer. Six tool calls mean seven model calls.
Models have no memory between calls. Every call sends the full context again: the system prompt, the definitions of every tool the agent can use, the question, and every earlier tool call and result. You pay input price for all of it, every time.
What I measured
I connected to the AWS MCP Server, the managed MCP server that gives an agent AWS documentation, AWS APIs and curated skills, and measured the two things that dominate an agent's context.
Tool definitions. The server exposes eight tools. Their names, descriptions and input schemas from tools/list are 11,814 characters, about 2,950 tokens. They go into every model call, whether the agent uses a tool on that turn or not.
Tool results. Five search_documentation calls on everyday topics (Lambda MicroVMs, S3 bucket policies, EC2 instance types, Bedrock AgentCore, DynamoDB TTL) returned between 4,518 and 8,702 characters. The median was 6,361, about 1,590 tokens per result.
For the rest I used round, labelled assumptions: a 1,000-token system prompt, a 100-token question, 250 output tokens per tool-calling turn and a 500-token final answer. Prices are Claude Sonnet 5.5 list prices per million tokens: $2 input, $10 output, $2.50 cache write and $0.10 cache read. Token counts use 4 characters per token.
Where the money goes
Three things stand out.
| One request, six tool calls | Tokens | Cost |
|---|---|---|
| What people estimate: question + answer | 100 in, 500 out | $0.005 |
| What the agent sends: 7 model calls | 67,018 in, 2,000 out | $0.154 |
| of which tool definitions, re-sent 7 times | 20,678 in | $0.041 (27%) |
| of which the model's own output | 2,000 out | $0.020 (13%) |
| Same request with prompt caching | 67,018 in, 2,000 out | $0.059 |
Input, not output, is the bill. 87% of the cost is the model reading, not writing. Optimizing the length of the answer barely moves it.
Tool definitions are a fixed tax. More than a quarter of the request pays for describing eight tools seven times. Connect three MCP servers instead of one and that tax triples before the agent does any work.
Cost grows faster than the work. Each tool result is read again by every later call, so the bill grows with the square of the number of steps, not in a straight line.
Two levers that matter
Cache the prefix. With prompt caching, the part of the context the model has already seen is billed at the cache-read price, a twentieth of the input price. The same six-tool request drops from $0.154 to $0.059, 61% less. At 24 tool calls it drops from $1.37 to $0.23. If your agent framework supports cache points, this is the first switch to flip.
Keep tool results short. A tool result is not paid once; it is paid by every call that follows it. Halving the size of each result, for example by asking for fewer search hits or returning only the fields the agent needs, takes the uncached request from $0.154 to $0.121. Together with caching, it lands at $0.046, 70% below where it started.
At 1,000 such requests a day, the difference between the first and the last row is about $3,200 a month, for the same answers.
The decision I would argue for
Budget agents per request, not per month, and measure the input tokens of every model call, not the size of the question. A monthly Bedrock line item tells you that you spent money. The usage block that every Converse response returns (input, output, cache read and cache write tokens) tells you why.
The limits of this calculation: one model, one MCP server, fixed result sizes and a single scenario. Your system prompt, your tools and your model change every number in the table. The shape will not change: the more steps an agent takes, the more of your bill is the model re-reading its own history.
Try it
The calculator and the measured inputs are in CODE . Change the tool definition size, the result size, the number of steps or the prices, and it prints the cost of one request with and without caching.
You don't pay for the answer. You pay for re-reading the conversation, so cache what repeats and keep what the tools return short.
Sources
- The AWS MCP Server is now generally available (tools, IAM, no additional charge for the server): https://aws.amazon.com/blogs/aws/the-aws-mcp-server-is-now-generally-available/
- AWS MCP Server endpoints: https://docs.aws.amazon.com/general/latest/gr/aws-mcp.html
- Amazon Bedrock pricing: https://aws.amazon.com/bedrock/pricing/
- Claude Sonnet 5.5 list prices: https://openrouter.ai/anthropic/claude-sonnet-5.5 and https://aiidelist.com/blog/sonnet-5-5-bedrock
- Amazon Bedrock prompt caching: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article