Home / The Claude API for builders

Two cost levers: cached memory and batch processing

A request prefix marked as reusable costs a reduced fraction of the normal price when read back from the cache, and a set of non-urgent requests processed in a batch costs less than immediate processing, two discounts that stack with each other and with the other pricing modifiers.

Two mechanisms reduce the cost of a request to the Messages API without changing its response: cached memory reuses a stable prefix from one request to the next, and batch processing groups non-urgent requests into a delayed send.

Cached memory: a read cheaper than a normal input

Marking a content block as reusable creates a breakpoint in the request: everything before that point can be read back from the cache on a later call that shares exactly the same prefix. A cache read costs a reduced fraction of the normal input price for nearly all current models, the figure in this lesson gives the exact rate with its source. Writing to the cache for the first time, by contrast, costs more than a normal input, and is chosen between two retention durations, five minutes or one hour, the longer one costing more to write. The cache pays for itself from the very first re-read under five-minute retention, the default duration, and only from the second re-read onward under one-hour retention.

Batch processing: a delayed send at a reduced price

The batch processing API accepts a set of independent requests and processes them in a delayed fashion, with a fixed discount on both input and output tokens, whatever model is called, also stated in the figure in this lesson. This discount suits work that does not need an immediate response: classifying a batch of documents, generating summaries in series, or rebuilding a test dataset. The two mechanisms stack with each other and with the other pricing modifiers: a prefix cached then re-read in a request sent as part of a batch benefits from both discounts at once.

The same stable prefix that benefits from the cache also counts toward the calculation of the context window before sending, since marking a block as reusable does not change its weight in tokens at all.

import anthropic

client = anthropic.Anthropic()

instructions_stables = "Vous etes un assistant qui repond en une phrase. " * 200

reponse = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=100,
    system=[
        {
            "type": "text",
            "text": instructions_stables,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "Resume ce texte en une phrase."}],
)

print("jetons ecrits en cache :", reponse.usage.cache_creation_input_tokens)
print("jetons lus depuis le cache :", reponse.usage.cache_read_input_tokens)

The first call with this prefix pays the write rate, and a second call that reuses exactly the same text before the breakpoint pays the reduced read rate. The response's usage field distinguishes the two counters, which makes it possible to check that the cache was actually hit rather than assume it. A prefix that is too short, below a minimum threshold that ranges from 512 to 4,096 tokens depending on the model called, is never cached and shows no error, the request simply goes out at the normal rate.