Stretch Your Claude Code Budget with Bedrock Prompt Caching

Pratik Kulkarni
AWS , AI FinOps
12 May, 2026
05 Mins read

Anthropic recently tightened usage limits on Claude Code — and if you’re doing serious development work, you feel it. Long refactoring sessions, codebase-wide architecture questions, iterative debugging loops: they all burn through your token allocation fast. Now you can’t practically use Claude Code less. But you can make each token go further.

Routing Claude Code through Amazon Bedrock with prompt caching enabled solves the problem at both ends: you’re on Bedrock’s separate quota system (not Anthropic.ai’s consumer limits), and the caching layer means Claude doesn’t reprocess your codebase on every request. Cached tokens aren’t deducted against your rate limit at all.

Why Bedrock Changes the Quota Equation

When you connect Claude Code to Amazon Bedrock, you leave Anthropic’s consumer usage tiers entirely. Bedrock uses Token Per Minute (TPM) and Request Per Minute (RPM) quotas managed through AWS Service Quotas — a system designed for production workloads, not individual accounts.

The default Bedrock quotas are generous, and if they’re not enough, you can request increases through the AWS console. For teams, the math from the AWS guidance is instructive: 200 developers at 20,000 TPM each requires requesting 4 million total TPM — something you can do with a service quota increase request to AWS (anthropic as a consumer product does not allow it).

More importantly, prompt caching changes what “using tokens” means. Once your codebase context is cached, subsequent requests that hit the cache don’t re-count that context against your TPM quota. You get Claude’s full understanding of your code without the full token cost.

How Prompt Caching Works in Claude Code

When Claude Code reads your project files, it sends that context to Bedrock as part of every request. Without caching, each request reprocesses every token: your system prompt, your project files, your conversation history. For a moderately complex codebase, that’s thousands of tokens on every single turn.

With prompt caching, Bedrock creates a checkpoint after processing the static parts of your context — the parts that don’t change between requests. On the next request, if that prefix matches what’s in cache, Bedrock loads the saved model state instead of recomputing. The cache has a 5-minute TTL that resets on every hit. Keep working in the same session and the cache stays warm indefinitely.

The savings compound as your codebase grows. A simple app shows ~20% cost reduction. A complex codebase with many files, Claude reading multiple modules to understand call chains and data flow, shows dramatically more. The AWS benchmark: up to 90% token cost reduction and 85% latency reduction in MCP-heavy workflows.

Prompt caching is on by default when you route Claude Code through Bedrock. You don’t configure it. Claude Code manages the cache checkpoints automatically.

Setup: Three Environment Variables

The prerequisites are an AWS account with Bedrock model access enabled for Claude Sonnet 4 (or any model) in us-east-1 or us-west-2, and AWS CLI configured with credentials that have Bedrock invoke permissions.

Then:

# Install Claude Code if you haven't already
npm install -g @anthropic-ai/claude-code

# Route to Bedrock with prompt caching
export CLAUDE_CODE_USE_BEDROCK=1
export ANTHROPIC_MODEL='us.anthropic.claude-sonnet-4-20250514-v1:0'
export ANTHROPIC_SMALL_FAST_MODEL='us.anthropic.claude-haiku-4-5-20251001-v1:0'

# Start Claude Code
claude

The us. prefix on the model ID enables cross-region inference — Bedrock routes to whichever region has capacity, which matters during peak hours. If you’re hitting throttling, this is the first thing to check.

To verify prompt caching is active, run /cost after a few exchanges. You’ll see a breakdown of cached vs. uncached tokens alongside total cost and API latency. This is your feedback loop for understanding where your budget is going.

Making the Cache Work Harder

The cache saves whatever context was processed before Claude Code’s first dynamic input in a given session. The more you reuse that same static prefix across turns, the more you save. A few session habits that compound the effect:

Stay in one session longer. The 5-minute TTL resets on every cache hit. An active coding session keeps the cache permanently warm with no additional cost. Spinning up a new Claude Code process loses that cached state and forces a cold start.

Let Claude read the codebase once at the start. Ask Claude to summarize the architecture, map the data flow, understand the test coverage — whatever gives it a comprehensive picture of the project. That full-context read is expensive once. Every follow-up question in the same session benefits from it.

Work on related files in sequence. Claude Code builds its context from what it’s read. If you jump between completely unrelated parts of the codebase, you fragment the cache-able prefix. Grouping related work in a session means the shared context stays warm.

Don’t restart between small fixes. The reflex to restart Claude Code when something feels slow is counterproductive. A warm cache is fast by design. Check /cost to confirm you’re getting cache hits before restarting.

Extended 1-Hour TTL for Long Sessions

Some Claude models on Bedrock support an extended 1-hour cache TTL alongside the default 5-minute window — specifically Claude Opus 4.5, Claude Sonnet 4.5, and Claude Haiku 4.5. This is useful when your session has natural breaks: a meeting, a code review, stepping away to test on a device.

With 5-minute TTL, any gap longer than 5 minutes means a cold start on your next request. With 1-hour TTL, your codebase context survives the interruption. Claude Code doesn’t expose a user-facing toggle for this yet, but it’s worth knowing the capability exists as the feature surface expands.

MCP Multiplies the Savings

If you’re using Model Context Protocol servers alongside Claude Code — for AWS documentation, database schemas, internal tools — prompt caching becomes even more valuable. Each MCP tool response enriches your prompt with external knowledge. Without caching, that knowledge is reprocessed on every request. With caching, it’s computed once per cache window.

The AWS documentation MCP server is a good example. When Claude Code fetches a service’s documentation to answer a question, that content can be hundreds of tokens. In a session where you’re building an AWS-backed feature and repeatedly referencing the same service docs, caching eliminates that reprocessing cost on every subsequent turn.

For Teams Running Claude Code at Scale

If you’re rolling Claude Code out across a development team, Bedrock gives you controls that the direct Anthropic API doesn’t:

IAM Identity Center for centralized access management — developers authenticate with temporary role-based credentials, no static API keys
CloudTrail logs every Bedrock API call, giving you per-developer usage visibility
Service quotas are adjustable through AWS, so you can match TPM limits to your team size
Environment variable management through your internal config tooling — set CLAUDE_CODE_USE_BEDROCK, ANTHROPIC_MODEL, and ANTHROPIC_SMALL_FAST_MODEL as managed variables so all developers connect through Bedrock by default

A shared .mcp.json checked into each repo — configured by a central team — means every developer automatically gets the same MCP servers and the same caching benefits, without per-developer setup.

Key Takeaways

Routing Claude Code through Amazon Bedrock puts you on Bedrock’s TPM/RPM quota system, independent of Anthropic’s consumer usage limits
Prompt caching is enabled automatically on Bedrock — no code changes, no configuration beyond the three env vars
Cache hits are not counted against your rate limit, making cached tokens effectively free toward your quota
Keep sessions warm: the 5-minute TTL resets on every cache hit, so an active session maintains the cache indefinitely
Complex codebases and MCP-heavy workflows see the largest savings — up to 90% token cost reduction
Use /cost in Claude Code to monitor cache hit rates and validate that the caching is working
Monorepos with large shared context (types, configs, schemas) benefit disproportionately — the cache amortizes that fixed overhead across every prompt in the session