Optimize LLM Prompts with Caching Strategies

This skill covers caching strategies specifically for LLM prompts: Anthropic's native prompt caching, response caching, and Cache Augmented Generation (CAG). It scopes itself deliberately narrow - it does not cover CDN caching, database query caching, or static asset caching, focusing only on prompt- and response-level caching for LLM calls.

Three patterns are covered with working TypeScript. Anthropic prompt caching marks stable prefixes (a long system prompt, a static knowledge base) with cache_control: { type: "ephemeral" } via the @anthropic-ai/sdk client, claiming roughly a 90% cost reduction on cached tokens and up to 2x lower latency. Response caching hashes a prompt (SHA-256) and stores the full response in Redis (ioredis on servers, @upstash/redis for serverless/edge without a persistent connection), with variants for exact-match caching, semantic-similarity caching via embeddings, and temperature-aware caching that only caches low-temperature (<=0.5) responses. CAG pre-computes and caches an entire document corpus directly in the prompt instead of doing RAG retrieval, with a stated decision matrix: CAG wins when the corpus is under ~100K tokens, updates infrequently, and latency is critical; RAG wins for larger, more frequently updated, or more specific-query corpora.

Use this skill when implementing caching specifically for LLM prompts or responses - Claude's native prompt caching for repeated system-prompt prefixes, response caching for repeated identical queries, or CAG when a document set is stable and small enough to fit in context. It explicitly recommends context-window-management as a prerequisite skill, and delegates to rag-implementation when retrieval (not caching) is the real need, or to conversation-memory when the need is persistence rather than caching.

Don't reach for it for CDN, database, or static-asset caching - those are out of scope by design. And don't cache high-temperature responses (above 0.5) since they're non-deterministic by nature, and don't cache without a TTL, since that risks serving stale data indefinitely.

The skill documents four named "sharp edges" with severity ratings and fixes: a cache miss adding more latency than no caching at all (HIGH - fixed with a non-blocking race between cache lookup and the LLM call, or selective caching of only high-frequency query patterns); cached responses going stale because source data changed with no invalidation (HIGH - fixed with version-based, content-hash-based, or event-based invalidation); and Anthropic prompt caching silently missing because the cached prefix isn't byte-identical between calls, often from a timestamp or other dynamic content leaking into the system block (MEDIUM - fixed by keeping the cached prefix fully static and putting dynamic content only in the user message).

Named tools are Anthropic's native Prompt Caching API, Redis (via ioredis or @upstash/redis) for response storage, and OpenAI's automatic API-level caching.

Developers building LLM applications who need to cut token costs and latency on repeated prompts or queries, and who need concrete guidance on the specific ways prompt and response caching silently break (stale data, prefix mismatches, and net-negative cache misses).