Prompt caching lets the platform store the processed form of a prompt prefix — system prompt, tool definitions, long documents — and reuse it on subsequent requests instead of reprocessing it. Claude Platform on AWS supports the full first-party caching feature set: 5-minute TTL, 1-hour TTL, and automatic caching. (TTL, "time to live," is how long a cache entry survives without being refreshed.)
Two ways to enable it
Automatic caching — a single top-level cache_control field on the request — is the recommended default: the platform decides where to place cache boundaries. Explicit breakpoints put cache_control on individual content blocks, giving you precise control over what is cached; everything up to and including the marked block becomes the cached prefix. The classic explicit setup marks the end of a long, stable system prompt:
from anthropic import AnthropicAWS
client = AnthropicAWS() # AWS_REGION + ANTHROPIC_AWS_WORKSPACE_ID set
resp = client.messages.create(
model="claude-opus-4-8",
max_tokens=512,
system=[{
"type": "text",
"text": LONG_POLICY_DOCUMENT, # stable, reused prefix
"cache_control": {"type": "ephemeral"} # cache up to here
}],
messages=[{"role": "user", "content": "Summarize section 4."}],
)
print(resp.usage)Order matters: put stable content first and variable content (the user's question) after the breakpoint. Any change to the cached prefix — including switching the model string — invalidates the cache, and the first request on the new model writes it fresh. There are minimum cacheable sizes: 1,024 tokens on Claude Opus 4.8, and 512 on Claude Fable 5.
Verifying hits in the usage fields
The response's usage object is your ground truth. On a cache write you'll see tokens counted under cache_creation_input_tokens; on a hit, under cache_read_input_tokens; only the uncached remainder appears as ordinary input_tokens. If cache_read_input_tokens stays zero across back-to-back identical requests, the prefix is changing between calls or is below the minimum size. Two platform-specific notes: prompt caches are isolated per workspace on Claude Platform on AWS (as on the first-party API), so traffic split across workspaces will not share a cache; and the first-party cache diagnostics feature is not available on this platform, so the usage fields are the observability you get.
The economics
Caching changes the price per token of the cached prefix (per 1M tokens, Claude Opus 4.8 rates):
| Token category | Multiplier | Opus 4.8 price / MTok |
|---|---|---|
| Normal input | 1x | $5.00 |
| 5-minute cache write | 1.25x | $6.25 |
| 1-hour cache write | 2x | $10.00 |
| Cache read (hit) | 0.1x | $0.50 |
A worked example: a 20,000-token system prompt called 1,000 times per hour on Opus 4.8. Uncached, that prefix costs 20M input tokens/hour ≈ $100. With a 5-minute cache refreshed on use, roughly one write plus 999 reads: about $0.125 for the write and $9.99 for the reads — roughly $10.12, a ~90% reduction on the prefix. The break-even is fast: a 5-minute cache write pays for itself after a single read, and a 1-hour write after two reads. Caching multipliers also stack with other modifiers, including the Batch API's 50% discount and the inference_geo: "us" 1.1x data-residency multiplier.
Data-handling note
For organizations with Zero Data Retention arrangements: prompt caching is ZDR-eligible. Prompts and outputs are not stored; cache representations and cryptographic hashes are held in memory for the cache TTL and promptly deleted after expiry. Confirm your own arrangement's terms with your Anthropic representative.
Where to go next
Compare with prompt caching on Bedrock (which lacks automatic caching), see the Batch API on Claude Platform on AWS for stacking discounts, and check the feature matrix for platform-by-platform support.