← Back to all guides

When Cache Reads Cut AI Prompt Costs

Use Cache Reads When the Beginning of the Prompt Repeats

Cache reads are most valuable when many requests share a large, stable prompt prefix. Typical examples include a long system instruction, product documentation, coding standards, API schemas, policy manuals, or a repository summary that is sent repeatedly during an agent session. Instead of paying the full input-token rate for that same prefix on every request, a cache-aware model can reuse the previously processed content and bill the reused portion as a cache read.

The important distinction is that caching helps repeated input, not repeated output. If every request contains a different 200-token question and a different 2,000-token context, there is little to reuse. If every request contains the same 12,000-token handbook plus a different question, cache reads can materially reduce prompt cost and may also improve request latency.

A Practical Support Assistant Example

Imagine a support assistant that answers questions using a 20,000-token operations guide. The guide changes weekly, while customers ask hundreds of unique questions each day. Put the stable guide at the start of the request and mark it as cacheable. Keep the changing customer question after the cached block.

Claude-compatible request example:

curl https://api.59api.com/v1/messages -H "x-api-key: $API_KEY" -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d '{"model":"claude-sonnet-4-5","max_tokens":700,"system":[{"type":"text","text":"You are a precise support agent. Answer only from the operations guide."},{"type":"text","text":"OPERATIONS_GUIDE_CONTENT_HERE","cache_control":{"type":"ephemeral"}}],"messages":[{"role":"user","content":"Can I change a shipment address after dispatch?"}]}'

The guide is the cache candidate because it is large and unchanged across requests. The user message must remain outside that block because it varies. On a later request, send the exact same cacheable content in the same position, then replace only the final customer question.

Preserve Cache Hits Deliberately

• Place stable instructions and reference material first, followed by variable request-specific content.
• Keep cached text byte-for-byte consistent when possible. Small edits, reordered sections, timestamps, random request IDs, and changing dates can prevent reuse.
• Use a versioned document identifier in your application, such as handbook-v7, and invalidate or replace the cached block only when the source changes.
• Group similar work together. A batch of requests using one policy pack is more cache-friendly than alternating among many unrelated packs.
• Measure cache-read tokens separately from normal input tokens in provider usage data before assuming a saving.

When Cache Reads Are Not the Right Tool

Do not add caching automatically to every call. A short prompt may not be large enough for the savings to matter. One-off research requests, heavily personalized context, and prompts assembled from frequently changing search results often produce weak cache reuse. In those cases, reduce prompt size first: retrieve only relevant passages, summarize older conversation turns, and remove duplicate instructions.

Also avoid caching information that should not persist within the provider's configured cache behavior. Review your model provider's cache retention, privacy terms, and account settings before sending regulated or highly sensitive material. Cache reuse is a cost and performance technique, not a substitute for data classification.

Use Cache Reads in an Agent Workflow

Developer agents are a strong fit because they repeatedly need the same repository conventions, architecture notes, tool instructions, and build commands. For example, cache a project briefing at the beginning of a coding session, then append each new task, compiler error, or file diff. This keeps the high-value context available without repeatedly paying the normal input rate for every turn.

59API is a practical option for this workflow because it provides pay-as-you-go access to native official-quality Claude models, including Opus, Sonnet, Haiku, and Fable, alongside GPT models through https://api.59api.com. Its compatibility with Claude Code, Codex, and OpenAI SDK-based applications means an existing client often needs only a base URL and API-key configuration change. Combined with competitive relay pricing, prompt caching can reduce the cost of context-heavy workloads without downgrading the model used for the job.

OpenAI SDK configuration example:

from openai import OpenAI

client = OpenAI(base_url="https://api.59api.com/v1", api_key=os.environ["API_KEY"])

Start with one repeat-heavy endpoint, log normal input versus cache-read usage for a week, and compare the cost per completed task. Developers who want a low-cost relay for that experiment can sign up for 59API and apply the same cache-friendly prompt structure to their existing tools.

Pricing · Docs