{"slug": "amazon-bedrock-four-request-settings-that-change-your-inference-bill", "title": "Amazon Bedrock: Four Request Settings That Change Your Inference Bill", "summary": "AWS published guidance on November 12, 2026, from authors Sai Pavan Kasani and Aswath Ram A Srinivasan identifying four request-level Amazon Bedrock settings — prompt cache TTL, service tier, adaptive thinking effort, and maxTokens — that still move inference bills after prompt tuning. AWS's tests found a 1-hour cache write costs 2× the input rate versus 1.25× for a 5-minute write, Nova 2 Lite Flex billed at half Standard in us-west-2 at time of writing, and raising reasoning effort from low to high on Opus 5 increased median output tokens 169% on agent tasks while a code task stayed flat. AWS recommends changing one setting at a time, confirming model support in the current Region, and validating against your own task distribution rather than vendor averages.", "body_md": "**On November 12, 2026, AWS published [Four Amazon Bedrock inference choices that affect cost](https://aws.amazon.com/blogs/machine-learning/four-amazon-bedrock-inference-choices-that-affect-cost/?ref=explainx)—a measured follow-up to the same morning's [Tokenomics at scale](https://explainx.ai/blog/track-and-cap-amazon-bedrock-spend-per-iam-principal-cur-2-0-aws-budgets-deny-policy-guide-2026) and [cost-per-task ROI](https://explainx.ai/blog/aws-bedrock-cost-per-task-not-per-token-agent-roi-baselines-holdouts-part-2-2026) posts.** Authors Sai Pavan Kasani and Aswath Ram A Srinivasan argue that **request-level knobs** still move bills after you tune prompts: **prompt cache TTL**, **service tier**, **adaptive thinking effort**, and **`maxTokens`**.\n\nIf you run [agents on Bedrock](https://explainx.ai/blog/aws-bedrock-agentcore-runtime-next-generation-november-2026) or compare [Grok 4.7 long-horizon patterns](https://explainx.ai/blog/grok-4-7-bedrock-reasoning-effort-72-agent-runs-token-cost-2026), these four settings are the difference between a flat forecast and a surprise CUR line.\n\n## TL;DR\n\n| Knob | AWS default or permissive state | What their tests showed | Risk AWS flags | \n|---|---|---|---|\n| **Cache duration** | Model-specific TTL | 1-hour cache beats 5-minute when same prefix returns after gaps over 5 minutes | 1-hour writes cost 2× input; low reuse loses money; partition tenant prefixes | \n| **Service tier** | `default` | Nova 2 Lite Flex billed at half Standard in us-west-2 at time of writing | Unsupported models error; set deadlines; optional fallback retry | \n| **Reasoning effort** | `high` on tested Opus 5 | Low→high +169% median output tokens on agent tasks; code task flat | Quality can drop on hard tasks; track pass rate with tokens | \n| **`maxTokens`** | Large ceiling (e.g. 2048) | 155-token fence avoided 1,893 output tokens on one verbose prompt | `stopReason` max_tokens truncates multi-turn chains | \n\n## Where inference cost actually lives\n\nEvery Bedrock response includes **usage metadata**. You pay **input and output** tokens at the model and tier rate, plus separate **cache read and write** counters, and **reasoning tokens count as output** on adaptive models.\n\nThat is why [IAM principal caps](https://explainx.ai/blog/track-and-cap-amazon-bedrock-spend-per-iam-principal-cur-2-0-aws-budgets-deny-policy-guide-2026) still miss the target when developers change only application code: the same role can double output tokens by leaving **effort** at default after a model upgrade.\n\nAWS recommends changing **one setting at a time**, confirming **model support** in the current Region, then validating in **your** task distribution—not vendor averages alone.\n\n## Prompt cache duration\n\nRepeated **system prompts**, **tool definitions**, and **reference context** can re-bill when cache entries expire. The [prompt caching guide](https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html?ref=explainx) lists **5-minute** and **1-hour** TTL values for supported Anthropic models and **30-minute minimum** TTL for supported GPT-5.6 models on Bedrock.\n\nExplicit caching uses a Converse API checkpoint:\n\n```\n{ \"cachePoint\": { \"type\": \"default\", \"ttl\": \"1h\" } }\n```\n\nInvokeModel for Anthropic models places the same TTL inside `cache_control`.\n\n### Published rate shape (Sonnet 5 and Opus 5)\n\nAWS cites [Bedrock pricing](https://aws.amazon.com/bedrock/pricing/?ref=explainx) for Anthropic Claude Sonnet 5 and Opus 5 on Bedrock:\n\n| Event | Multiple of input rate (per AWS post) | \n|---|---|\n| 5-minute cache write | 1.25× | \n| 1-hour cache write | 2× | \n| Cache read | 0.1× | \n\n**Break-even intuition from AWS:** a **5-minute** cache pays back on the **first reuse within 5 minutes**. If the same prefix returns **more than 5 minutes apart**, you pay **1.25× writes on every call** unless you use a longer TTL. A **1-hour** cache is cheaper from the **second request within the hour**. Beating **no cache** needs **three requests per hour** with the reuse pattern AWS describes.\n\n**Implicit caching** is best-effort without cache controls; duration tuning in the post targets **explicit** checkpoints.\n\n### Stability and multi-tenant layouts\n\nAWS reran **six calls** on Claude Sonnet 5 with a **1-hour** checkpoint, changing the system prompt once and the tool definition once. Each change produced **zero cache reads** and a **new write**—checkpoints evaluate in order **tools, system, messages**, so an early edit invalidates later sections.\n\nFor SaaS, AWS repeats the pattern in [Optimizing cost and latency with Amazon Bedrock prompt caching for Anthropic models](https://aws.amazon.com/blogs/machine-learning/optimizing-cost-and-latency-with-amazon-bedrock-prompt-caching-for-anthropic-models/?ref=explainx): prepend a **tenant-specific SHA-256 hash** to the cacheable prefix so entries partition inside one account. Enforce authorization **before** building the prompt; regulated tenants may still need **separate AWS accounts** for hard isolation.\n\n**Constraint:** prompt caching does **not** work with **batch inference**—on-demand only.\n\nAmazon Bedrock inference cost tuning starts with prompt cache TTL and invalidation timing\n\n## Service tier (Flex)\n\nBackground jobs—eval harnesses, nightly summarization, backfills—may not need Standard latency. For models that support **Flex**, Converse accepts:\n\n```\n{ \"serviceTier\": { \"type\": \"flex\" } }\n```\n\nUse **`default`**, not `standard`, for Standard tier per AWS naming in the post.\n\n### Support matrix AWS reports\n\n| Model family | Flex in model card (per AWS Nov 12 post) | \n|---|---|\n| Amazon Nova 2 Lite | Supported | \n| OpenAI gpt-oss-120b | Supported | \n| Anthropic Claude Sonnet 5 | Not supported | \n| Anthropic Claude Opus 5 | Not supported | \n\nAn unsupported Flex request returns **`ValidationException`**—not a silent downgrade. AWS suggests a **single** catch-and-retry to `default` when policy allows, and warns not to retry every validation error.\n\n### Nova 2 Lite interleaved test\n\nAWS sent **200 default** and **200 flex** requests in **interleaved pairs** on Nova 2 Lite. Both tiers processed the same input and output token totals; all 400 resolved to the requested tier; median latency difference was **noise**. At publication time, **Flex in us-west-2 was half the Standard rate** on the pricing page, and AWS said the bill matched.\n\nVerify with response **`serviceTier`** and CloudWatch **` ResolvedServiceTier`**. See [Service tiers for optimizing performance and cost](https://docs.aws.amazon.com/bedrock/latest/userguide/service-tiers.html?ref=explainx).\n\nAmazon Bedrock Flex service tier halves Standard rates on supported models like Nova 2 Lite\n\n## Adaptive thinking effort\n\nReasoning tokens bill as **output**. Claude Sonnet 5 and Opus 5 default to **`high`** adaptive effort even when a request omits `thinking`—migrating from Sonnet 4.6 without edits can start billing thinking tokens immediately, and **`maxTokens` caps thinking plus final text together**.\n\nLower effort via Converse:\n\n```\n{\n  \"thinking\": { \"type\": \"adaptive\" },\n  \"output_config\": { \"effort\": \"low\" }\n}\n```\n\nKeep **`effort` inside `output_config`**, not nested under `thinking`.\n\n### Opus 5 agent benchmark (AWS table)\n\nAWS reused tasks from [Build long-horizon agents with Grok 4.7 on Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/build-long-horizon-agents-with-grok-4-7-on-amazon-bedrock/?ref=explainx)—each task has one correct answer. **Eight runs per effort level**:\n\n| Effort | Correct runs | Median output tokens | Change vs low | \n|---|---|---|---|\n| low | 24 of 24 | 936 | baseline | \n| medium | 24 of 24 | 1,484 | +59% | \n| high (default) | 24 of 24 | 2,521 | +169% | \n| xhigh | 24 of 24 | 2,964 | +217% | \n| max | 24 of 24 | 3,762 | +302% | \n\nAccuracy held on these tasks, but AWS stresses **your** distribution may differ—measure pass rate alongside tokens.\n\nOn the **code generation** sample in [Invoke Bedrock model for code generation](https://github.com/aws-samples/sample-code-for-genai-cost-management-workshop?ref=explainx), median output was **676 at low** versus **743 at high**—within run-to-run variation, with programs passing at both levels.\n\n**Practice:** start below **`high`** for bounded routines; keep **` high`** only where quality tests prove the margin. Cross-read our [Grok 4.7 effort cost walkthrough](https://explainx.ai/blog/grok-4-7-bedrock-reasoning-effort-72-agent-runs-token-cost-2026) for a parallel agent lens.\n\nBedrock adaptive thinking effort raises output tokens on agent workloads\n\n## Output token limits (`maxTokens`)\n\n`maxTokens` is a **ceiling on application output**, not a substitute for [Bedrock Guardrails](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html?ref=explainx). Quota logic reserves **input tokens plus `maxTokens`** at request start per [How tokens are counted in Amazon Bedrock](https://docs.aws.amazon.com/bedrock/latest/userguide/model-parameters.html?ref=explainx).\n\nExample Converse fence:\n\n```\n{ \"inferenceConfig\": { \"maxTokens\": 155 } }\n```\n\n### Illustrative Sonnet 5 test\n\nAfter five normal outputs peaking at **103 tokens**, AWS set **`maxTokens`: 155**. The same deliberately verbose prompt with thinking disabled produced **2,048** tokens under a 2,048 ceiling versus **155** under the fence—**1,893 tokens avoided**, both ending at **`stopReason` max_tokens**. The fence limits spend but **does not fix a bad prompt**; truncated turns can break downstream agent steps.\n\n**Calibration:** compare **P95 and P99** per task type with thinking enabled when adaptive thinking is on; P95 caps exposure more aggressively, P99 preserves long tails at higher cost.\n\n## Putting the four knobs together\n\nAWS's closing table is a deployment checklist:\n\n| Symptom | Verify with | First response | \n|---|---|---|\n| Cache not helping | Latency and cost telemetry | Prefix stability, reuse interval, model support | \n| Wrong tier | `serviceTier` plus`ResolvedServiceTier` | Supported tier or move interactive traffic to default | \n| Tokens up, quality flat | Invocation logs plus pass rate | Lower effort for that task class | \n| Frequent `max_tokens` stops | Stop reason plus output distribution | Inspect prompt before raising ceiling | \n\nMaintain a **capability record** per model version and Region: supported cache TTL, tiers, effort levels, and fences—validate each request before send.\n\nIf you also operate a [LiteLLM gateway on Fargate](https://explainx.ai/blog/self-service-llm-gateway-amazon-bedrock-litellm-fargate-inference-profiles-virtual-keys-guide-2026), encode those records in the router so one misconfigured profile does not inherit another team's cache TTL.\n\n## What builders should do this week\n\n1. **Inventory defaults** on production Bedrock profiles—especially**effort** after any Sonnet or Opus upgrade.\n2. **Plot reuse intervals** for stable system and tool prefixes; pick**5m versus 1h** with the AWS break-even math, then confirm cache read and write lines in CUR.\n3. **Pilot Flex** only on supported models in latency-tolerant queues; log`ValidationException` rates.\n4. **Set task-scoped `maxTokens`** from measured P95 with headroom; alert on` max_tokens` stopReason spikes.\n5. **Link spend to principals** using the companion[Tokenomics guide](https://explainx.ai/blog/track-and-cap-amazon-bedrock-spend-per-iam-principal-cur-2-0-aws-budgets-deny-policy-guide-2026) so experiments show up in the right cost center.\n\n## What people are asking\n\n**Does this replace model routing or distillation?** No—AWS points to [Effective cost optimization strategies for Amazon Bedrock](https://aws.amazon.com/blogs/machine-learning/effective-cost-optimization-strategies-for-amazon-bedrock/?ref=explainx) for model choice, batch inference, and distillation. These four knobs sit **inside** a chosen model.\n\n**Can I mix Flex and prompt caching?** Caching rules are independent, but both need model support checks. Flex failures are immediate; cache misses show up as write spikes.\n\n**Does Kimi K3.1 Pro highspeed change the math?** Separate model card and pricing—rerun the same telemetry loop when you add [Bedrock highspeed profiles](https://explainx.ai/blog/kimi-k3-1-pro-amazon-bedrock-highspeed-opencode-guide-2026).\n\n## Related reading\n\n*Inference parameters, pricing multiples, and model support matrices reflect AWS documentation and the November 12, 2026 AWS Machine Learning blog post as we read them; confirm current Region and model card text before production rollout.*", "url": "https://wpnews.pro/news/amazon-bedrock-four-request-settings-that-change-your-inference-bill", "canonical_source": "https://explainx.ai/blog/aws-bedrock-four-inference-choices-cost-cache-flex-guide-2026?utm_source=rss&utm_medium=feed&utm_campaign=blog", "published_at": "2026-11-12 00:00:00+00:00", "updated_at": "2026-11-12 21:54:05.992058+00:00", "lang": "en", "topics": ["ai-infrastructure", "large-language-models", "ai-agents", "mlops"], "entities": ["Amazon Web Services", "Amazon Bedrock", "Sai Pavan Kasani", "Aswath Ram A Srinivasan", "Anthropic Claude Sonnet 5", "Anthropic Claude Opus 5", "Nova 2 Lite", "GPT-5.6"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/amazon-bedrock-four-request-settings-that-change-your-inference-bill", "markdown": "https://wpnews.pro/news/amazon-bedrock-four-request-settings-that-change-your-inference-bill.md", "text": "https://wpnews.pro/news/amazon-bedrock-four-request-settings-that-change-your-inference-bill.txt", "jsonld": "https://wpnews.pro/news/amazon-bedrock-four-request-settings-that-change-your-inference-bill.jsonld"}}