← Agent Frameworks 🕐 16 min read
Agent Frameworks

Bedrock Prompt Caching — Deep Mechanics and Cost Optimization (2026)

What This Note Covers · March 2026

Prompt caching on Amazon Bedrock is one of the highest-leverage cost levers available to teams running Claude at scale.

Prompt caching on Amazon Bedrock is one of the highest-leverage cost levers available to teams running Claude at scale. The mechanism is straightforward in concept — cache a prefix, pay less to re-read it — but the economics are non-obvious. The write premium, the TTL tier tradeoff, the model-specific minimum token thresholds, and the ordering constraint on multi-TTL requests all have direct dollar consequences. Teams that deploy caching without understanding the break-even math frequently find their bill increasing rather than decreasing.

This note covers the full mechanics: how cache checkpoints work internally, where to place them, what the two TTL tiers actually cost and when each makes sense, how to calculate break-even hit rates, and how to monitor cache effectiveness in production. It closes with three production patterns — agent loop caching, RAG caching, and multi-turn conversation caching — with realistic ROI calculations for each.

1. How Prompt Caching Works Mechanically

When Bedrock receives an inference request with a cachePoint block, it computes a fingerprint of the token sequence that precedes the cache marker. If a matching fingerprint exists in the regional cache and has not expired, the model skips recomputation of those tokens and reads the cached KV state instead. The caller is charged at the reduced cache-read rate for those tokens.

On a cache miss — first call, TTL expiry, or any change to the prefix — Bedrock runs full inference on the prefix tokens, writes the resulting KV state to cache, and charges at the write-premium rate.

Three things follow from this architecture:

The cache is a prefix cache, not a semantic cache. It matches token-by-token from the start of the prompt. A single character change before the cache marker — even a trailing space — invalidates the entry. Semantic similarity is irrelevant.

Cached tokens still consume context window. The cache stores computation, not tokens. The full prompt (including cached sections) still counts against the model’s context window limit.

The cache is regional. Cache entries do not replicate across AWS regions. If cross-region inference routes a request to a different region, it will be a cache miss. In high-demand periods, cross-region inference may increase write frequency as requests distribute across regions.

2. Supported Models and Minimum Token Thresholds

Not all models support the same cache checkpoint behavior. The thresholds as of mid-2026:

Model Min tokens per checkpoint Max checkpoints Supported TTLs Cacheable fields
Claude Sonnet 4.6 1,024 4 5m system, messages, tools
Claude Opus 4 1,024 4 5m system, messages, tools
Claude 3.7 Sonnet 1,024 4 5m system, messages, tools
Claude 3.5 Sonnet v2 1,024 4 5m (preview) system, messages, tools
Claude Opus 4.5 4,096 4 5m, 1h system, messages, tools
Claude Sonnet 4.5 4,096 4 5m, 1h system, messages, tools
Claude Haiku 4.5 4,096 4 5m, 1h system, messages, tools
Claude Opus 4.6 4,096 4 5m system, messages, tools

The minimum applies to the cumulative token count across all three sections (tools → system → messages) up to the cache marker, not per section. This matters when placing checkpoints across fields: a tools definition of 600 tokens and a system prompt of 500 tokens combine to 1,100 tokens, which meets the 1,024-token threshold for Sonnet 4.6 or Opus 4 even if neither section alone does.

If a cache checkpoint is placed before the minimum token count is reached, inference succeeds normally — the prefix is simply not cached. There is no error. This silent non-caching is the most common source of “I added caching but my costs didn’t change” reports.

3. TTL Tiers: When 5-Minute vs. 1-Hour Makes Economic Sense

The Two Tiers

AWS Bedrock currently offers two TTL options:

  • 5-minute TTL — default; sliding window that resets on each successful cache hit
  • 1-hour TTL — available for Claude Opus 4.5, Sonnet 4.5, and Haiku 4.5 only; requires explicit "ttl": "1h" in the cache point block

The pricing structure differs between the two tiers. The 5-minute TTL write costs approximately 1.25× the standard input token rate. The 1-hour TTL write costs approximately 2.0× the standard input token rate. Both tiers share the same read rate: approximately 0.1× the standard input token rate (a 90% discount).

The 1-hour TTL premium reflects the substantially larger infrastructure cost of maintaining cache entries for an extended window. AWS is provisioning KV state storage and ensuring cache availability for twelve times as long as the default tier.

