Prompt cache and the Batch API, two discounts worth knowing
The prompt cache charges reading of an identical prefix at around ten per cent of the normal input price, with a lifetime that depends on the offering, one hour for the main conversation of a paid subscription used within its plan, five minutes for an API key or a sub agent; the Batch API, for its part, processes a batch of requests asynchronously with a fifty per cent discount, on a separate rate limit quota.
The prompt cache and the Batch API are two different discounts on the same token cost, and they do not reward the same thing. The cache rewards a start of conversation that does not change, the Batch API rewards a volume of requests that can wait.
The cache, a discount on what does not change
When a message reuses a start identical down to the byte to that of a previous message, reading that already computed portion is billed at around ten per cent of the normal input price, instead of the full rate. This discount applies only to the portion of the message that stays exactly identical: from the very first character that differs, the portion that follows is no longer considered a cached prefix and is billed at the normal rate.
The cache's lifetime depends on your offering
This point differs according to how Claude is used. On a paid Claude subscription, used within the normal scope of the plan, the main Claude Code conversation benefits from a cache lifetime of one hour between two messages that share the same start. On an API access key, the interface that lets a program send messages directly to Claude without going through the usual conversation window, or for a sub agent, this lifetime drops by default to five minutes, even if the account otherwise uses a paid subscription. This five minute default is not set in stone: the promptCacheTtl and subagentPromptCacheTtl settings allow explicitly requesting a one hour lifetime on an API key or for a sub agent. Without this setting, a pause of more than an hour on the main conversation, or of more than five minutes elsewhere, drops the prefix out of the cache: the next message pays the full rate on that portion again.
The Batch API, a discount on volume, not on speed
The Batch API processes a set of requests asynchronously, that is, without waiting for an immediate response to each one, with a fifty per cent discount on both input and output. It relies on a rate limit quota separate from the usual limits of a conversation, which makes it useful for a batch of repetitive tasks, for example rephrasing the same question across several dozen documents. Sending such a batch requires going through developer access to the API: flag this need to whoever in your organisation already manages that access, describing the volume and frequency of the batch of repetitive tasks, and in the meantime keep handling your questions one by one in the usual conversation.
Message 1: general instructions (identical) + document A
Message 2: same general instructions + document B
This identical start, stable general instructions plus a document that changes, remains eligible for the cache reading discount described above, and echoes the same principle set out in the four levers of a long session.
Two discounts on the token cost
A non-profit uses a paid Claude subscription within the normal scope of its plan. An employee opens a Claude Code conversation in the morning, pastes their project instructions as the first message, then asks several successive questions on that same project through the morning, with twenty minute pauses between each question.
Write, in one sentence, what this situation establishes, and in one sentence what it does not establish.
What this establishes: What the situation describes stays within the one hour window documented for the main conversation of a subscription used within its plan, so the prefix set in the first message remains eligible for the cache reading discount throughout the morning.
What this does not establish: It does not establish that the same behaviour applies to an API key or a sub agent, whose cache lifetime defaults to five minutes rather than one hour, unless a one hour lifetime is explicitly requested through the settings provided for that purpose.
The three most common miscalibrations
- Too broad The prompt cache stays active indefinitely as long as the conversation is not closed, regardless of the time between two questions.
- Too narrow Nothing can be said about the cache until the exact content of the project instructions is known.
- Off target The employee spaced out their questions by twenty minutes because other tasks kept them busy that morning.
- Reading a prefix already in the cache costs around ten per cent of the normal input price, on the subscription side as much as on the API access side.
- The cache's lifetime differs by default depending on the offering used, subscription or API access, but the promptCacheTtl and subagentPromptCacheTtl settings allow requesting one hour even on an API key or for a sub agent.
- The Batch API processes a batch of requests asynchronously with a fifty per cent discount, on a rate limit quota separate from the usual limits.
- A message start identical down to the byte is the condition that triggers the cache reading discount, a single difference at the start cancels the discount on everything that follows.
In your next conversation that asks several questions on the same subject, copy the very first lines of instructions identically from one message to the next, without changing a single word, so that reading this start keeps being billed at the cache's reduced rate.
These points depend on an interface or a rule that may have changed since this was written. Check them on your own screen before relying on them.
- Check, in your Claude account's settings or billing, whether you use a paid subscription within its normal plan or API key access: the cache lifetime is not the same in the two cases.
Every datable claim in this lesson links here to the public text behind it. A source that does not open proves nothing.
- Prompt caching, cache lifetime consultée le 2026-09-02
- Cache read price, on the API side consultée le 2026-09-02
- Batch API, discount and rate limits consultée le 2026-09-02
- Rate limits, separate quota for the Batch API consultée le 2026-09-02