AWS explains how to measure Amazon Bedrock agent cost per task, not per token

AWS published the second part of its Amazon Bedrock cost series on 12 November 2026. The post argues that builders should compare models by what a whole task costs, not by price per token, and it walks through four cost drivers that the pricing page does not show.

What happened

The AWS Machine Learning Blog post, written by Majd Arbash, Ajit Mahareddy and Aswath Ram A Srinivasan, follows a first part about attribution, logging and spend enforcement. That earlier part answered who spent the money. This one asks why a workflow is expensive and whether an agent beats the humans it replaces. In the AWS post, a "task" is one complete unit of work, such as resolving a support email or extracting fields from an invoice, however many model calls it takes.

The ROI half of the post promises baselines from human work, controlled experiments and a scorecard covering five dimensions. The supplied text covers the cost-per-task material in detail, so the points below stay with that part.

The four hidden cost drivers

• Tokenizer efficiency. Each model family splits the same text into a different number of tokens. A model with a 15% lower list price can still cost more if it needs 40% more tokens for your data. AWS says structured schemas and numerical arrays are common cases.
• Output verbosity. Output tokens commonly cost 3–5x more than input tokens, depending on the model family. A model that ignores an instruction like "return only raw JSON" makes you pay that premium for filler.
• Agentic loop efficiency. Each tool-use turn re-sends the conversation history and tool results as input. A four-turn model costs much more than one that finishes in a single pass.
• Reasoning overhead. Reasoning tokens bill as output tokens, and some models redact the reasoning while still charging for it. AWS advises starting with reasoning off and enabling it only when benchmarks show a quality gap worth the cost.

A worked example

AWS uses illustrative prices, not real Bedrock rates, for an agent that reads a 750-word email, extracts entities, calls an API to check account status and returns strict JSON.

Metric	Model A (lower list price)	Model B (higher list price)
Input / output list price per 1M tokens	$0.50 / $1.50	$1.00 / $3.00
Turn 1 input tokens	1,500	1,000
Final response tokens	450	150
Turns	3 (error correction)	1
Cumulative input / output tokens	6,150 / 750	1,000 / 150
Total task cost	$0.0042	$0.00145

Model B has twice the list price but costs 65% less per task in this scenario. AWS attributes that to the tokenizer, the padded output and the extra correction turns that re-send a growing history.

Count failures too

AWS notes that the example assumes both models eventually succeed, and production workloads won't. It gives two formulas:

retry-until-success:   cost per successful task = cost per attempt / success rate
escalate-on-failure:   cost per successful task = cost per attempt + (1 - success rate) x escalation cost

When prompt caching is active, input splits into three buckets billed at different rates: uncached input at the base rate, cache reads below it, and cache writes above it.

Key details: measuring on your own workload

• Amazon Bedrock model evaluation covers the quality side. You define criteria, upload prompt datasets and get scored results, with optional human review.
• CountTokens returns the input token count a model would charge for a payload without running inference, so it is a cheap way to compare tokenizers.
• The invocation response usage block carries inputTokens, outputTokens, cacheReadInputTokens and cacheWriteInputTokens. With caching on, inputTokens counts only uncached tokens, so total input is the sum of the three input fields. Price them separately.
• Model invocation logging writes per-invocation token counts to Amazon S3 or CloudWatch Logs. Request metadata lets you slice those counts, but AWS says these are log fields, not cost allocation tags, and they do not appear in Cost Explorer or the Cost and Usage Report.
• Application inference profiles do reach both, but at one usage type per day. That suits chargeback and is too coarse for cost per task.

Multiplying logged tokens by published rates gives a near real-time estimate, not an invoice. AWS says it ignores commitments, batch pricing and provisioned throughput unless you model them, so reconcile against the Cost and Usage Report. It also warns that cache checkpoints drift as an application evolves and tools go stale, which means more cache writes over time. Re-evaluate them regularly.

Levers for reducing cost

The post names prompt caching, which it calls the largest win on agentic paths, and intelligent prompt routing, which sends easy requests to a cheaper model in the same family. It also names a tool schema combined with a maxTokens cap, which AWS says holds verbosity down more reliably than prose instructions.

Why it matters

The example is illustrative and comes from AWS itself, so treat its numbers as a method, not a benchmark. The practical takeaway is to run candidate models on your own prompts, log tokens per turn and compute cost per successful task. For related reading, see how AWS evaluates AI agents with UAEF, its context engineering layers in Deep Insight, and the Claude models added to Amazon Bedrock.

FAQ

Why can a cheaper model cost more per task? According to AWS, it may split your text into more tokens, pad its output, misread tool schemas and need extra turns, each of which re-sends a growing context.

Does token logging replace the AWS bill? No. AWS describes logged token counts times published rates as an estimate that you should reconcile against the Cost and Usage Report.