2026 support ticket costs: OpenAI vs Anthropic prompt caching below $0.02 - cache or skip

This guide compares 2026 support ticket costs for OpenAI versus Anthropic prompt caching below $0.02.

It gives the per-ticket cost formula and the reuse threshold that decides whether to cache or skip.

How prompt caching actually works

Prompt caching works by reusing a stable prefix, not by discounting an entire request. The eligible tokens must appear in the same order at the start of the prompt, and the provider applies the discount only to that prefix. For Anthropic, the stable context must sit at the start of the request behind an explicit cache breakpoint; only tokens before that breakpoint are discounted (amnic.com).

Anthropic's pricing has two parts: a cache write costs 25% more than standard input, listed as $3.75 per 1M tokens on Sonnet, while a cache read costs 90% less, listed as $0.30 per 1M tokens on Sonnet (apicalculators.com). The request that creates the cache pays the write price; later requests that hit the same prefix pay the read price. That asymmetry is why reuse count matters.

OpenAI uses automatic caching rather than an explicit breakpoint, with roughly a 50% discount on cached input tokens, compared with Anthropic's roughly 90% discount (aicosts.ai; betterclaw.io). In both cases, the variable part of the ticket—user text, tool results, or newly retrieved context—should come after the stable prefix so it is not treated as part of the cached block.

TTL behavior is the other gate: a cached prefix is only valuable if the same prefix is reused before it expires. Because TTLs and hit reporting differ by provider, treat the TTL as a measured window rather than a fixed assumption, and count only reuses that actually hit within it.

Operationally, keep stable instructions, examples, and policy text first; put ticket-specific content last; then check whether the provider reports a cache hit and whether the resulting per-ticket cached input cost clears your threshold. If the prefix is not reused at least twice within the TTL, skip caching and use batch or plain input.

The evidence: what the numbers say

The evidence converges across sources on the shape of prompt-caching discounts rather than on a single universal price: Anthropic is reported with the deepest cache-read discount plus a cache-write premium and a break-even at two requests using the same prefix; OpenAI is reported with a smaller automatic cached-input discount and no explicit breakpoint; Google is reported at a 75% cached-input discount with mechanics distinct from both (apicalculators.com; betterclaw.io; aicosts.ai; aipromptshub.co).

For Anthropic, apicalculators.com reports a cache-write premium above standard input, a much lower cache-read price, and break-even typically at two requests using the same prefix. That two-request floor is the practical convergence point for deciding whether a stable prefix is worth caching, because one write followed by only one read does not recover the premium.

For OpenAI, betterclaw.io and aicosts.ai describe cached input as automatic, with no explicit breakpoint required. The sources therefore frame OpenAI's benefit as easier to trigger but smaller in magnitude than Anthropic's reported cache-read discount, which matters when a support workflow has only intermittent prefix reuse.

For Google, aipromptshub.co reports a 75% cached-input discount and emphasizes that its mechanics are wildly different from both Anthropic and OpenAI. The convergence is on relative positioning, not on interchangeable implementation rules, so a provider switch should be treated as a new measurement rather than a simple discount swap.

Read as a set, the sources agree on an ordering—Anthropic deepest, Google middle, OpenAI automatic but smaller—and on two reuses as the practical break-even neighborhood. They do not agree on enough implementation detail to treat any provider's cache as a default for support tickets.

Anthropic vs OpenAI: which wins for tickets

The head-to-head winner for support-ticket workloads is conditional: Anthropic wins when a stable prefix is reused at least twice within the provider's TTL, while OpenAI wins for one-shot or low-reuse tickets.

For repeated-prefix tickets, Anthropic wins because its 90% cache-read discount dominates OpenAI's 50% once reuses reach two or more, according to costlens.dev. That advantage applies only after the reader rule is met: compute cached input cost per ticket as (prefix tokens × cache-write price) + (prefix tokens × cache-read price × (reuses − 1)), and cache only when that total is below $0.02 with at least two reuses inside the TTL.

For one-shot or low-reuse tickets, OpenAI wins because automatic caching avoids Anthropic's cache-write premium on prefixes that never get reused, as apicalculators.com notes. Paying a write premium for a prefix that earns no read discount is the wrong trade, so plain input or batch processing is the safer default.

