# Prompt Caching, Routers and AI Gateways Compared

[Skip to content](#lm-inhoud)Network/[NL](/en/tools-voor-prompt-caching-semantische-routers-en-gateway-proxy-s)EN[Hubhub.llmnet.nlCompare models on task, language, cost and licence.](https://hub.llmnet.nl/en/)[Communitycommunity.llmnet.nlPrompt techniques, patterns and system prompts.](https://community.llmnet.nl/en/)[APIapi.llmnet.nlLLMs in production: rate limits, routing, structured output.](https://api.llmnet.nl/en/)[Consultancyconsultancy.llmnet.nlRolling out AI in an organisation, pilot to production.](https://consultancy.llmnet.nl/en/)[Newsnieuws.llmnet.nlAI developments, explained for the Netherlands.](https://nieuws.llmnet.nl/en/)[Benchmarkbenchmark.llmnet.nlMeasure AI quality yourself, on your own tasks.](https://benchmark.llmnet.nl/en/)[Careersvacatures.llmnet.nlAI roles, salaries and career paths in the Netherlands.](https://vacatures.llmnet.nl/en/)[Learnleren.llmnet.nlAI concepts in plain language, beginner to builder.](https://leren.llmnet.nl/en/)[Guidegids.llmnet.nlRun AI privately on your own Mac, PC, NAS or home server.](https://gids.llmnet.nl/en/)[Directorydirectory.llmnet.nlMapping the AI ecosystem: tools, models, companies.](https://directory.llmnet.nl/en/)[Radarradar.llmnet.nlSignals from X, research and communities for indie developers.](https://radar.llmnet.nl/en/)[Appsapps.llmnet.nlReviews of AI apps and open-source repos, with tips for builders.](https://apps.llmnet.nl/en/)[llmnet.nl — main site](https://llmnet.nl/en/)[](https://x.com/intent/post?url=https%3A%2F%2Fdirectory.llmnet.nl%2Fen%2Ftools-voor-prompt-caching-semantische-routers-en-gateway-proxy-s&text=Prompt%20Caching%2C%20Routers%20and%20AI%20Gateways%20Compared)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fdirectory.llmnet.nl%2Fen%2Ftools-voor-prompt-caching-semantische-routers-en-gateway-proxy-s)[](https://www.reddit.com/submit?url=https%3A%2F%2Fdirectory.llmnet.nl%2Fen%2Ftools-voor-prompt-caching-semantische-routers-en-gateway-proxy-s&title=Prompt%20Caching%2C%20Routers%20and%20AI%20Gateways%20Compared)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fdirectory.llmnet.nl%2Fen%2Ftools-voor-prompt-caching-semantische-routers-en-gateway-proxy-s&text=Prompt%20Caching%2C%20Routers%20and%20AI%20Gateways%20Compared)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fdirectory.llmnet.nl%2Fen%2Ftools-voor-prompt-caching-semantische-routers-en-gateway-proxy-s)[](https://www.reddit.com/submit?url=https%3A%2F%2Fdirectory.llmnet.nl%2Fen%2Ftools-voor-prompt-caching-semantische-routers-en-gateway-proxy-s&title=Prompt%20Caching%2C%20Routers%20and%20AI%20Gateways%20Compared)[](#)

 
# Tools for prompt caching, semantic routers, and gateway proxies

 By Ivo Donker — compiled with AI assistance (Claude & Gemini)

 
 Status & Verification: Categories, proxy architectures, and tool examples checked on 2026-08-19. This overview positions network-layer tools within the broader infrastructure layer for language models.

 

 When applications make intensive use of large language models, developers inevitably run into three bottlenecks: unpredictable network latency, escalating API costs, and fragile dependencies on external providers. Calling a model API directly from application code works fine for simple prototypes, but falls short once scalability, cost control, and fault tolerance are required. To solve these challenges structurally, a specialized intermediate layer has emerged that acts as an intelligent traffic controller between the application logic and the underlying inference servers.

 This architectural intermediate layer combines three closely intertwined disciplines: caching previous prompts and responses, dynamically routing prompts to the most suitable model, and managing API keys, rate limits, and failovers via reverse proxies. Within [the complete category map of the AI ecosystem](https://directory.llmnet.nl/en/ai-ecosysteem-categorieen) this category forms a crucial part of the operational software stack that keeps production deployments profitable and stable. Understanding how these tools work prevents applications from needlessly repeating the same computations or deploying unnecessarily heavy models for trivial tasks.

 
## The anatomy of the AI gateway: three complementary tasks

 Although many open source projects and hosted services simply market themselves as an 'AI Gateway', in practice they fulfill different tasks. To make a well-considered architecture choice, it helps to split the responsibilities of the proxy layer into three clear components:

 
 
- Prompt & Response Caching: Storing computation results to handle identical or semantically similar prompts instantly, without sending a new inference request to the provider.
 
- Semantic Routing: Inspecting the incoming prompt for intent, complexity, or domain in order to route the query to the smallest, fastest, or cheapest model that can handle the task.
 
- Gateway & Proxy Management: Centralizing rate limiting, credential pooling, retries with exponential backoff, load balancing, and harmonized logging across multiple providers.
 

 In complex systems, these three layers work together seamlessly. An incoming prompt first passes through the cache; on a cache miss, the semantic router analyzes the content and selects a route; the gateway proxy then handles the actual delivery to the selected provider, with automatic failover during outages. Anyone who wants to make a targeted choice based on specific system requirements can use [the interactive AI tool picker](https://directory.llmnet.nl/en/ai-tool-kiezer) to check how these components connect to other parts of the application landscape.

 
## Exact prefix caching versus server-side KV caching

 Caching for LLMs works fundamentally differently from traditional HTTP caching. Where a web server matches an exact URL or JSON payload, the efficiency of LLM caching depends on the internal workings of the Transformer architecture. We distinguish two primary approaches here: provider-native prefix caching and local key-value caching (KV caching).

 Large API providers such as Anthropic, Google, and OpenAI now support server-side prompt caching. In this setup, the provider keeps the computed key-value states of earlier tokens in GPU memory. When consecutive requests share exactly the same prefix (such as a large system prompt, a document set, or a detailed JSON schema), the inference engine doesn't need to recompute these tokens. This significantly lowers both the token price and the Time to First Token (TTFT).

 To understand how this translates into concrete cost savings in application architectures, [the architecture guide on caching LLM responses](https://api.llmnet.nl/en/caching-llm-antwoorden) offers a detailed insight into the financial and technical dynamics of response caching. The most important condition for successful server-side caching is byte-identical consistency: a single space or variable date at the beginning of the system prompt invalidates the entire cache index.

 
 
 
 
 Mechanism | 
 Location | 
 Matching method | 
 Latency gain | 
 Limitations | 
 

 
 
 
 Provider KV Cache | 
 GPU cluster provider | 
 Exact token prefix | 
 Moderate (no input TTFT) | 
 Minimum token threshold, TTL-dependent | 
 

 
 Exact Response Cache | 
 Local gateway / Redis | 
 Cryptographic hash (SHA-256) | 
 Very high (< 5 ms) | 
 Only works with 100% identical prompts | 
 

 
 Semantic Cache | 
 Vector database / Gateway | 
 Cosine similarity on embeddings | 
 High (15–40 ms) | 
 Risk of contextual errors (false positives) | 
 

 
 
 

 
## Semantic caching: vector matching and threshold values

 Exact hashing falls short when end users ask questions that are identical in content but differ in wording. A question like "How do I reset my password?" after all has exactly the same answer as "Forgot password, what should I do?". Semantic caching solves this by converting prompts into vector embeddings and retrieving earlier answers when the cosine similarity exceeds a preset threshold.

 Two leading open source libraries in this domain are GPTCache and the semantic caching module of Redis. Both systems first convert the incoming user question into a vector using a compact embedding model. A vector index then searches for similar earlier queries within the vector space. If the computed distance is smaller than the configured threshold (for example, a cosine similarity of 0.92 or higher), the system immediately returns the previously generated answer.

 The effectiveness of a semantic cache stands or falls with the quality of the underlying embedding model. Consult [the comparative overview of embedding models](https://directory.llmnet.nl/en/embedding-modellen-vergeleken) to determine which models offer sufficient dimensional separation for semantic comparisons in Dutch. A threshold that's too low leads to 'false positives', where users get an answer that belonged to a subtly different question. A threshold that's too high instead results in unnecessary cache misses.

 # Voorbeeld: Semantische cache evaluatie met Python
from gptcache import cache
from gptcache.adapter import openai
from gptcache.embedding import FastText
from gptcache.similarity_evaluation.distance import SearchDistanceEvaluation

# Initialiseer de semantische cache met een strikte drempelwaarde
cache.init(
 embedding_func=FastText().to_embeddings,
 evaluation_func=SearchDistanceEvaluation(max_distance=0.15)
)

# Aanroepen via de cache wrapper
response = openai.ChatCompletion.create(
 model="gpt-4o-mini",
 messages=[{"role": "user", "content": "Wat is het retourbeleid?"}]
)

 
## Semantic routers: dynamic model selection based on complexity

 Not every question requires an advanced, top-tier reasoning model. Simple extractions, routing questions, or factual summaries can easily be handled by compact models such as Llama 3 8B or Mistral NeMo, while complex multi-step reasoning needs to be routed to larger models. Semantic routers provide this intelligent triage.

 Tools such as Semantic Router (from Aurelio AI) and RouteLLM (developed by LMSYS) categorize the intent or difficulty of a prompt within milliseconds. RouteLLM, for example, trains lightweight routers (such as Matrix Factorization or BERT-based classifiers) on benchmark datasets to predict whether a cheaper model can produce an answer of equal quality to a 'frontier' model. If the task turns out to be simple, the router sends the prompt to a local or inexpensive API model; if the task requires deep abstraction, the system routes it to the primary flagship model.

 For software teams weighing a ready-made routing solution against a custom-built classification layer, [the trade-off between building, buying, or algorithms for routing](https://api.llmnet.nl/en/kopen-bouwen-of-algoritme-routing) analyzes which operational trade-offs this brings in terms of latency and maintenance costs.

 
## Gateway proxies and load balancers in production

 Once an organization drives dozens of microservices or internal applications through external LLM providers, it becomes unworkable to program authentication, budgeting, and error handling separately in every codebase. A central reverse proxy for LLM traffic centralizes these responsibilities and exposes a uniform, OpenAI-compatible interface to the outside world.

 
 
 
 
 Tool / Platform | 
 Type | 
 Primary focus | 
 Hosting options | 
 

 
 
 
 LiteLLM Proxy | 
 Open source / Self-hosted | 
 Unified interface for 100+ APIs, load balancing, key management | 
 Docker, Kubernetes, Bare metal | 
 

 
 Portkey | 
 Open source core / SaaS | 
 Enterprise governance, tracing, fallbacks, and budget monitoring | 
 Self-hosted or Managed Cloud | 
 

 
 Kong AI Gateway | 
 API Gateway Plugin | 
 Integration of AI traffic within existing enterprise API architectures | 
 Kubernetes, Hybrid cloud | 
 

 
 Cloudflare AI Gateway | 
 Managed Edge Proxy | 
 Fast edge caching, basic rate limiting, and observability | 
 Fully serverless on the Cloudflare network | 
 

 
 
 

 LiteLLM Proxy has positioned itself as the de facto open source standard for interoperability. It allows teams to send prompts to a single central endpoint, after which the proxy translates the request into the specific JSON format of providers such as Anthropic, Mistral, Vertex AI, AWS Bedrock, or local vLLM instances. This lets developers switch underlying models without changing a single line of code in the frontend.

 
## Error handling, circuit breakers, and failover patterns

 External AI APIs are inherently volatile. Providers regularly struggle with capacity shortages, overloaded GPU clusters, and temporary 429 Rate Limit Exceedederror messages. A robust gateway proxy therefore implements advanced resilience patterns to keep applications online during outages.

 The most important patterns a gateway handles are:

 
 
- Key Pooling and Round-Robin: Distributing requests across multiple API keys of the same account to avoid exceeding per-key quotas.
 
- Fallback Cascades: When the primary provider (for example, Anthropic Claude) returns a 500 or 529 error, the proxy automatically switches to an equivalent model on AWS Bedrock or Azure OpenAI within 200 milliseconds.
 
- Circuit Breakers: Temporarily blocking requests to an unstable provider to prevent application threads from filling up with timeouts, while traffic is routed directly to a healthy secondary provider.
 
- Automatic Retries with Jitter: Repeating failed network requests with exponentially increasing wait times and random delay ('jitter') to prevent the 'thundering herd' problem in recovering APIs.
 

 The configuration below illustrates how a model router with automatic fallbacks is defined in a proxy environment:

 # Voorbeeld: LiteLLM Proxy configuratie met fallback-keten
model_list:
 - model_name: productie-redeneren
 litellm_params:
 model: anthropic/claude-3-5-sonnet-20241022
 api_key: os.environ/ANTHROPIC_API_KEY
 rpm: 1000
 - model_name: productie-redeneren
 litellm_params:
 model: bedrock/anthropic.claude-3-5-sonnet-20241022-v2:0
 aws_region_name: eu-central-1
 rpm: 1000

router_settings:
 fallbacks: [{"productie-redeneren": ["bedrock/anthropic.claude-3-5-sonnet-20241022-v2:0"]}]
 num_retries: 3
 timeout: 10
 allowed_fails: 2
 cooldown_time: 60

 
## Measurement methods and observability for proxy infrastructure

 Introducing an extra intermediate layer always raises questions about overhead and network latency. To verify whether a caching and routing layer actually adds value, infrastructure engineers need to continuously monitor specific performance metrics.

 The three key metrics to monitor are:

 
 
- Cache Hit Ratio (CHR): The percentage of requests successfully answered from the cache. In production environments with strict document Q&A, a healthy semantic CHR lies between 20% and 45%.
 
- Proxy Overhead Latency (P99): The delay that the proxy itself adds to the chain (excluding inference time). A well-configured proxy built on Go, Rust, or optimized async Python adds less than 10 to 25 milliseconds to the P99.
 
- Cost Savings Index per Token Class: The savings achieved by routing prompts to smaller models and intercepting repeated prompts through KV caching.
 

 To correlate these data streams with token usage and error rates, gateways integrate directly with specialized monitoring tools. In [the overview of LLM observability tools](https://directory.llmnet.nl/en/llm-observability-tools) , platforms are discussed that aggregate OpenTelemetry spans from gateways for detailed trace analysis and debugging.

 
## Self-hosting versus managed gateway services

 When selecting proxy and routing technology, organizations face the fundamental choice between self-hosted components and fully managed cloud services. This decision is primarily driven by compliance requirements, data sovereignty, and operational complexity.

 Self-hosted solutions (such as your own LiteLLM or Kong cluster in a private VPC) offer maximum control over data traffic. Requests and sensitive personal data never leave your own infrastructure before being anonymized or filtered on their way to the provider. This is often a hard requirement in regulated sectors such as finance and healthcare. The downside is that the team itself is responsible for high availability, zero-downtime updates, and managing the underlying Redis and database clusters.

 Managed cloud services (such as Portkey SaaS or Cloudflare AI Gateway) remove operational maintenance entirely and offer ready-made dashboards, but introduce an additional external party with access to prompt metadata. Organizations need to weigh, per use case, whether the convenience of a managed gateway outweighs the risk of vendor lock-in and possible compliance restrictions.

 
## Selection criteria for software architects

 The landscape of network tools for AI is evolving quickly. To choose the right components for a specific workload, software architects can apply the criteria below during evaluation:

 
 
- Support for streaming responses: Can the gateway stream server-sent events (SSE) smoothly without blocking semantic routing or the generation of trace logs?
 
- Granular budget management: Does the system offer the ability to create virtual keys with strict limits per user, team, or environment (development versus production)?
 
- Compatibility with open standards: Does the proxy use the OpenAI API standard, so that client applications can switch with minimal code changes?
 
- Memory efficiency of the router: How much extra compute power does the local embedding or classification model that drives the routing require?
 

 Thoughtfully combining prompt caching, semantic routing, and gateway proxies creates a resilient and cost-efficient architecture. It decouples application logic from specific LLM providers and helps organizations stay agile in a market where model performance and pricing are constantly changing.

 
 Overview verified on 2026-08-19: This dossier is periodically reviewed to accurately document new open source releases, proxy engines, and provider-specific cache protocols.