Break-Even Hit Rate by Tier

The break-even hit rate is the cache hit rate at which caching breaks even with no-caching in terms of total cost.

For a prefix of N tokens at a base rate of P per token:

No-caching baseline cost per request: N × P

With 5-minute TTL:

  • Cache-write cost: N × 1.25P
  • Cache-read cost: N × 0.1P
  • Savings per read vs. no-caching: N × 0.9P
  • Extra cost per write vs. no-caching: N × 0.25P

Break-even: extra write cost equals saved read cost on the first hit.

  • First call: pay 0.25P extra over baseline
  • First cache hit: save 0.9P below baseline
  • Net after one hit: 0.25P extra + (−0.9P) = −0.65P savings
  • Break-even at approximately 28% hit rate (1 in 3.6 calls must be a cache hit)

In practice, the economic rule is: if the same prefix will be sent more than twice before the cache expires, the 5-minute TTL is cost-positive from the third call onward.

With 1-hour TTL:

  • Cache-write cost: N × 2.0P
  • Cache-read cost: N × 0.1P
  • Extra cost per write vs. no-caching: N × 1.0P

Break-even: the extra 1.0P per write requires savings from reads.

  • Each cache hit saves 0.9P
  • Break-even: 1.0 / 0.9 ≈ 1.1 hits to break even
  • Break-even at approximately 53% hit rate (just over half of calls must be cache hits)

The 1-hour TTL pays off only when the hit rate is reliably above 50%. This makes it unsuitable for bursty or unpredictable workloads. It is the right choice for agentic workflows where the same session context is re-used over an extended period, or batch processing pipelines where many documents are processed sequentially with a shared system prompt.

Choosing Between Tiers — Decision Rules

Choose the 5-minute TTL when:

  • User interactions are frequent (multiple messages per session within a 5-minute window)
  • Traffic is predictable and high-volume (hit rate reliably above 30%)
  • The workload is conversational (each turn extends a shared prefix)
  • You need cache availability at no extra write cost for high-cadence use

Choose the 1-hour TTL when:

  • Sessions involve low-cadence interactions (user may take 10–30 minutes between turns)
  • Agentic sub-agents run long multi-step workflows lasting more than 5 minutes
  • Batch processing jobs share a long system prompt and tool definition across hundreds of sequential requests
  • You can forecast that the hit rate will exceed 50% for the cached prefix

Ordering Constraint

When mixing TTL tiers in a single request (both a 1-hour and a 5-minute cache point), the longer TTL entry must appear first in the prompt. A 1-hour cache checkpoint must precede any 5-minute cache checkpoint in the same request. Violating this order produces an error.

Concretely: cache the most stable content (tool definitions, base system prompt) with a 1-hour TTL at the top of the prompt; cache less stable content (extended context appended per session) with a 5-minute TTL below it.

4. CachePointBlock Placement Strategy

Section Processing Order

Bedrock processes cache checkpoints in a fixed order across sections: tools → system → messages. The minimum token count is evaluated cumulatively across all three in this order, not per-section independently. Content earlier in the chain affects caching of content later in the chain — modifying the tools section invalidates both the system and messages caches.

Converse API Placement

In the Converse API, a cache checkpoint is a content block object inserted after the content you want cached:

# System prompt caching
system=[
    {"text": "Your full system prompt text here..."},
    {"cachePoint": {"type": "default"}}                 # 5-minute TTL (default)
    # OR: {"cachePoint": {"type": "default", "ttl": "1h"}}  # 1-hour TTL
]

# Tool definition caching
toolConfig={
    "tools": [
        {"toolSpec": { ... }},     # tool definition
        {"toolSpec": { ... }},     # more tools
        {"cachePoint": {"type": "default"}}   # cache all tools above this line
    ]
}

# Message history caching (conversation prefix)
messages=[
    {"role": "user", "content": [{"text": "Prior user message"}]},
    {"role": "assistant", "content": [{"text": "Prior assistant response"}]},
    {"role": "user", "content": [
        {"text": "Next user message"},
        {"cachePoint": {"type": "default"}}   # cache everything above
    ]}
]

InvokeModel API Placement (Anthropic Claude format)

For direct InvokeModel calls using the Anthropic message format, use cache_control instead of cachePoint:

