Prompt Caching Across Backends Under the 1.3x Rule: Where Cache Hits Show Up in Your USDC Deduction

Prompt caching is one of the few optimizations that lowers cost without touching output quality. When you call many backends through a single aggregator key, the picture gets more complicated: each backend implements caching differently, and the aggregator bills you on metered usage. This guide explains conceptually where cache hits appear in your USDC deduction and how to structure prompts so more of your input is billed at cached rates.

The mental model: two layers of accounting

Your deduction passes through two layers:

• The backend layer. Each model provider meters your request and decides which input tokens count as cache reads, cache writes, or uncached input. Rules differ: some cache on a prefix you define explicitly, some cache automatically with a short time-to-live, some require a minimum prefix length before caching applies at all.
• The aggregator layer. We bill at the official price for the measured usage multiplied by 1.3. This multiplier is applied uniformly to whatever the backend meters, including cached and uncached token lines separately. We do not flatten everything into one blended rate.

Because the multiplier is uniform, caching changes your deduction only through the backend's own per-token pricing. A cache read that the backend prices lower stays proportionally lower after the 1.3 multiplier.

Where you actually see the cache hit

You can identify cache activity in your deduction statement in three ways:

• Input token line items. Where a backend reports separate cached and uncached input buckets, your statement shows them as distinct quantities, each multiplied by the official rate and then by 1.3.
• Cache write tokens. Some backends charge a premium for the first request that populates the cache. That one-time write cost also carries the 1.3 multiplier. If your prompts are one-shot, cache writes can cost more than they save.
• A lower effective input rate. Even without line-item detail, a session that consistently hits cache shows a visibly lower average input cost per call. This is the easiest signal to watch when comparing prompt layouts.

It is the backend's cache pricing that determines the shape of the saving. We are a pass-through with a multiplier, not a re-pricer, so caching gains you see on a backend's own dashboard are the same gains, scaled by 1.3, on your statement.

What makes a prefix cache hit

Across most backends, prefix caching works on the bytes at the start of your request. Some principles hold broadly:

• Stable prefix, volatile suffix. Keep the long, reused material (system instructions, reference documents, style guides, tool schemas, few-shot examples) at the very beginning and unchanged. Put the user-specific or per-turn content last.
• Byte-identical prefixes. A single changed character, extra whitespace, or a reordered JSON field breaks the match. Even the same information in a different key order can count as a different prefix.
• Minimum threshold. Several backends only cache when the prefix exceeds a minimum length. Short prompts may never populate a cache, so caching is a long-context optimization in practice.
• Time-to-live. Backends expire caches after an interval. If your requests are spaced far apart, you may keep paying cache writes or never see reads. Bursty or conversational traffic fits caching better than sparse batch jobs.

How to structure prompts for a higher hit rate

• Move all reusable context to the front. System prompt, tool definitions, schema docs, and long reference material belong in a fixed block, not interleaved with the question.
• Serialize deterministically. When embedding structured data, use a fixed key order and stable formatting so the prefix is byte-identical across requests. Avoid timestamps, request IDs, or other varying content inside the cached block.
• Split dynamic content out. Put user input, retrieved snippets unique to the turn, and volatile metadata after the stable prefix.
• Reuse within the cache window. When several requests share the same context (a multi-turn session, a batch over one document), send them close together so the cache is warm rather than rebuilt each time.
• Keep one prefix per workload. Mixing many different system prompts shortens the useful life of each cache. If you serve multiple tasks, keep each task's prefix internally consistent.
• Measure, don't assume. Check per-backend usage details where available and watch the average input cost on your statement. A prefix that never hits cache is just an expensive prefix.

Backend differences to expect

Since each backend implements caching with its own rules, the same prompt can hit the cache on one model and miss on another:

• Some require you to explicitly declare a cache breakpoint; others cache automatically once a threshold is met.
• Some use a short, rolling time-to-live; others allow longer retention.
• Some price cache writes and reads very differently from each other.

If you are routing one workload across several models, expect the share of cached tokens to vary per backend. Long, static context typically benefits most; short, varied prompts typically benefit least.

Putting the 1.3x rule in context

The multiplier does not change your caching strategy — it just scales the result. A cache that reduces the backend's metered input cost also reduces your deduction by the same proportion, times 1.3. So the question is always: does this backend's cache pricing, applied to my prompt layout, produce fewer metered tokens than sending the same context uncached? When the answer is yes, the saving flows through to your USDC balance.