Recent guidance from AWS highlights four inference‑time parameters that influence how many tokens Bedrock processes and the rates applied to them: prompt cache TTL, the selected service tier (and its associated reasoning effort), and the maxTokens limit. Understanding and adjusting these levers lets AI engineers, platform teams, and SREs keep inference bills from spiraling as workloads evolve.
Prompt cache duration and its cost trade‑offs
Bedrock can store a prefix of a prompt in a cache and reuse it for subsequent calls. The cache entry’s time‑to‑live (TTL) is configurable per request. Supported TTLs include 5 minutes, 30 minutes, and 1 hour, depending on the model (e.g., Anthropic Claude series or GPT‑5.6). Explicit TTL is set in the request payload, for example:
{ "cachePoint": { "type": "default", "ttl": "1h" } }Cache reads and writes are billed separately from regular token usage. For Anthropic Claude Sonnet 5 and Claude Opus 5, a 5‑minute write costs 1.25 × the input token rate, a 1‑hour write costs 2 ×, and a cache read costs 0.1 ×. The break‑even point occurs after the first reuse within the TTL: a 5‑minute cache pays back on the first hit, while a 1‑hour cache becomes cheaper from the second request within the hour. Implicit caching exists but is best‑effort and does not guarantee a hit, so explicit TTL values remain the reliable control.
Cache entries are scoped to the AWS account and region, not to individual tenants. In multi‑tenant applications, prepend a tenant‑specific hash to the cacheable prefix to avoid cross‑tenant cache pollution. Cache does not apply to batch inference; on‑demand calls are required for caching to work.
Service tier, reasoning effort, and token accounting
Each Bedrock response includes usage metadata that records input tokens, output tokens, cache read/write tokens, and reasoning tokens. Reasoning tokens are counted as output tokens, so higher reasoning effort raises the output token count and the associated cost. Selecting a lower‑effort tier reduces the number of reasoning tokens generated, directly lowering the bill.
Practitioners can verify the impact by inspecting the response metadata, reviewing CloudWatch logs, or correlating with billing reports. The same metadata can be used to confirm that cache reads/writes are being counted as expected.
Limiting output with maxTokens
The maxTokens parameter caps the number of tokens the model may emit. Because output tokens are billed at the model’s output rate, a tighter limit prevents runaway token consumption on long completions. Sample notebooks in the Bedrock Samples repository demonstrate how adjusting maxTokens interacts with reasoning effort for cost control.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
To keep Bedrock inference spend predictable, teams should:
- Choose the shortest TTL that still satisfies latency requirements, and monitor cache hit ratios via usage metadata.
- Prefer lower‑effort service tiers when the application can tolerate reduced reasoning depth.
- Set
maxTokensto the smallest value that meets functional needs. - Validate cost impact with the built‑in usage counters rather than relying on assumptions.
- In multi‑tenant designs, namespace cache keys with tenant identifiers to avoid accidental cache invalidation across tenants.
By treating these four knobs as part of the regular deployment checklist—alongside model selection, batch vs. on‑demand inference, and routing decisions—engineers can achieve measurable cost savings without sacrificing model capabilities.