body={
    "anthropic_version": "bedrock-2023-05-31",
    "system": "Your system prompt...",
    "messages": [
        {
            "role": "user",
            "content": [
                {
                    "type": "text",
                    "text": "Large reference document text here...",
                    "cache_control": {"type": "ephemeral"}   # marks cache boundary
                },
                {
                    "type": "text",
                    "text": "User question goes here (not cached)"
                }
            ]
        }
    ],
    "max_tokens": 2048
}

Simplified Cache Management

For Claude models, Bedrock offers a simplified mode: place a single cache checkpoint at the end of your static content, and Bedrock automatically looks back up to approximately 20 content blocks from that marker to find the longest matching cache prefix. This reduces the need to predict exact optimal checkpoint placement. If your static content spans more than approximately 20 content blocks, use multiple explicit checkpoints or restructure the prompt.

Placement Principles for Maximum Hit Rate

Stable content before dynamic content. Every character before the cache marker must be identical across requests for a cache hit to occur. Sort content by how frequently it changes, with the most stable content earliest in the prompt.

Hierarchy of stability (most stable to least):

  1. Tool definitions (change only when schema changes)
  2. System prompt base instructions (change only with new deployments)
  3. Injected reference documents (change per document, stable within a session)
  4. Conversation history (grows with each turn)
  5. Current user message (changes every turn — never cache this)

Use multiple checkpoints for independently-varying sections. If your tool definitions change independently of your system prompt, place a checkpoint after tools and another after the system prompt. Caches for the two sections then expire and invalidate independently.

Never modify a cached prefix during a session. Appending to a session’s conversation history is fine — the new messages come after the existing cache point. But editing or replacing earlier messages that precede a checkpoint invalidates the cache for that checkpoint.

5. Cache Invalidation — What Breaks the Cache

Understanding invalidation is essential to debugging unexpected cache misses.

TTL expiry. The TTL is a sliding window, not a fixed window. Each successful cache hit resets the clock. A 5-minute TTL cache entry that is hit every 3 minutes will persist indefinitely. One that is not hit for 5 minutes expires. For 1-hour TTL, the window is 60 minutes from the last hit.

Any prefix modification. A single token change — a different character, an added space, a reordered instruction — produces a different fingerprint. The old cache entry becomes unreachable. This is the most common cause of unexpected misses. Sources include:

  • Template rendering that injects timestamps or session IDs into the system prompt
  • Tool schemas generated dynamically with non-deterministic field ordering
  • Whitespace normalization differences between requests

Model version change. Cache entries are scoped to a specific model ID. Switching from anthropic.claude-sonnet-4-5-20250929-v1:0 to a different version ID clears the cache for that prefix.

Regional routing change. As noted, cross-region inference may route to a different region, producing a cache miss. The entry in the original region remains valid but is inaccessible to the re-routed request.

Explicit cache checkpoint below minimum token threshold. If the prefix doesn’t meet the minimum token count for the model, no cache entry is written. Subsequent calls also miss because there is nothing to hit.

6. Reading Cache Effectiveness from API Responses

The Converse API response includes three fields under usage when prompt caching is active:

{
  "usage": {
    "inputTokens": 87,
    "outputTokens": 234,
    "totalTokens": 321,
    "cacheReadInputTokens": 4321,
    "cacheWriteInputTokens": 0
  }
}

inputTokens — tokens that were not read from cache and not written to cache. These are charged at the standard input rate.

cacheReadInputTokens — tokens retrieved from the cache. Charged at approximately 0.1× the standard rate.

cacheWriteInputTokens — tokens written to the cache in this request. Charged at 1.25× (5-minute TTL) or 2.0× (1-hour TTL) the standard rate.

Total input tokens sent: inputTokens + cacheReadInputTokens + cacheWriteInputTokens

An important implication: a request showing inputTokens: 87 with cacheReadInputTokens: 4321 means 98% of the input was served from cache. The billing reflects this — you pay for 87 tokens at standard rate and 4,321 tokens at the 0.1× read rate. The effective cost of the input portion is approximately 10% of what it would be without caching.

A cacheWriteInputTokens: 4321 with cacheReadInputTokens: 0 means this was a cold write — the cache was populated but not yet read. You are paying the write premium with no offsetting savings on this request.

7. CloudWatch Monitoring and Alerting

