← Retour aux guides

Prompt Caching Explained: Cut AI API Costs

Prompt caching lets an AI provider reuse a portion of a previous request instead of processing the same tokens from scratch every time. It is especially useful when your application sends a large, stable instruction set, documentation bundle, tool definition, or conversation prefix with many requests.

When configured correctly, caching can reduce input-token costs and improve response latency. It does not cache the model's answer automatically. Instead, it caches matching prompt content so the model can process repeated input more efficiently.

How prompt caching works

A typical request contains a stable prefix and changing content. The stable prefix might include your system instructions, product documentation, or tool schemas. The changing section could be a user's latest question.

The provider creates a cache entry for the reusable prefix. On a later request, it compares the new prompt with the cached content. If the prefix matches the required conditions and the cache has not expired, the provider reads the cached tokens rather than charging or processing them as new input tokens. The new user message is then appended and evaluated normally.

Cache matching is usually sensitive to order and exact content. Changing whitespace, instructions, tool definitions, or the position of a message can prevent a cache hit. Most caches also have a limited time-to-live, so an entry may disappear after a period of inactivity.

Step 1: Find the repeatable part of your prompt

Review several real requests from your application and separate fixed content from variable content. Good candidates include:

• A system prompt that remains unchanged across a session.
• Large policy documents, manuals, or product catalogs.
• Repeated tool definitions and JSON schemas.
• A long conversation prefix that receives many follow-up questions.

Do not cache short prompts simply because caching exists. The setup overhead, minimum token requirements, or provider-specific rules may make caching ineffective for very small inputs.

Step 2: Put stable content before changing content

Organize each request with the most reusable material first and the user's current question last. Keep the stable section byte-for-byte consistent when possible. If your application adds timestamps, random IDs, or changing instructions near the beginning, move those values into the final dynamic section.

This layout is useful even when you are not using explicit caching because it creates a predictable prompt structure and makes cache behavior easier to measure.

Step 3: Use the model provider's caching method

Claude APIs commonly support explicit cache breakpoints, allowing you to mark content that should be written to a cache. The exact field names, supported models, minimum sizes, and time-to-live options depend on the API version. OpenAI models with prompt caching generally detect eligible repeated prefixes automatically, although eligibility and pricing vary by model.

Do not assume that a generic OpenAI-compatible endpoint exposes every vendor-specific caching feature. Check the documentation for the model and relay you are using, then confirm whether explicit cache-control fields are passed through or whether caching is automatic.

Step 4: Route requests and verify cache hits

With 59API, you can use the API base URL https://api.59api.com and connect through Claude Code, Codex, or an OpenAI SDK. Select the Claude Opus, Sonnet, Haiku, Fable, or GPT model that fits your workload. Because caching behavior is model- and endpoint-dependent, test the exact model and request format you plan to use.

Send the same large prefix in two or more requests, changing only the final user message. Then inspect the usage information returned by the API or provider. Look for cached-input, cache-read, or cache-creation token fields. A successful cache read should appear on later requests, while the first request may show cache creation or normal input processing.

Step 5: Calculate the real savings

Compare uncached and cached requests using the same prompt length, model, and output size. Include cache-write charges, cache-read charges, expiration, and the number of requests that reuse the prefix. Caching is most valuable when the stable prefix is large and reused frequently. It may provide little benefit when every request changes substantially or sessions are too short.

59API is a practical low-cost option for running this comparison because it offers pay-as-you-go access to native official-quality Claude and GPT models without a model downgrade. You can test a caching-heavy workflow without committing to a large subscription, and its referral rebate can make ongoing usage even more economical. Sign up for 59API, configure your SDK with its base URL, and measure cache hits before moving the workflow into production.

Common mistakes to avoid

• Assuming a cached prompt also caches the model's response.
• Changing the supposedly stable prefix between requests.
• Ignoring provider-specific minimum token or expiration rules.
• Measuring only latency without checking token usage and billing.
• Sending sensitive information into a cache without reviewing retention and privacy policies.

Tarifs · Docs