01What is OpenRouter response caching and how it works

OpenRouter response caching is a new feature that stores the full response from an AI model and returns it instantly for identical requests. It was released on April 30 and changes how you use AI tools. Instead of hitting the model every time, OpenRouter saves the response and serves it from its edge cache.

Here’s how it works. When you send a request with caching enabled, OpenRouter hashes the request body, the model, your API key, and whether you’re streaming. That becomes a cache key.

If an identical request was made before and hasn’t expired, the cached response comes back immediately. No provider is called, no tokens are consumed, and you are not charged.

Think of it like a restaurant. The first time you order a dish, the chef cooks it fresh. It takes 10 minutes.

If you order the exact same thing again, they already have it ready. You get it in seconds. That’s literally what this does, but for AI.

02Key features of response caching

Response caching comes with several useful features that make it easy to control and verify.

  • Instant responses: Cached responses return in 80–300 milliseconds. The cache lookup itself averages 4ms.
  • Zero cost: Identical requests after the first one are free. No tokens are billed.
  • Works for many types: It works for text, images, audio, documents, and tool calls.
  • Streaming support: It works for both streaming and non-streaming requests.
  • Cache control: You can set how long responses stay cached from 1 second up to 24 hours. The default is 5 minutes.
  • Presets: You can enable caching in a preset config so it applies automatically to every request using that preset.

Response headers show you what happened. You’ll see xOpenRouterCacheStatus with hit or miss, plus the age of the cache and the TTL. This lets you confirm whether you got a cached response or a fresh one.

03How to set up OpenRouter response caching

Setting up OpenRouter response caching is simple. You just add a header to your API requests or enable it in your preset config. Here are the steps.

  1. Go to OpenRouter.ai and log in to your account.
  2. If you’re making API calls, add the header xOpenRouterCache: true to any request where you expect identical inputs.
  3. If you’re using presets, set cacheEnabled: true in your preset config. This applies caching to every request using that preset automatically.
  4. Optionally, set the cache lifetime by adding xOpenRouterCacheTTL with a value from 1 second to 24 hours. The default is 5 minutes.
  5. If you ever need a fresh response, add xOpenRouterCacheClear: true to bust the cache for that specific request.
  6. Check your response headers to confirm you’re getting cache hits. Look for xOpenRouterCacheStatus: hit.

That’s all you need to do. Once caching is on, repeated identical requests will be served from the cache instantly and for free.

04How to use it in real workflows

In this episode, Julian Goldie shows how OpenRouter response caching makes real-world workflows faster and cheaper. Here are examples from the episode.

First, think about an onboarding flow. When new members join a community, they often get the same welcome automation, FAQ responses, and intro content. Without caching, every one of those AI calls hits the model fresh.

With caching on, the first member triggers the generation. Everyone after that gets the same response instantly. You built the automation once, and now it runs fast and free.

Another example is testing AI workflows. When you’re building something, you tweak one part and run it again. Many steps are identical to last time.

Without caching, you pay for everything again. With caching, subsequent runs are deterministic and free after the first run populates the cache. This is huge if you’re iterating quickly.

You can also control the cache. Use xOpenRouterCacheTTL to set how long responses stay cached, from 1 second to 24 hours. If you need a fresh response, send xOpenRouterCacheClear: true to bust the cache for that request.

05Results and comparisons from the episode

The episode shows specific numbers for how long AI responses take without caching. For GPT 5.5, a request takes about 9.1 seconds. For KimiK2, it’s about 4.6 seconds.

Even Gemini 2.5 Flash, which is fast, takes about 1.3 seconds. Multiply that across dozens of requests, and it adds up quickly.

With OpenRouter response caching, cached responses return in 80–300 milliseconds. That’s a dramatic difference. For a GPT 5.5 request that normally takes 9.1 seconds, you wait once, and every identical request after that is instant.

The episode also clarifies that response caching is different from prompt caching. Prompt caching saves on the input side by caching a system prompt prefix. It still calls the model and you still pay for the completion.

Response caching skips the provider entirely. Nothing hits the model at all. These two can work together.

You can have prompt caching reduce input costs, while response caching eliminates costs for repeated identical requests.

06Tips, limits, and mistakes to avoid

There are a few important things to know about OpenRouter response caching to avoid mistakes.

  • No request coalescing: If two identical requests arrive at the exact same time before the first one is written to cache, both will result in a cache miss and both will be billed. This is rare, but possible.
  • Large payloads: Very large multimodal payloads that get offloaded internally for processing are not eligible for caching. Standard size requests cache fine.
  • Beta feature: Response caching is currently in beta. The API and behavior may change, so keep an eye on the docs.
  • Only successful responses are cached: Errors and partial outputs are not stored. Only successful responses get cached.
  • Don’t confuse with prompt caching: Prompt caching saves on input, but still calls the model. Response caching skips the provider entirely.

For most use cases, this feature works well. Just be aware of these limits, especially if you’re sending simultaneous identical requests or using very large payloads.

07Who should use response caching and why it matters

Anyone building AI workflows should consider turning on OpenRouter response caching today. It benefits content automation, client onboarding AI flows, and any scenario where the same input triggers the same output repeatedly.

Why does it matter? It makes AI workflows more predictable. You get faster responses and system outputs, and you only pay for genuinely new work.

Every repeated request without caching is a wasted call.

The episode also points out that OpenRouter gives you access to 300+ AI models through a single API. You don’t have to manage separate keys for Claude, GPT, Gemini, or Kimi. One place, one key, everything.

Now they’re solving the infrastructure layer with response caching. This is part of a bigger trend where the raw model performance gap is narrowing, and the infrastructure layer—speed, reliability, cost—becomes the differentiator.

If you’re already using OpenRouter, add the header to your API requests. If you’re using presets, flip cacheEnabled to true. Check your headers to confirm you’re getting cache hits.

If you’re not using OpenRouter yet, this is a good reason to start.