Amazon Bedrock automatically publishes cache metrics to CloudWatch in the AWS/Bedrock namespace when prompt caching is active.

Native CloudWatch metrics:

  • CacheReadInputTokenCount — tokens served from cache per request
  • CacheWriteInputTokenCount — tokens written to cache per request
  • Standard InputTokenCount — non-cached, non-written tokens

Cache hit rate calculation:

Cache Hit Rate = CacheReadInputTokenCount / (CacheReadInputTokenCount + InputTokenCount + CacheWriteInputTokenCount)

This denominator is the total input token count sent. The hit rate is the fraction of those tokens that were served from cache rather than reprocessed.

Custom CloudWatch metric (recommended):

Push a derived CacheHitRate metric from your application layer to capture the per-request rate with model and endpoint dimensions:

import boto3

cloudwatch = boto3.client("cloudwatch")

def record_cache_metrics(response, model_id: str, use_case: str):
    usage = response["usage"]
    cache_read = usage.get("cacheReadInputTokens", 0)
    cache_write = usage.get("cacheWriteInputTokens", 0)
    standard = usage.get("inputTokens", 0)
    total = cache_read + cache_write + standard

    hit_rate = (cache_read / total * 100) if total > 0 else 0.0

    cloudwatch.put_metric_data(
        Namespace="BedrockLLMOps",
        MetricData=[
            {
                "MetricName": "CacheHitRate",
                "Value": hit_rate,
                "Unit": "Percent",
                "Dimensions": [
                    {"Name": "ModelId", "Value": model_id},
                    {"Name": "UseCase", "Value": use_case},
                ],
            },
            {
                "MetricName": "CacheReadTokens",
                "Value": cache_read,
                "Unit": "Count",
                "Dimensions": [{"Name": "ModelId", "Value": model_id}],
            },
            {
                "MetricName": "CacheWriteTokens",
                "Value": cache_write,
                "Unit": "Count",
                "Dimensions": [{"Name": "ModelId", "Value": model_id}],
            },
        ],
    )

CloudWatch Insights query — hourly cache efficiency:

fields @timestamp, @message
| filter @logStream like /bedrock/
| stats
    sum(cacheReadTokens) as totalReads,
    sum(cacheWriteTokens) as totalWrites,
    sum(inputTokens) as totalStandard,
    (sum(cacheReadTokens) / (sum(cacheReadTokens) + sum(cacheWriteTokens) + sum(inputTokens))) * 100 as hitRatePct
| by bin(1h)

Alerting thresholds by use case:

Use case Healthy hit rate Alert threshold Interpretation below threshold
Chatbot / conversational ≥ 70% < 50% Prefix likely not stable; check for per-request timestamp injection
RAG document Q&A ≥ 80% < 60% Retrieval context changing too frequently; check chunking strategy
Agent loop ≥ 85% < 70% Tool definitions or system prompt being regenerated unnecessarily
Batch processing ≥ 90% < 80% Requests not sharing the same prefix; check batch grouping logic

A hit rate below the alert threshold does not mean caching is broken — it means caching is not working as intended and the write premiums are eroding savings.

8. Production Caching Patterns

Pattern 1: Agent Loop Caching

In agentic systems, each turn of an agent loop typically sends: the system prompt + tool definitions + the full conversation history (all prior tool calls and results) + the new user message or tool result.

The system prompt and tool definitions are entirely stable within a session. Caching them eliminates their reprocessing cost on every loop iteration.

Implementation:

def build_agent_request(system_prompt: str, tools: list, messages: list) -> dict:
    return {
        "modelId": "anthropic.claude-sonnet-4-6",
        "system": [
            {"text": system_prompt},
            {"cachePoint": {"type": "default"}}   # cache the full system prompt
        ],
        "toolConfig": {
            "tools": [
                *[{"toolSpec": t} for t in tools],
                {"cachePoint": {"type": "default"}}   # cache all tool definitions
            ]
        },
        "messages": messages,   # conversation history grows here; no cache point needed
        "inferenceConfig": {"maxTokens": 4096}
    }

With this structure, on turn N of a 10-turn agent loop:

  • Turn 1: full write cost for system prompt + tools (cache miss, prefix written)
  • Turns 2–10: read cost at 0.1× for system prompt + tools on every turn

