---
title: "90% cheaper cached input is not a pricing trick. It changes what belongs in the prompt."
description: "AWS says Bedrock prompt caching can reduce repeated input-token costs by up to 90% and latency by up to 85%. The production decision is architectural: stable context should be separated from volatile context and governed as a reusable dependency."
url: "https://devencelab.com/insights/2026/09/15/90-cheaper-cached-input-is-not-a-pricing-trick"
date: "2026-09-15"
section: "Insights"
tag: "Model Releases"
author: "Devence Lab"
reading_time: "2 min read"
site: "Devence Lab"
license: "Readable and quotable with attribution to the canonical URL."
---

# 90% cheaper cached input is not a pricing trick. It changes what belongs in the prompt.

AWS says Bedrock prompt caching can reduce repeated input-token costs by up to 90% and latency by up to 85%. The production decision is architectural: stable context should be separated from volatile context and governed as a reusable dependency.

AWS says Amazon Bedrock prompt caching can cut the cost of repeated input tokens by up to 90% and reduce latency by up to 85%. Those figures make caching look like a billing optimisation. The more useful reading is architectural: production prompts now have a reason to separate stable context from request-specific state.

The distinction matters most in systems that repeatedly send large system instructions, tool definitions, policies, schemas or conversation history. Without an explicit boundary, every request pays to process context that may not have changed.

## A cache boundary is also a context boundary

AWS describes caching across message content, system prompts and tool definitions, with cache checkpoints identifying reusable prefixes. That turns prompt composition into two classes of data: material expected to remain stable long enough to reuse, and material that must be evaluated afresh for each request.

The production mistake is to optimise the whole prompt as one blob. Stable policy instructions can be cached. User state, authorisation context and rapidly changing operational data usually need a different treatment because freshness matters more than token reuse.

> Prompt caching is safest when the cache boundary matches the system's trust and freshness boundary.

That is particularly important for agents. Tool descriptions may be stable, while the permissions attached to the current user are not. A low-latency request is not a successful request if it reused context whose authority or business state had expired.

## Tenant isolation becomes part of the cost design

AWS includes tenant isolation as one of its six practical caching scenarios. That is not an implementation footnote. Shared AI services need cache keys and context boundaries that prevent one tenant's reusable material from becoming another tenant's optimisation input.

The same review should cover retention and invalidation. A cached policy, tool schema or long system instruction needs an owner and a condition that makes it stale. Otherwise cost optimisation creates a second configuration layer that can drift away from the source it represents.

## Measure cache correctness before cache hit rate

Teams adopting prompt caching should inventory repeated context, classify it by sensitivity and freshness, then decide what can be cached. Record the cache boundary alongside the prompt version, tenant scope and invalidation condition.

Only then should hit rate, token savings and latency become optimisation targets. AWS has made repeated context materially cheaper. The practitioner change is to treat that reusable context as a governed production dependency rather than an invisible performance feature.

## Sources

- [Optimizing cost and latency with Amazon Bedrock prompt caching](https://aws.amazon.com/blogs/machine-learning/optimizing-cost-and-latency-with-amazon-bedrock-prompt-caching/) - AWS