Prompt Caching

Some models cache large, repeated prompt prefixes so that re-sending them costs less than fresh input. Primex meters cached tokens as their own buckets and prices them from the model's catalogue rates. It never infers a cache discount.

How it's metered

For token-priced models, the request ledger keeps four separate input/output buckets:

• input: total input tokens, including any reported cache-read/cache-write subsets.
• cache read: input tokens served from the provider's cache (a subset of input, billed at the cache-read rate, not added on top of input).
• cache write: input tokens written into the cache on this request, billed at their own rate and subtracted from input before pricing ordinary input.
• output: generated tokens.

A model only bills cache buckets if the provider reports them and the model publishes a rate for that bucket. If a cache bucket appears without a catalogue rate, Primex does not guess a discount; it falls back to the provider's whole-request cost or the uncharged meter-circuit path. See Billing & Credits.

Which models support caching and their exact per-bucket rates are on the model's catalogue entry; this page does not repeat volatile prices.

Getting cache hits

• Keep the cacheable prefix (system prompt, long context) stable and at the start of the request; vary only the tail.
• On models that accept it, send a stable prompt_cache_key for requests that share a prefix. Primex preserves it end to end to improve cache affinity.
• Caching is best-effort and provider-specific. Some providers report explicit cache writes; others expose only cache reads or require cache-control options. Identical follow-ups may report a cache read. Do not depend on a hit for correctness.