If the system prompt is 2,000 tokens and the tool definitions are 1,500 tokens (3,500 total), the cache covers 3,500 tokens per turn. Over 10 turns: 9 reads × 3,500 × 0.1× rate versus 9 reads × 3,500 × standard rate without caching. Net savings: ~85% on the stable prefix across a 10-turn session.

For sessions lasting more than 5 minutes (common in complex agentic workflows), use the 1-hour TTL on the system prompt and tools cache point to prevent mid-session expiry:

{"cachePoint": {"type": "default", "ttl": "1h"}}

ROI calculation (illustrative, Claude Sonnet 4.6 pricing):

  • Base input rate: ~$3.00 / million tokens
  • 5-min write rate: ~$3.75 / million tokens
  • Read rate: ~$0.30 / million tokens

For 1,000 agent sessions/day, 10 turns each, 3,500-token stable prefix:

  • Without caching: 1,000 × 10 × 3,500 × $3.00/M = $105/day
  • With caching: write cost (1,000 × 3,500 × $3.75/M) + read cost (1,000 × 9 × 3,500 × $0.30/M) = $13.13 + $9.45 = $22.58/day
  • Savings: ~78.5% on the stable prefix portion

Pattern 2: RAG Document Caching

In a retrieval-augmented system, retrieved context is typically the largest component of the input. If multiple questions are asked against the same retrieved document in the same session, caching the retrieved context is straightforward.

Structure:

def build_rag_request(system_prompt: str, retrieved_doc: str, user_question: str,
                      conversation_history: list) -> dict:
    return {
        "modelId": "anthropic.claude-sonnet-4-6",
        "system": [{"text": system_prompt}],
        "messages": [
            # First turn: inject the document, mark cache boundary
            {
                "role": "user",
                "content": [
                    {"text": f"Reference document:\n\n{retrieved_doc}"},
                    {"cachePoint": {"type": "default"}}   # cache document here
                ]
            },
            {"role": "assistant", "content": [{"text": "Understood. I have reviewed the document."}]},
            # Subsequent turns: add conversation history, then new question
            *conversation_history,
            {"role": "user", "content": [{"text": user_question}]}
        ],
        "inferenceConfig": {"maxTokens": 1024}
    }

On the first question, the document is written to cache. All subsequent questions in the same session hit the cache for the document tokens.

Critical constraint: The retrieved document must be identical byte-for-byte across requests. If retrieval re-ranks or reformats the document between queries, the cache misses. For caching to work in RAG, the application must retrieve the document once per session and hold it in memory, not re-retrieve on each question.

ROI calculation (20,000-token document, 10 questions per session):

  • Document tokens: 20,000
  • First question: write cost
  • Questions 2–10: read cost

Savings per session versus uncached:

  • Without caching: 10 × 20,000 × $3.00/M = $0.60 in document tokens alone
  • With caching: write (20,000 × $3.75/M) + 9 reads (20,000 × $0.30/M) = $0.075 + $0.054 = $0.129
  • Savings: ~78.5% on the document token portion per session

Pattern 3: Multi-Turn Conversation Caching

In a long-running conversation, prior conversation turns constitute a growing prefix. As the conversation grows, caching the history reduces reprocessing costs.

The diminishing returns problem: Each new assistant + user turn pair adds content that is unique to this session. On turn N, the cacheable prefix includes turns 1 through N−1. The cache is written when those turns are new and hits on turn N+1. But the cache point must be placed before the most recent user message — which means the cache grows one turn at a time and each new turn triggers a write.

def build_conversation_request(system_prompt: str, messages: list) -> dict:
    # Place cache point after all but the last user message
    if len(messages) >= 3:
        cacheable = messages[:-1]   # everything except current user message
        current = messages[-1:]
        
        # Insert cache point at end of cacheable history
        cacheable_with_cp = list(cacheable)
        last_cacheable = cacheable_with_cp[-1]
        last_cacheable["content"].append({"cachePoint": {"type": "default"}})
        
        final_messages = cacheable_with_cp + current
    else:
        final_messages = messages

    return {
        "modelId": "anthropic.claude-sonnet-4-6",
        "system": [
            {"text": system_prompt},
            {"cachePoint": {"type": "default"}}
        ],
        "messages": final_messages,
        "inferenceConfig": {"maxTokens": 512}
    }

