June 2, 2026 LLMs prompt caching DeepSeek review analytics

Reducing LLM Costs with Prompt Caching

How moving one changing field reduced the observed cost of a DeepSeek labeling job by about 26%.

A batch identifier looks like harmless bookkeeping. In our review-labeling test, placing it before the repeated instructions prevented that block from being cached. Moving it after the static content reduced the observed cost by about 26%.

Each request asked DeepSeek to label ten German customer reviews using the same instructions and list of 23 topics. Most of that setup stayed unchanged between requests. The new reviews, and a batch identifier where included, were the changing parts.

The experiment showed why prompt optimization needs to account for more than length. Reordering a field could make repeated text cheaper to process. Compressing a topic list could send fewer tokens yet increase the bill if cache reuse disappeared.

Scroll through one prompt, request by request, to see what the cache can reuse.

Prompt structure

Request 1

Input served from cache0%
Cost per 1M reviews$34.83−26%

The first request writes the cache. Every request sends the same instructions, the 23-topic list, and the response format, plus ten new reviews and a batch identifier.

The identifier changes first. The cache only reuses an identical beginning. With the identifier on top, the very first line differs, so nothing after it can be reused.

Move one block. Same content, same length. Only the identifier moves below the repeated rules.

Now the beginning repeats. Instructions, topic list, and format match the previous request and come from cache, about 48% of all input tokens in our test.

Stable content first, changing content last. Moving one line cut the observed cost from $34.83 to $25.84 per million reviews.

Try it yourself

Prompt structure

Input served from cache0%
Cost per 1M reviews$34.83

Observed in two runs of 200 reviews (20 batches of ten), scaled to one million reviews at the May 2026 prices. Block heights are schematic; the snippets are abridged, and the example reviews are written for illustration.

One changing line, a higher bill

We tested four layouts on the same 200 reviews, in 20 batches of ten, with reasoning disabled. The model and topic definitions stayed fixed. We changed the placement of the batch identifier or the ordering of the topic list.

The clearest comparison was between these two layouts:

Changing field first

Batch identifier: 001
Instructions
Topic list
Response format
Ten new reviews

The identifier changes on the next request, before the repeated instructions begin.

→

Repeated content first

Instructions
Topic list
Response format
Batch identifier: 001
Ten new reviews

The identifier changes after the reusable block. Its position leaves that beginning intact.

With the identifier first, the API reported no cache hits. Moving it after the static block allowed about 48% of all input tokens to be served from cache. The cost calculated from observed usage fell from $34.83 to $25.84 per million reviews, a reduction of about 26%.

These figures are scaled from the 200-review runs using the prices recorded in May 2026. They are a way to compare the tested layouts, not the cost of a measured million-review run or a quote at current prices.

Prompt layouts produced costs of about $26 or $35 per million reviews Bars show costs calculated from observed usage. Ticks show what each run would cost with the same input and output tokens but no cache discount. Scaled from 200-review runs at the recorded May 2026 prices.

Source: deepseek_cache_cost_by_run.csv, production validation rows.

Layout Input tokens served from cache Cost / 1M reviews
Static content first, no batch identifier 48.8% $26.17
Batch identifier after static content 48.2% $25.84
Batch identifier before static content 0.0% $34.83
Topic list shuffled between requests 0.9% $35.29

The shuffled list contained the same 23 topic definitions, but in a different order on each request. It produced just one 256-token cache hit across all 20 batches. Keeping the meaning unchanged was insufficient; the sequence of repeated content mattered too.

Output lengths varied slightly between runs, so the difference between their total bills is not a perfectly isolated measure of the cache discount. The chart’s ticks provide that separate comparison: they hold each run’s input and output token counts fixed and price all input as uncached. For the layout with metadata after the static block, that calculation is $35.32 without caching versus $25.84 with the recorded cache hits.

What the cache reuses

The prefix is the beginning of a request. When successive requests start with the same content, prefix caching can reuse processing associated with that shared beginning. A changing field placed early can interrupt the match before the instructions or topic list are reached.

For this labeling task, the request can be understood as two blocks:

UNCHANGED BETWEEN REQUESTS
  System instructions
  Labeling rules
  Fixed topic list, in a fixed order
  Required response format

CHANGING BETWEEN REQUESTS
  Batch identifier, if needed
  Ten new customer reviews

The cache does not supply a saved answer for the new reviews. The model still generates their labels, and output tokens are billed separately. The API reports reused input as prompt_cache_hit_tokens and the remaining input as prompt_cache_miss_tokens.

