GPT-6.1 Terra Caching: Five Cents a Read, and When the Write Pays

GPT-6.1 Terra's cached input rate is $0.05 per million tokens — 95% below the $1.00 standard input rate, and the largest single discount on the whole card. The catch is on the other side of the ledger: writing to the cache costs $1.25 per million for 30-minute retention or $2.50 per million for 12 hours. A workload that reads the same prefix twice comes out ahead. A workload that rebuilds its prefix on every call pays the write fee and never collects the discount, and the rate card will not tell you which one you are running.

This piece does the arithmetic: the exact break-even, three worked workloads at different scales, the interaction with the 272K long-context cliff, and the prompt-engineering habits that quietly destroy caches.

The four numbers

• Standard input — $1.00 per million tokens.

• Cached input — $0.05 per million, a 95% discount.

• Cache write, 30-minute retention — $1.25 per million.

• Cache write, 12-hour retention — $2.50 per million.

Above 272,000 input tokens everything doubles: $2.00 input, $0.10 cached, $2.50 cache write. So the long-context cliff does not only raise the input rate — it raises the price of both caching and writing at the same time.

For comparison, GPT-6.1 Sol's cached input is $0.10 and GPT-5.6 Terra's is $0.20. Terra's five-cent read is the cheapest in the family, and the 95% discount is what makes repeated long-context calls economically possible at all.

The exact break-even

Assume a prefix of P tokens reused across N calls, and ignore output for a moment.

• Without caching: N × P × $1.00.

• With caching: one write at $1.25 × P, then N reads at $0.05 × P.

Setting them equal: 0.95N = 1.25, so N ≈ 1.32. In practice that means the second call is already profitable: the write costs 1.25 per million and each read saves 0.95, so two reads recover more than the write. With 12-hour retention the write is $2.50 and the break-even is 2.63 reads — the third call pays for it.

That is a lower bar than most teams assume. The common myth is that caching only pays for very high reuse; on this card it pays from the second request, provided the prefix actually matches.

Three workloads

A 50,000-token system prompt across 10,000 short requests. Uncached: 10,000 × 50,000 × $1.00 per million = $500 just for the prefix. Cached: one write of 50,000 × $1.25 per million = $0.0625, plus 10,000 reads at 50,000 × $0.05 per million = $25. Total $25.06 — a 95% saving on the prefix, and the cache write is a rounding error.

A 900,000-token repository across 20 questions. Uncached, every request trips the long-context rate: 900,000 × $2.00 per million = $1.80 per call, $36 for twenty. Cached: one write of 900,000 × $2.50 per million = $2.25, then twenty reads at 900,000 × $0.10 per million = $0.09 each, $1.80 total. Total $4.05 — an 89% saving, and the eighteen-dollar difference is the entire margin on some products.

A 20,000-token document across three questions, each with a different persona and instructions. This is the case where caching fails: if the prefix changes between calls — different system prompt, different instruction order, a user ID interpolated at the top — the model sees three different prefixes and writes three caches. Uncached and "cached" cost the same, except you paid for writes. The fix is structural: put everything variable at the end of the prompt, and keep the document and the stable instructions at the front.

What breaks a cache/p> p>OpenAI's prompt caching works on the unchanged prefix of a request. Anything that changes early in the prompt invalidates everything after it. The usual culprits:/p> p>• A timestamp or request ID in the system prompt. It is the most common cause of a 0% cache hit rate./p> p>• Per-user personalisation inserted at the top instead of the bottom./p> p>• Reordered tool definitions or a tool list that changes between calls./p> p>• A retrieval step that concatenates documents in a different order each time./p> p>• Whitespace changes from templating engines — reformatting a JSON block is enough./p> p>• Switching between Chat Completions and Responses mid-pipeline, which changes the serialised prefix./p> p>The diagnostic is simple: log the first 2,000 tokens of each request and hash them. If the hash changes between calls that should be identical, the cache is dead and no amount of tuning will revive it./p> h2>Cache and the 272K cliff

The two interact in a way that is easy to miss. A 250,000-token cached prefix costs $0.05 per million to read and $1.25 to write. Grow it to 300,000 tokens and every number doubles: $0.10 read, $2.50 write, and the uncached portion is billed at $2.00. A pipeline that crosses the threshold pays the cliff on both the cached and uncached sides.

This creates a design incentive that is not obvious: if a workload sits just above 272K, shrinking the prefix to 270K can halve the bill without changing the task. Trimming a boilerplate section, dropping an unnecessary retrieval block or moving an example out of the system prompt is worth more at the boundary than it is anywhere else on the card.

Caching versus the alternatives

• Caching — best when the same long prefix is reused many times within the retention window, and the prefix is genuinely stable.

• Chunking — best when the document is large but each question touches a small part; retrieval is cheaper than sending 900K tokens even at the cached rate.

• Batch/Flex — 50% off standard, but batch latency is measured in hours; it stacks with caching, not with real-time products.

• A cheaper model — GPT-6 Luna at $0.10/$0.50 can beat Terra's cached rate for simple tasks, because Luna's uncached input is only twice Terra's cached input.

The last comparison is the one teams forget. Caching is a discount on Terra, not a guarantee that Terra is the cheapest way to answer a question. For classification over a 50,000-token prompt, Luna cached at $0.01 per million read is still the cheaper arm if the task is simple enough.

What you can run today

GPT-6.1 Terra is not on the OrcaRouter catalogue at the time of writing, so its cache behaviour has to be measured against OpenAI directly. The models that are live — GPT-6.1 Sol at $2/$10 with a $0.10 cached rate, GPT-5.6 Terra at $2/$12 with $0.20, GPT-6 Luna at $0.10/$0.50 — can all be exercised on one key at 0% markup over provider list price.

The measurement to build is not "does caching work" — it does — but "what fraction of my traffic has a stable prefix". That fraction is the only number that decides whether Terra's five-cent read matters to your bill, and it is a property of your prompts, not of the model.