Even after prompts and application logic are tuned, an Amazon Bedrock inference bill can continue to grow. Choices made on each request still influence how many tokens the service processes and which rate applies to them. Four settings in particular — cache duration, service tier, reasoning effort, and maxTokens — can move cost without any change to the model or the prompt.
How each option behaves depends on the model and the workload. The original post explains how each choice was tested and how to confirm its effect through response metadata, logs, and billing data.
Readers who want to reproduce the settings can start with the Amazon Bedrock Samples notebooks Mixed TTL Caching and Tenant Isolation with Prompt Caching. For maxTokens and reasoning effort, the 01-low-effort folder of the sample-code-for-genai-cost-management-workshop GitHub repository contains the relevant examples. Every sample hardcodes its own model ID, so it should be replaced, along with the inference parameters, to match the model being called. Model availability by AWS Region is listed in Models at a glance, while broader decisions such as model selection, batch inference, routing, and distillation are covered in Effective cost optimization strategies for Amazon Bedrock.
Where inference cost comes from
Usage metadata accompanies every Amazon Bedrock response. Input and output tokens are billed at the rate of the model and tier that served the request. Cache reads and cache writes have their own token counters, and reasoning tokens are billed as output tokens.
Prompt cache duration
When a cache entry expires before the next request arrives, repeated system instructions, tool definitions, or reference context get processed again. The Prompt caching for faster model inference guide documents 5-minute and 1-hour TTL values for supported Anthropic models and a 30-minute minimum TTL for supported GPT-5.6 models. Support and API fields vary by model, so the current support matrix should be consulted before a duration is chosen.
Amazon Bedrock additionally provides implicit prompt caching on supported models; it tries to reuse eligible prompt prefixes without any cache controls in the request. Since implicit caching is best effort and does not guarantee a hit, the duration choices in this section concern explicit caching.
On models that support it, this Converse API signature requests a 1-hour entry:
{ "cachePoint": { "type": "default", "ttl": "1h" } }
For supported Anthropic models, InvokeModel accepts the same ttl value inside cache_control.
A longer duration is not automatically the cheaper option. The Amazon Bedrock Pricing page publishes different rates for 5-minute writes, 1-hour writes, and cache reads. On Amazon Bedrock, a 5-minute write for Anthropic Claude Sonnet 5 and Anthropic Claude Opus 5 costs 1.25 times the input rate, a 1-hour write costs 2 times, and a cache read costs 0.1 times.
Those rates determine the break-even point, assuming each request reuses the identical prefix and each cache read refreshes the TTL. A 5-minute cache pays for itself on the first reuse inside 5 minutes. If requests carrying the same prefix land more than 5 minutes apart, every request rewrites the entry at 1.25 times the input rate; in that pattern the 1-hour cache becomes cheaper starting from the second request within the hour.
Cache rates and checkpoint minimums vary by model, so the comparison should be rerun against the pricing page and the prompt caching guide for the model in use, then verified against cache read and write tokens after rollout.
Practical guidance: place stable content ahead of dynamic content, satisfy the model's checkpoint minimum, and stick to on-demand inference, since prompt caching does not work with batch inference.
Editing a cached prefix — whether a system instruction or a tool definition — produces a miss and a fresh write. Checkpoints are evaluated in the order tools, system, then messages, meaning a change in an earlier section also invalidates the later ones. Frequently changing prompts should be versioned so each version receives its own cache entry. In the author's test, six calls on Claude Sonnet 5 with a 1-hour checkpoint, with the system prompt changed once and the tool definition changed once, produced zero cache reads and a new write on each modification.
AWS describes cache entries as scoped to the account and Region rather than to individual tenants. In multi-tenant applications, a tenant-specific SHA-256 hash can be prepended to the cacheable prefix, a pattern described in Optimizing cost and latency with Amazon Bedrock prompt caching for Anthropic models. Tenant authorization must be enforced before the prompt is built. The hash partitions entries within one account; regulated workloads that need a hard data boundary should isolate each tenant in a separate AWS account.
The 5-minute default suits frequent reuse. A longer supported duration becomes worthwhile when the same prefix recurs at least twice per hour with gaps longer than 5 minutes. To outperform no caching at all, the 1-hour cache requires three requests an hour.
Service tiers for latency-tolerant workloads
Background jobs, evaluation harnesses, nightly summarization, and backfills do not always need the latency profile of interactive traffic. On models that support Flex, it is selected with this request signature:
{ "serviceTier": { "type": "flex" } }
The Standard tier is requested with default rather than standard, and serviceTier can simply be omitted:
{ "serviceTier": { "type": "default" } }
Tier support is model-specific and should be recorded against exact model versions. The model cards for Amazon Nova 2 Lite and OpenAI gpt-oss-120b list Flex as supported, while the cards for Anthropic Claude Sonnet 5 and Anthropic Claude Opus 5 on Amazon Bedrock list it as unsupported. A Flex request sent to an unsupported model fails with a ValidationException rather than silently falling back to Standard — the author's request to Claude Sonnet 5 returned exactly that error.
When policy permits Standard as a fallback, the unsupported-tier error can be caught and retried once with default. Not every ValidationException should be retried, because malformed requests raise the same exception. Application-level retries should be capped; the AWS SDK's bounded retry strategy already handles throttling and transient errors.
Flex requests need a caller-defined deadline. A supported response reports the resolved tier, which can also be checked through the Amazon CloudWatch ResolvedServiceTier metric. Exact rates appear in Service tiers for optimizing performance and cost and on the Amazon Bedrock Pricing page for the model in question.
The author's Flex test on Amazon Nova 2 Lite used 200 default and 200 flex requests sent in interleaved pairs. Both tiers processed identical input and output token counts, all 400 requests resolved to the requested tier, and the median latency gap was too small to distinguish from noise. At the time of writing, the published Flex rate for Nova 2 Lite in us-west-2 was half the Standard rate, and the bill reflected that. Latency-sensitive traffic should remain on default.
Adaptive thinking effort
Reasoning tokens bill as output tokens. Claude Sonnet 5 and Claude Opus 5 run adaptive thinking at high effort by default, even when a request omits the thinking field. An application migrated from Claude Sonnet 4.6 without modification therefore starts being billed for thinking tokens, and maxTokens now caps thinking plus response text together. Claude Haiku 5.5 defaults to medium. All three models accept low, medium, high, xhigh, and max. Effort for a task is lowered with this request signature:
{
"thinking": { "type": "adaptive" },
"output_config": { "effort": "low" }
}
The effort value belongs in output_config, not inside thinking. The Adaptive thinking documentation should be reviewed whenever the model changes.
The author tested a tool-calling agent built on Claude Opus 5. Its three tasks follow the design from Build long-horizon agents with Grok 4.7 on Amazon Bedrock, and each task has a single correct answer. Every task ran eight times at each effort level. Median output tokens:
| Effort | Correct runs | Median output tokens | Change from low (95% interval) |
|---|---|---|---|
| low | 24 of 24 | 936 | baseline |
| medium | 24 of 24 | 1,484 | +59% (50% to 78%) |
| high (default) | 24 of 24 | 2,521 | +169% (112% to 190%) |
| xhigh | 24 of 24 | 2,964 | +217% (170% to 260%) |
| max | 24 of 24 | 3,762 | +302% (180% to 402%) |
Whether lower effort preserves accuracy depends on the model and the task, so measurement should happen on tasks shaped like the real workload.
On the Invoke Bedrock model for code generation workload from Amazon Bedrock Samples, median output tokens were 676 at low effort and 743 at high — a difference inside run-to-run variation — and the graded programs passed at every effort level.
Per-request output-token counts, the CloudWatch AWS/Bedrock OutputTokenCount metric, invocation logs, and a task pass rate together evaluate the setting. Routine, well-bounded tasks can start below high; high should stay where quality tests show the task needs it. Cutting tokens in a way that breaks the task is not a saving.
Output token limits
maxTokens acts as an application-level ceiling on output: it bounds what a bad prompt, regression, or loop can emit before the request stops. The quota rule is documented in How tokens are counted in Amazon Bedrock: the service deducts input tokens plus maxTokens when a request begins, so an oversized ceiling reduces concurrency.
An output ceiling is not a safety control. Amazon Bedrock Guardrails remains the standard responsible AI control for production generative AI workloads: it can filter content, detect prompt attacks, and check grounding on supported inputs and responses, as described in Detect and filter harmful content by using Amazon Bedrock Guardrails.
maxTokens should be set per task type after observing a representative output-token distribution:
{ "inferenceConfig": { "maxTokens": 155 } }
The request parameters are documented in Inference using Converse API.
In the author's test on Claude Sonnet 5, five normal outputs peaked at 103 tokens, so an illustrative fence of 155 tokens was chosen with headroom. The same deliberately verbose prompt was then sent twice with adaptive thinking disabled — once under a 2,048-token ceiling and once under the 155-token fence. The first produced 2,048 output tokens and the second 155, meaning the fence avoided 1,893 output tokens. Both requests stopped at max_tokens, so both responses were truncated. A fence limits spend but does not make an unsuitable prompt useful, and inside a multi-turn or agentic chain a truncated turn can break the steps that follow.
For production calibration, the 95th and 99th percentiles (P95 and P99) of each task type should be compared and headroom added to the chosen percentile. With adaptive thinking enabled, maxTokens also caps thinking tokens, so calibration should run with thinking on. P95 restricts exposure more aggressively but accepts a higher truncation risk; P99 keeps more valid long-tail responses at a higher ceiling. max_tokens stops should be monitored and the request investigated before the task's limit is raised.
Putting it together
The same test loop applies to every setting: confirm model support, change a single request choice, measure tokens or cost, and track quality or completion. Teams routing across models should maintain a capability record for each model version, Region, and API — supported cache duration, service tiers, reasoning levels, and output ceiling — validate each request against it before sending, then confirm the resolved tier and cache counters in the response.
| Setting | Default or permissive state | Result | Risk to accept |
|---|---|---|---|
| Cache duration | Model-specific TTL | From published Sonnet 5 and Opus 5 rates, a 1-hour cache wins from the second request per hour when gaps exceed 5 minutes | A 1-hour write costs 2 times input, so low reuse loses money; partition tenant prefixes |
| Service tier | default | At the time of writing, Nova 2 Lite Flex was published at half the Standard rate, and the measured bill matched | Longer processing; set your own deadline and a fallback |
| Reasoning effort | high on the tested adaptive model | Low to high: +169% median output tokens on the agent test, no reliable difference on code generation | Quality can drop near the task's capability boundary; track pass rate with tokens |
| maxTokens | Permissive 2,048-token cap | An illustrative 155-token fence avoided 1,893 output tokens in one test | Truncation can cascade through multi-turn or agentic chains; check stopReason before raising the limit |
Signals to watch
| Setting | Symptom | Verify with | First response |
|---|---|---|---|
| Cache duration | Repeated context does not produce the expected latency or cost benefit | Application latency and cost telemetry | Check prefix stability, reuse interval, and model support before changing TTL |
| Service tier | The requested tier is unsupported or the serving tier differs from expectation | Response serviceTier and CloudWatch ResolvedServiceTier | Use a supported tier or return latency-sensitive traffic to default |
| Reasoning effort | Output tokens rise while quality holds | Per-request response telemetry, CloudWatch OutputTokenCount, invocation logs, and task pass rate | Lower effort for that task class and rerun its quality test |
| maxTokens | stopReason is max_tokens | Response stop reason and task-scoped output-token distribution | Inspect the prompt and task fence before raising the limit |
P95 and P99 for each task type should be derived from task-tagged application telemetry or invocation logs.
Conclusion
All four choices sit inside the inference request. Model support should be rechecked whenever the model changes; then one setting at a time can be modified and its effect measured in the application.
Resources for evaluating these options per workload: the Amazon Bedrock console at console.aws.amazon.com/bedrock; Prompt caching for faster model inference; Service tiers for optimizing performance and cost; Adaptive thinking; Detect and filter harmful content by using Amazon Bedrock Guardrails; Effective cost optimization strategies for Amazon Bedrock; and the related samples and posts Invoke Bedrock model for code generation and Build long-horizon agents with Grok 4.7 on Amazon Bedrock.