At the prices saved for this experiment, a million cached input tokens cost $0.0028, compared with $0.14 for uncached input: a 50-fold difference. That explains how a moderately longer request could be cheaper if enough of it was reused. The complete rates and cost calculation are retained in the methods note below; the provider’s pricing page lists current rates.

What happened during warm-up

In the static-first run, the first two requests received no cache hits. Every request from batch 3 onward reported exactly 768 cached input tokens. The remaining input varied because each batch contained different reviews.

In this run, reuse began on the third request Cache-friendly production layout, one bar per request of 10 reviews. The first two calls miss; from batch 3 onward exactly 768 input tokens are served from cache.

Source: production_good/batch_api_usage.csv, deepseek-v4-flash, 2026-05-31.

This is the warm-up pattern we observed, not a promise that caching always starts on the third request. Cache availability is best-effort provider behavior; the DeepSeek caching guide describes the feature.

Two measurements help separate cost from behavior. The overall cached share includes every request, including warm-up, and is the percentage used in the opening table. The steady-state measurements exclude the first three requests so we can inspect reuse after warm-up. In this run, 48.8% of all input was cached; after excluding those requests, the share was 53.3%. These are shares of input tokens, not percentages of requests that received a hit.

Why a shorter prompt can cost more

An earlier experiment exposed the problem while we were trying to shorten the prompt. One version kept complete topic and category names. A second shortened JSON field names (for example, topic_id became t) while retaining the descriptive values. A third removed repeated category names and used short topic codes that Python mapped back to the full hierarchy afterward.

The difference is illustrated by a topic such as staff friendliness. Shortening a field name leaves “Service” and “Staff friendliness” in the prompt. The more aggressive version keeps the topic description but replaces its place in the hierarchy with a code. Both reduce text, but they change different parts of the repeated setup.

This was a separate 1,000-review experiment with reasoning enabled, using batches of ten. Its total costs include reasoning and are therefore much higher than the opening comparison. Compare the variants within this table.

Prompt version Input tokens across 1,000 reviews Cached share Input cost / 1M reviews Total cost / 1M reviews
Original field names and full topic values 188,265 96.5% $1.44 $104.19
Shorter field names, full topic values 168,565 96.2% $1.35 $97.64
Coded taxonomy 141,565 0.0% $19.82 $113.03

The coded version sent 24.8% fewer input tokens than the original, but none received the discounted cache-hit price. Its input cost rose from $1.44 to $19.82 per million reviews, about 13.8 times higher. Its total cost rose by a much smaller 8.5%, because output and reasoning accounted for most of the bill.

Shorter field names worked better in this comparison: they reduced tokens while retaining cache reuse. That is an observed result for these prompts, rather than a guarantee that one representation will always be cheaper.

The experiment changed several aspects of the request, including its length, representation, and, in additional variants, schema placement. It revealed the tradeoff but did not isolate why a particular version stopped receiving hits. The two diagnostic experiments below were designed to examine that behavior more directly.

Additional prompt variants

Two further versions added a short guide mapping category codes to names and descriptions. One also moved the response schema before the changing reviews, making it part of the reusable beginning.

Variant Input tokens across 1,000 reviews Cached share Input cost / 1M reviews Total cost / 1M reviews
Coded taxonomy plus category guide 203,665 0.0% $28.51 $126.30
Same guide, response schema before reviews 203,665 22.6% $22.19 $125.25

Moving the schema restored some cache reuse, but neither variant had the lowest total cost in this experiment.

What determines how much input gets reused?

The production layouts showed the cost difference. Two smaller diagnostic tests examined the amount of unchanged content and the position of the first changing field. Each configuration used 20 batches of ten reviews with reasoning disabled; the charts report median cached tokens after excluding the first three batches.

How much unchanged content comes first?

The first test began with a minimal one-topic prompt and added increasing amounts of identical filler text before the reviews. This artificial setup made it possible to explore short prefixes; the full production prompt was already long enough to receive hits.

Without padding, the prompt received no hits in 20 requests. The first padded setting, targeting 128 added tokens, received 256 cached tokens on every one of the 17 steady-state requests. The total reusable beginning included the instructions as well as the added padding, which is why those two numbers differ.

More unchanged content made more input available for reuse A minimal prompt received increasing amounts of identical filler text. The horizontal axis counts added padding, not the complete prompt prefix. Dots show tested settings; the line connects them.

