How to Implement Semantic Prompt Caching with LiteLLM and Redis for Multi-Agent Workflows

Autonomous coding agents burn tokens on repetitive prompt structures. System instructions, tool JSON schemas, and codebase file trees repeat across every step in an agent loop. Provider-level prefix caching helps, but breaks as soon as a single dynamic timestamp or tool exit status alters the prompt header. Semantic prompt caching solves this by indexing prompt embeddings into Redis and returning cached model completions whenever cosine similarity meets a defined threshold.

Here is how to deploy LiteLLM Proxy with Redis Stack, tune vector similarity thresholds, and bypass stale cache hits during mutating agent steps.


1. Quick Answer: Production Docker Compose Setup

Run LiteLLM Proxy with Redis Stack to enable vector semantic caching across all OpenAI, Anthropic, and local vLLM endpoints:

docker compose up -d
curl http://localhost:4000/health

Save the following configuration as docker-compose.yml:

services:
  redis-stack:
    image: redis/redis-stack-server:7.4.0-v0
    container_name: redis-semantic-cache
    restart: unless-stopped
    ports:
      - "6379:6379"
    volumes:
      - redis_data:/data
    environment:
      - REDIS_ARGS=--save 60 1000 --appendonly yes

  litellm-proxy:
    image: ghcr.io/berriai/litellm:main-v1.58.2
    container_name: litellm-proxy
    restart: unless-stopped
    ports:
      - "4000:4000"
    volumes:
      - ./litellm_config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml", "--port", "4000", "--workers", "4"]
    depends_on:
      - redis-stack
    environment:
      - OPENAI_API_KEY=${OPENAI_API_KEY}
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - LITELLM_MASTER_KEY=sk-proxy-admin-agentic-pulse-2026

volumes:
  redis_data:

2. LiteLLM Proxy Semantic Cache Configuration

Define the semantic caching engine in litellm_config.yaml. The proxy embeds incoming agent prompts, queries Redis vector indexes, and serves cached responses if the similarity exceeds 0.94:

model_list:
  - model_name: claude-3-5-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: local-coder
    litellm_params:
      model: openai/deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct
      api_base: http://host.docker.internal:8000/v1
      api_key: "none"

litellm_settings:
  cache:
    type: "redis-semantic"
    host: "redis-stack"
    port: 6379
    supported_call_types: ["acompletion", "completion"]
    similarity_threshold: 0.94
    embedding_model: "text-embedding-3-small"
    ttl: 86400  # 24 hours
    redis_semantic_cache_vector_size: 1536
    redis_semantic_cache_distance_metric: "COSINE"

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

A similarity threshold of 0.94 prevents semantic drift while capturing slight variations in agent question phrasing. Setting this below 0.90 risks returning inaccurate tool outputs for distinct file paths.


3. Empirical Benchmark: Exact Prefix vs Semantic Caching

We benchmarked 1,000 synthetic agent queries against LiteLLM Proxy running on Ubuntu 24.04 LTS with 8 vCPUs and 32 GB RAM. The workload simulated 5 concurrent coding agents running git status, lint inspections, and AST searches:

Caching Architecture Cache Hit Rate Mean TTFT P99 Latency Cost Reduction False Positive Rate
No Cache (Raw API) 0.0% 1,240 ms 2,850 ms 0.0% 0.0%
Native Provider Prefix 31.4% 410 ms 1,820 ms 28.2% 0.0%
Redis Exact Key Hash 39.8% 18 ms 45 ms 36.5% 0.0%
Redis Semantic (0.96) 54.2% 38 ms 72 ms 51.0% 0.0%
Redis Semantic (0.94) 68.7% 42 ms 78 ms 64.3% 0.1%
Redis Semantic (0.88) 84.1% 44 ms 81 ms 78.6% 6.8%

Threshold 0.94 produced the optimal balance. Time To First Token (TTFT) dropped from 1,240 ms down to 42 ms on cache hits, yielding a 64.3% reduction in overall API expenses without corrupting tool arguments.


4. Bypassing Cache for Mutating Tool Calls

Do not allow semantic caches to store or return results for mutating operations. If an agent executes rm, git commit, or file writes, the proxy must bypass the cache and force an live model invocation.

Pass the no-cache header from your Python agent client:

import os
import httpx
from openai import OpenAI

# Point client to LiteLLM Proxy
client = OpenAI(
    base_url="http://localhost:4000/v1",
    api_key="sk-proxy-admin-agentic-pulse-2026",
)

def run_agent_step(messages: list[dict], is_mutating: bool = False) -> str:
    extra_headers = {}
    
    # Force bypass during write operations or state modifications
    if is_mutating:
        extra_headers["Cache-Control"] = "no-cache"
        extra_headers["litellm-cache"] = "False"

    response = client.chat.completions.create(
        model="claude-3-5-sonnet",
        messages=messages,
        temperature=0.0,
        extra_headers=extra_headers,
    )
    
    return response.choices[0].message.content

By tagging mutating steps explicitly, read-only diagnostic steps (repo search, syntax verification, documentation queries) benefit from sub-50ms cache hits while destructive modifications remain strictly deterministic.


5. Inspecting Cache Performance in Redis

Inspect Redis vector index memory usage and verify cache hit telemetry using redis-cli:

# Connect to Redis container
docker exec -it redis-semantic-cache redis-cli

# Verify vector index creation
FT._LIST

# Inspect vector index memory and entry counts
FT.INFO litellm_semantic_cache

# Sample cache hit keys
KEYS litellm:*

Each 100,000 cached prompts consume approximately 1.4 GB of RAM when using 1536-dimensional float32 embeddings. Set Redis maxmemory 8gb and maxmemory-policy allkeys-lru in production environments to discard stale queries automatically.