Claude API Gateway: Is Prompt Caching Really Working?

A lower token price looks attractive until your application keeps paying to process the same long context.

A cache discount looks even better—provided your requests actually use it.

When evaluating a Claude API gateway, there are three separate questions:

1. Does the route support the caching behavior you need?
2. Do your requests generate cache reads?
3. Does the gateway’s billing reflect those reads in a useful way?

A pricing table cannot answer all three.

This article shows how to run a controlled cache experiment before estimating savings. It focuses on an existing Claude workload with repeated context, rather than promising a universal percentage reduction.

The aim is to leave with a measurable answer: does this Claude route make repeated requests less expensive for your actual request pattern?

First, decide whether your workload has anything to reuse

Consider two applications.

The first sends an unrelated short prompt for every request. It rarely repeats substantial context.

The second sends the same long instruction set and reference material with many different questions.

Both use Claude. Their opportunities for caching are very different.

Before looking at a gateway’s cache pricing, inspect a sample of your own requests:

• How much content repeats?
• Is that content at the beginning of the request?
• Does it remain identical between calls?
• How much time passes before it is reused?
• Does the model or configuration change between calls?

These questions determine whether a cache experiment is worth running.

Do not add unnecessary text simply to make a cache statistic look better. A cached request that processes irrelevant material can still be worse than a shorter request designed around the task.

Understand the native counters before reading a dashboard

Claude’s native caching documentation distinguishes three input categories:

• input_tokens: input outside cache reads and writes.
• cache_creation_input_tokens: newly cached input.
• cache_read_input_tokens: input reused from cache.

For this native accounting structure:

total input =
    input_tokens
  + cache_creation_input_tokens
  + cache_read_input_tokens

Caching can be requested with cache_control, and eligibility depends on the model’s minimum cacheable length and other documented conditions.

See Claude prompt caching for the current details.

A gateway may expose a different accounting format. Do not apply this formula to renamed or aggregated fields until you know what those fields represent.

Most importantly, a missing field is not the same as a reported zero.

Design one experiment with three requests

You do not need a large benchmark to establish an initial signal.

Use a fixed, non-sensitive reference document that is long enough to qualify under the selected model’s documented requirements.

Keep the model, route, token group, and relevant settings constant.

Then send:

Run the requests sequentially and close enough together for the configured cache lifetime. Complete the first request before starting the next one.

Keep the questions short and comparable. If one request asks for a sentence and another asks for a long report, output differences will make total charges harder to compare.

This is an experiment design, not a guarantee that request B will hit a cache. If it does not, the failure is useful information.

Keep changing metadata outside the reusable prefix

An application can accidentally change context it considers “static.”

Examples include:

• A generated timestamp inserted into the system prompt.
• Tool definitions emitted in a different order.
• A request identifier added before the reference document.
• A freshly generated summary replacing the original instructions.

Anthropic’s cache diagnostics guide specifically addresses comparing consecutive request structures and locating divergence.

For the initial experiment, simplify the request. Put stable instructions and reference material in a stable order, then place the changing question afterward.

Avoid reorganizing the prompt and changing the gateway at the same time. You want to know which change produced the result.

If you later use provider-specific diagnostics, verify that the selected gateway route supports those fields. Their availability on the direct API is not proof of gateway support.

Record evidence without turning missing data into zeros

Here is a local helper for inspecting a saved native Claude response:

def cache_observation(response: dict) -> dict:
    usage = response.get("usage")

    if not isinstance(usage, dict):
        return {
            "status": "usage_unavailable",
            "input_total": None
        }

    fields = (
        "input_tokens",
        "cache_creation_input_tokens",
        "cache_read_input_tokens",
    )

    missing = [field for field in fields if field not in usage]

    if missing:
        return {
            "status": "incomplete_native_usage",
            "missing_fields": missing,
            "input_total": None
        }

    values = {field: usage[field] for field in fields}

    if any(type(value) is not int or value < 0
           for value in values.values()):
        return {
            "status": "unexpected_usage_values",
            "input_total": None
        }

    return {
        "status": "observed",
        **values,
        "input_total": sum(values.values()),
    }