Source: cache_threshold_summary.csv. Cached tokens are medians over batches 4–20.

All the padded settings received hits on every steady-state request. As padding increased, the amount reused generally increased too. The higher cached share did not mean hits were becoming more reliable; more of each request was simply unchanged text.

This experiment does not establish that adding filler saves money. It measured reuse, and extra padding still has a cost. For an actual labeling job, the useful action is to preserve the instructions and reference material already needed, then measure the bill.

Where does the first changing field appear?

The second test kept a large prompt fixed and inserted a line containing the changing batch number at different positions. If that line appeared within the first 192 words, the API reported no cache hits. Placing it later preserved more reuse: at the tested positions of 256, 1,024, and 2,048 words, the median reported hits were 256, 1,024, and 2,048 tokens respectively. Without the inserted field, the median was 3,328 tokens.

Moving the changing line later preserved more cached input The same changing batch identifier was inserted at different positions in a fixed prompt. The dashed line shows the result without that inserted field.

Source: cache_breaker_position_summary.csv; first 3 batches excluded from steady metrics.

Here the insertion positions are measured in words, while the API reports reuse in tokens. The numerical matches at those settings are specific to the test text; words and tokens are not interchangeable units. The practical result is that moving the changing field later left more of the beginning available for reuse. Identical text after that field did not restore the lost benefit.

Across both scans, the smallest nonzero reported hit was 256 tokens and every nonzero hit count was a multiple of 128. Those observations are consistent with reuse in discrete units, but they do not establish a universal 256-token minimum or uniquely identify a 128-token cache implementation. They describe this model and workload on the experiment date.

A prompt layout to use and verify

For this workload, a useful starting layout is:

Fixed instructions → fixed topic list → fixed response format → changing metadata → new reviews.

The batch-identifier example shows why the boundary matters. A field can be useful for tracking requests without occupying the first line. Likewise, a topic list can retain its meaning while changing its order, but that change may prevent reuse.

When building or revising a labeling prompt:

  1. Keep repeated content consistent. Use the same topic order, section names, and formatting between requests.
  2. Place changing fields after the reusable block. Check batch identifiers, timestamps, and other per-request metadata as well as the review text.
  3. Measure after a change. Inspect cache-hit and cache-miss tokens, output tokens, and total cost; a shorter prompt or a higher cached percentage alone does not establish a saving.
  4. Check representative requests after warm-up. Inspect several batches to understand reuse, while including the initial requests in the total bill.

These tests measured cache behavior and cost, not labeling quality or latency. A prompt change still needs to produce useful labels. The result worth carrying into another workload is the testable layout principle: keep the necessary repeated content together at the beginning, then verify what the provider actually reuses.

Methods, historical pricing, and sources

Scope. The controlled experiments used deepseek-v4-flash on May 31, 2026, with reasoning disabled and 200 reviews per configuration. Production validation used the fixed 23-topic taxonomy; the padding test used a minimal one-topic prompt. The earlier format comparison used 1,000 reviews per variant with reasoning enabled. All used ten reviews per batch. A run-specific identifier in the system message was held constant within each controlled run and changed between runs to separate their cache prefixes.

Historical rates. The saved cost rollup used the following prices, recorded on May 31, 2026. These are experiment inputs, not current pricing. Model versions, rates, and caching behavior can change.

Token class USD per million tokens
Cached input $0.0028
Uncached input $0.14
Output $0.28

Calculation. Costs use provider-returned input cache-hit, input cache-miss, and completion-token counts. Scaling to a million reviews divides the run cost by its review count and multiplies by one million.

run_cost = (
    cached_input_tokens × 0.0028
  + uncached_input_tokens × 0.14
  + output_tokens × 0.28
) / 1,000,000

uncached_comparison = (
    all_input_tokens × 0.14
  + output_tokens × 0.28
) / 1,000,000

The uncached comparison holds the run’s input and output counts fixed. It changes only the price applied to cached input. The measured output includes reasoning tokens where reasoning was enabled.

Sources. Charts and tables draw on the experiment summaries and per-batch API usage logs: cache_threshold_summary.csv, cache_breaker_position_summary.csv, production_cache_validation_summary.csv, deepseek_cache_cost_by_run.csv, pricing_used.json, and the earlier prompt-format comparison. Full experiment files are available on request. The article does not establish caching behavior across providers or guarantee that another workload will reproduce these costs or hit counts.