The tie-breaker is prefix share: the larger the stable prefix is as a fraction of total input tokens, the more token volume the deeper cache-read discount applies to, which is what lets Anthropic's read price overcome its write-side premium. No source here publishes a specific prefix-share threshold, so measure your own prefix share and re-run the per-ticket formula from the decision rules section rather than assuming any cutoff.

Apply the checks in order: count reuses within the TTL, measure prefix share, then run the per-ticket formula. If reuses are below two or the computed cached input cost is not below $0.02, skip caching and use batch or plain input.

The practical reading is that provider choice follows workload shape: repeated prefixes favor Anthropic's deeper read discount, while unpredictable or single-use prefixes favor OpenAI's automatic path. Either way, the $0.02 per-ticket ceiling and the two-reuse minimum remain the gating checks.

Costs and numbers that matter

The only figures this section adds are the per-million-token price points used to test the $0.02 cached-input rule; everything else about mechanism, evidence, provider choice, limits, or ticket volume belongs to other sections.

For Anthropic, apicalculators.com lists Sonnet standard input at $3.00 per 1M tokens, cache write at $3.75 per 1M tokens, and cache read at $0.30 per 1M tokens. Those three values are the fixed dollar inputs for the Anthropic side of the formula.

For OpenAI, betterclaw.io describes cached input as roughly 50% off standard input and applied automatically, so the usable price point is the discount rather than a single dollar rate. For Google, aipromptshub.co gives cached input as 75% off, which is useful as a third reference point rather than a recommendation.

To use these points in the reader rule, convert the per-1M rates to per-token rates before multiplying by prefix tokens: for Anthropic, that is $3.75 divided by 1,000,000 for the write and $0.30 divided by 1,000,000 for each read. For OpenAI and Google, apply the stated discount to the provider's current standard input price before running the same test.

These are volatile 2026 price points, so verify the current rate sheet before using them in a budget or ticket-cost estimate.

What the evidence does NOT establish

This section alone states the limits, variance, and unverified claims about caching. To begin, no source in the available sources gives a per-ticket dollar figure for support tickets specifically. The $0.02 threshold used for the reader rule is a method-derived ceiling, not a published number. Because of that, you cannot look up a ticket average to justify caching. Instead, you must compute cached input cost per ticket from your own prefix tokens and the exact prices you are billed for each provider.

Another gap is time-based validity. TTL values for Anthropic and OpenAI caches are not stated in the available sources. Since the reader rule requires reuses ≥ 2 within TTL, the count of reuses is only meaningful if the prefix is still valid at the moment of each request. For that reason, you must verify current TTL in each vendor's prompt caching docs before relying on any reuse count. Without that check, a prefix that appears stable across a test run may no longer be eligible by the time it is sent again.

Even if time is known, frequency is unproven. Cache-hit rates in production are not published by any source here. While betterclaw.io points to the possibility of 80%+ identical context for AI agents, that figure is not shown for support tickets. Treat it as a hypothesis to test, not an expectation. Measure your own prefix stability over a real sample of support tickets before assuming any level of reuse, as variance between ticket types can change that result entirely.

With all of these unknowns, the decision must stay strictly conditional. Use the formula (prefix tokens × cache-write price) + (prefix tokens × cache-read price × (reuses − 1)) to get cached input cost per ticket, but only cache if that total is < $0.02 and reuses ≥ 2 within TTL. If either condition cannot be verified from current vendor docs or from your own measurements, skip caching and use batch or plain input. These are checks to enforce, not guarantees to expect.

10k tickets/day

For a setup of 10,000 tickets/day with a 2,000-token stable prefix and a 500-token variable tail, 3 reuses per prefix within TTL, this section alone states the arithmetic translating discount rates into per-ticket and daily cost. Using the reader rule, cached input cost per ticket is (prefix tokens × cache-write price) + (prefix tokens × cache-read price × (reuses − 1)). For Anthropic, with write at 2,000 × $3.75/1M = $0.0075 and reads at 2,000 × $0.30/1M × 2 = $0.0012, the total cached input is $0.0087 per prefix, which comes to $0.0029 per ticket. At 10,000 tickets/day that is $29.00 per day for the cached prefix portion across those tickets, before the 500-token variable tail is added at its applicable rate.