This code inspects a response you already have. It does not send requests or establish that a gateway uses native Claude accounting.

The deliberate choice is to return an unknown result when evidence is missing.

A dashboard that shows only “total tokens” may still be useful for overall monitoring. It is insufficient for this particular cache experiment unless its detailed logs expose the relevant breakdown.

Read the outcome carefully

Several outcomes are possible.

A reports cache creation, and B and C report cache reads.

That supports the conclusion that reuse occurred for this controlled sequence.

It does not yet establish the savings on your production workload, which may have different timing, prompts, or routing behavior.

Every request reports new cache creation.

Something is preventing repeat reuse. Compare the requests, timing, configuration, and route behavior. Avoid immediately increasing the cache lifetime without identifying the cause.

All reported cache counters are zero.

Check the selected model’s eligibility requirements and whether the requested caching configuration is supported. A short prompt can be a valid API request without being cacheable.

The relevant fields are absent.

The result is inconclusive. Ask whether the gateway exposes native counters, a documented alternative, or billing-log details that can answer the same question.

Only total charges are available.

You can compare charges under controlled conditions, but you cannot confidently attribute a difference to caching alone. Output length and other billing components may vary.

Separate cache behavior from gateway pricing

Suppose your experiment confirms repeated cache reads.

You still need the applicable rates for your specific gateway group.

If the gateway separately prices ordinary input, cache writes, cache reads, and output, use:

request cost =
    uncached input × uncached rate
  + cache writes × write rate
  + cache reads × read rate
  + output × output rate
  + any separately billed services

Keep all rates in the same currency and token unit.

If the gateway uses an all-inclusive or otherwise different billing scheme, use that scheme instead. Do not reconstruct a fictional native invoice from fields that the provider does not bill separately.

The 4SAPI pricing page is a starting point for model rates. Confirm the actual group and billing rules in your account before calculating expected savings.

This step is particularly important when comparing two routes with different advertised discounts. A lower ordinary-input rate and a better cache-read rate are different advantages.

Turn the experiment into a buying decision

Imagine two candidate routes.

Route A has a lower ordinary input price. Route B has a higher ordinary input price but provides a documented, observable cache-read benefit.

Which route should you choose?

There is no universal answer.

For a workload with little reusable context, route A may be preferable.

For repeated long prefixes, route B may be more economical—but only after accounting for cache writes, reuse frequency, output, and the real billing terms.

Use your observed request distribution:

expected workload cost =
    cost of first-use requests
  + cost of repeated requests
  + cost of requests that miss the cache
  + output and other applicable charges

Do not forecast the entire month from a single successful cache hit. Measure a small representative sample first.

Also retain a no-cache estimate. It provides a useful budget boundary when the workload changes or cache reuse becomes less consistent.

How to evaluate the Claude route on 4SAPI

4SAPI documents a native Claude Messages interface at:

POST https://4sapi.com/v1/messages

The documentation also distinguishes model availability by group.

That provides a place to begin the integration. It does not establish that every group exposes identical caching behavior or identical usage fields.

For this experiment:

1. Select the exact Claude model available to your token.
2. Confirm support for the caching configuration you intend to use.
3. Run the three-request sequence with a fixed development fixture.
4. Preserve the response usage data.
5. Match each request to its account log.
6. Compare observed charges with the documented billing method.

The 4SAPI usage-log instructions explain where to inspect individual consumption records.

If a field or charge cannot be explained, resolve that uncertainty before increasing traffic.

When the experiment is successful

Success is not merely seeing a nonzero cache counter.

A useful evaluation produces four things:

• A repeatable request pattern that generates reuse.
• Usage evidence you can interpret.
• Charges that match the applicable billing rules.
• A reasonable estimate based on your real reuse frequency.

That is enough to make a grounded decision about a Claude API relay.

If repeated context is a meaningful part of your workload, create a 4SAPI account and use a small, capped development test to evaluate the relevant Claude group. Confirm advanced-feature support before committing a larger budget.

Choose the route that makes its behavior and costs explainable. A cache discount is valuable when your application can actually use it.