This yields cache hits on the conversation history prefix for every turn after the second. The savings grow as the conversation grows — a 20-turn conversation where each turn adds ~200 tokens accumulates ~3,800 cacheable tokens by turn 20. The reprocessing savings on those 3,800 tokens at turn 20 offset the write premium from turns 2–19.

Note on the 4-checkpoint limit. Up to 4 cache checkpoints per request. A typical deployment uses one for the system prompt, one for tools (if any), and one for the conversation history. The fourth is available for injected reference content. Using all four requires careful placement — they must appear in stability order with longer TTLs first.

9. Common Failure Modes and Debugging

Symptom: CacheWriteInputTokens always nonzero, CacheReadInputTokens always zero.

Cause: Every request is a cache miss. Likely causes:

  1. Prefix is not byte-identical — inspect for timestamp injection, dynamic UUIDs, or non-deterministic serialization in system prompt or tool definitions
  2. Model version mismatch — verify the same modelId string is used on every call
  3. TTL expiry — requests are spaced more than 5 minutes apart and the 5-minute TTL is in use; switch to 1-hour TTL

Symptom: CacheReadInputTokens present but lower than expected.

Cause: Partial cache hit. The cache matched a prefix shorter than expected. Likely: a later section of the prompt changed, causing a checkpoint earlier in the prompt to be the last matched point. Check whether tool definitions or system prompt text is being modified between requests.

Symptom: Billing increased after enabling caching.

Cause: Cache hit rate is below break-even. For 5-minute TTL, below ~28%; for 1-hour TTL, below ~53%. Diagnose by computing CacheReadInputTokens / (CacheReadInputTokens + InputTokens + CacheWriteInputTokens) per time period. If below threshold, the write premium is the problem — either increase request frequency (reduce inter-request gaps to below the TTL) or disable caching for this workload.

Symptom: Cache works in development, misses in production.

Likely causes:

  1. Multiple Lambda invocations or containers each starting with a cold cache — first requests from each container always write
  2. Cross-region inference routing requests to different regions
  3. Production system prompt template differs slightly from development (different environment variables, different feature flags)

Verifying a cache hit — minimal test:

import boto3, json

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")
system_text = "A" * 2000   # approximately 500 tokens of padding

def send_with_cache():
    resp = bedrock.converse(
        modelId="anthropic.claude-sonnet-4-6",
        system=[
            {"text": system_text},
            {"cachePoint": {"type": "default"}}
        ],
        messages=[{"role": "user", "content": [{"text": "Say hello."}]}],
        inferenceConfig={"maxTokens": 10}
    )
    usage = resp["usage"]
    print(f"Read: {usage.get('cacheReadInputTokens', 0)}, "
          f"Write: {usage.get('cacheWriteInputTokens', 0)}, "
          f"Standard: {usage.get('inputTokens', 0)}")

send_with_cache()   # expect: Write > 0, Read == 0
send_with_cache()   # expect: Read > 0, Write == 0

If the second call shows Read == 0, the cache is not working. Check minimum token threshold (system_text needs to meet the model’s minimum after tokenization) and verify the model ID is cache-capable.

10. FinOps Summary — Key Numbers

Parameter 5-minute TTL 1-hour TTL
Write cost multiplier 1.25× base input rate 2.0× base input rate
Read cost multiplier 0.1× base input rate 0.1× base input rate
Break-even hit rate ~28% ~53%
Break-even call count 2nd call 2nd call (if hit rate sustained)
Best use case High-frequency conversational Low-cadence sessions, batch
Supported models All cache-capable Claude Opus/Sonnet/Haiku 4.5 only
Max cache points per request 4 4 (mixed TTL: longer before shorter)

At scale impact (illustrative):

For a production deployment processing 100,000 requests/day with a 5,000-token stable prefix at 80% hit rate on Claude Sonnet 4.6:

  • Without caching: 100,000 × 5,000 × $3.00/M = $1,500/day
  • With caching at 80% hit rate:
    • Writes (20%): 20,000 × 5,000 × $3.75/M = $375/day
    • Reads (80%): 80,000 × 5,000 × $0.30/M = $120/day
    • Total: $495/day
  • Daily savings: $1,005 (67%)
  • Annual savings: ~$367,000

The ratio is not linear with hit rate — at 50% hit rate the savings drop to ~43%, and at 28% hit rate (break-even) costs are flat. Maintaining hit rate above 70% is the primary operational objective.

Sources