For OpenAI, the sources give only the discount shape — roughly 50% off cached input, applied automatically — not a standard input dollar rate; the $3.00/1M figure above is Anthropic Sonnet's standard input, not OpenAI's. To run the same test, apply the 50% discount to OpenAI's current standard input rate from its rate sheet, then compute 2,000 tokens × that discounted rate × 3 reuses, divide by 3 for the per-ticket figure, and multiply by 10,000 for the daily cost.

Both figures sit below the $0.02 per ticket threshold with reuses ≥ 2, but at this exact reuse count the difference is only about $0.0001 per ticket ($0.0029 vs $0.003), a fraction of a cent — small enough that a change in prefix size or reuse count could flip the verdict.

The point is not which is cheaper by a wide margin for these numbers, but that the split between write and repeated reads is what must be divided by reuses to get a per-ticket cost, and multiplied by 10,000 to get a daily cost.

The check is strictly arithmetic: if you skip dividing by the number of reuses, a $0.0087 prefix charge looks larger than $0.02 per ticket when misapplied, but correctly attributed it is $0.0029. If reuses fall to 1 within TTL, the (reuses − 1) term becomes zero and you must pay the write with no reads to offset it, so the cost per ticket would jump to the full prefix write charge with no spread across other tickets. If that full write charge per ticket would bring cached input above $0.02, or reuses < 2 within TTL, the rule is to skip caching and use batch or plain input instead. These are the numbers to plug into that formula for this 10,000 tickets/day case, with no rounding of the per-ticket decimals shown above.

Decision rules: cache or skip

For 2026 support tickets, the decision to enable prompt caching must be made by a pass/fail check, not by assumption. First, count reuses: if the same stable prefix sees fewer than two reuses within the provider's TTL, skip caching outright. The cache write carries a premium over standard input, and with only one use there is no opportunity to recover that write premium. Track observed reuses for that exact prefix against its observed TTL, not projected volume across your entire account.

Second, compute the ticket-level cached input cost before enabling it. Use the formula (prefix tokens × cache-write price) + (prefix tokens × cache-read price × (reuses − 1)) and only cache if that total is < $0.02 per ticket. If it is ≥ $0.02 per ticket, skip caching and route those tickets to batch or plain input. When pulling the cache-write and cache-read prices, use the exact billed rates for the specific provider and model on your invoice, as apicalculators.com notes the ratios differ by provider. Recompute this for each prefix, since a small change in prefix size or reuses can cross the $0.02 cutoff.

Third, treat prompt structure as a prerequisite for the providers where placement matters. For Anthropic, if the stable prefix is not at the start behind a breakpoint, fix prompt structure before enabling caching. As pointed out by Amnic, Anthropic only discounts cached tokens under that placement condition, so a hit cannot be forced by billing settings alone. Verify the position of every eligible token in that prefix against a breakpoint instead of assuming the template is correct.

Run these three gates in this order: reuse count within TTL, cached input cost per ticket against $0.02, and prefix placement at the start behind a breakpoint for Anthropic. If any one of them fails, skip caching and use batch or plain input. Apply the checks per prefix and per ticket template, because clearing the bar for one template does not obligate you to cache another.

What to do next

Frequently Asked Questions

Does prompt caching discount an entire request?

Prompt caching works by reusing a stable prefix, not by discounting an entire request.

What order requirement applies to eligible cached tokens?

The eligible tokens must appear in the same order at the start of the prompt, and the provider applies the discount only to that prefix.

Where must Anthropic's stable context be located?

For Anthropic, the stable context must sit at the start of the request behind an explicit cache breakpoint; only tokens before that breakpoint are discounted.

Which request pays Anthropic's cache write price?

The request that creates the cache pays the write price; later requests that hit the same prefix pay the read price.

How does OpenAI's caching differ from Anthropic's?

OpenAI uses automatic caching rather than an explicit breakpoint, with roughly a 50% discount on cached input tokens, compared with Anthropic's roughly 90% discount.

Where should variable ticket content be placed?

In both cases, the variable part of the ticket—user text, tool results, or newly retrieved context—should come after the stable prefix so it is not treated as part of the cached block.

Quick answers