The LRU-K algorithm is a cache eviction policy that generalizes the standard Least Recently Used (LRU) approach by considering the times of the last K accesses to an item, rather than just the single most recent access. It maintains a history list for all items, recording their last K access timestamps. When the cache is full and a new item must be inserted, the algorithm evicts the item with the largest backward K-distance, which is the time since its K-th-to-last reference. This provides a more nuanced prediction of future use, as it distinguishes between items accessed once recently and those accessed frequently over a longer period.
Glossary
LRU-K Algorithm

What is the LRU-K Algorithm?
The LRU-K algorithm is an advanced cache eviction policy designed to predict future access patterns more accurately than standard Least Recently Used (LRU) by tracking the times of the last K references to each item.
In practice, LRU-K significantly improves the cache hit ratio for workloads with complex, non-stationary access patterns, such as database buffer pools or agent-side API response caches, where simple recency is a poor predictor. The parameter K (typically 2) controls the depth of historical tracking, balancing prediction accuracy against the metadata overhead. A key operational detail is that items with fewer than K recorded accesses are treated as having an infinite backward K-distance, making them prime candidates for eviction and preventing one-time accesses from polluting the cache.
LRU-K vs. Other Eviction Algorithms
A technical comparison of the LRU-K algorithm against other common cache eviction policies, focusing on their mechanisms, performance characteristics, and suitability for different access patterns.
| Algorithm / Feature | LRU-K | Standard LRU | LFU | ARC (Adaptive Replacement Cache) |
|---|---|---|---|---|
Core Eviction Metric | Time of K-th-to-last access | Time of single last access | Total historical access frequency | Dynamic blend of recency (LRU) and frequency (LFU) |
Predictive Power for Future Access | High (models access patterns over K references) | Low (only considers most recent access) | Medium (considers long-term popularity) | Very High (self-tuning based on workload) |
Resistance to One-Time Scans | High (K > 1 prevents pollution) | Very Low (easily polluted by sequential scans) | High (scans don't accumulate high frequency) | High (dynamically adjusts) |
Memory Overhead Per Item | Moderate (stores K access timestamps) | Low (stores single timestamp or position) | Moderate (stores frequency counter) | High (maintains separate LRU and LFU lists) |
Implementation Complexity | High | Low | Medium | Very High |
Optimal For | Workloads with stable, recurring patterns (e.g., database query caching, agent-side API caching) | Simple, recency-biased workloads | Workloads with stable, highly popular items (e.g., static content CDN) | Variable, unknown, or shifting access patterns |
Handles Shifting Access Patterns | Moderate (requires tuning of K) | Poor | Poor (suffers from cache pollution by old popular items) | Excellent (primary design goal) |
Typical Hit Ratio Improvement over LRU | 15-40% | Baseline | Varies widely; can be worse than LRU on shifting patterns | Can exceed LRU by 20-50% on mixed workloads |
Frequently Asked Questions
The LRU-K algorithm is an advanced cache eviction policy designed to improve upon standard LRU by considering the frequency of recent accesses. These questions address its core mechanics, use cases, and implementation details.
The LRU-K algorithm is a cache eviction policy that tracks the times of the last K references to each cached item to make more informed predictions about future access patterns than a standard Least Recently Used (LRU) policy. It works by maintaining a history list for items not currently in the cache and a main cache for active items. For each access, the algorithm records a timestamp. When the cache is full and a new item needs to be inserted, the algorithm evicts the item with the oldest K-th-to-last access time, effectively penalizing items that have not been accessed frequently in the recent past. This approach better distinguishes between one-hit wonders (items accessed once) and genuinely popular items, leading to a higher cache hit ratio.
Key Mechanism:
- History List: Stores access history for items evicted from the main cache.
- K-th Access Time: The core metric for eviction decisions.
- Parameter K: Typically set to 2, balancing recency and frequency.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
LRU-K is a sophisticated eviction policy within the broader domain of caching. These related terms define the core concepts, patterns, and algorithms that performance engineers use to design and evaluate efficient agent-side caching systems.
Cache Eviction
Cache eviction is the process of removing items from a cache to free up space for new entries. It is governed by specific policies that determine which item to remove.
- Primary Goal: Maximize cache utility by retaining the most valuable data.
- Triggered by: Cache reaching its capacity limit or an item expiring based on Time-To-Live (TTL).
- Policies: Range from simple (FIFO, Random) to complex (LRU, LFU, ARC, LRU-K). LRU-K is an advanced eviction policy designed to predict future access more accurately than standard LRU.
Least Recently Used (LRU)
Least Recently Used (LRU) is a foundational cache eviction algorithm that removes the item that has not been accessed for the longest period when space is needed.
- Mechanism: Tracks only the timestamp of the most recent access for each cached item.
- Weakness: Vulnerable to one-time scans or large, non-repeating queries that can flush the entire cache of useful, frequently accessed items.
- Relation to LRU-K: LRU is a specific case of LRU-K where K=1. LRU-K generalizes this by tracking the last K accesses to better distinguish between infrequently accessed and truly cold items.
Adaptive Replacement Cache (ARC)
Adaptive Replacement Cache (ARC) is a self-tuning, patented eviction algorithm that dynamically balances between recency (like LRU) and frequency (like LFU) to optimize hit ratio under varying access patterns.
- Core Idea: Maintains two LRU lists: one for recently accessed items (T1) and one for frequently accessed items (T2). A ghost list tracks recently evicted items to adapt the size of T1 and T2.
- Comparison to LRU-K: Both are advanced policies. ARC adapts cache partition sizes between recency/frequency. LRU-K uses a deeper access history (K references) to make a more informed eviction decision on a per-item basis. ARC is often more complex to implement due to its adaptive ghost lists.
Cache Hit Ratio
Cache hit ratio is the primary performance metric for any caching system, calculated as (Number of Cache Hits / Total Cache Requests) * 100%.
- Significance: Directly correlates to reduced latency, lower backend load, and improved system throughput. A high hit ratio indicates an effective caching strategy.
- Optimization Target: The sole purpose of advanced eviction policies like LRU-K is to maximize the cache hit ratio for a given cache size and workload.
- Measurement: Must be monitored continuously. LRU-K typically outperforms standard LRU on workloads with mixed access patterns, leading to a higher sustained hit ratio.
Deterministic Cache
A deterministic cache stores the results of pure, side-effect-free functions where the same input arguments always produce the identical output.
- Key Property: Enables safe, correct caching because the cached value is guaranteed to be valid for its key indefinitely (or until the underlying function logic changes).
- Use Case: Ideal for caching agent-side computations, LLM inference on static prompts, or API calls to idempotent endpoints.
- Connection to LRU-K: LRU-K is an eviction policy, not a cache type. A deterministic cache can use LRU-K to manage its storage, evicting the least valuable deterministic results when the cache is full.
Cache Admission Policy
A cache admission policy is a rule that determines whether a newly fetched or computed data item should be inserted into the cache at all. It works in tandem with the eviction policy.
- Purpose: To prevent low-value or one-time-use items from polluting the cache and evicting more valuable data. Not all data deserves a cache entry.
- Common Policies: Always admit (standard), admit if future access is predicted (complex), or admit only if fetched on a second request (like in 2Q algorithm).
- LRU-K Context: LRU-K is primarily an eviction policy. Its historical data (K-access history) can, however, inform a sophisticated admission policy—for example, only admitting items after their K-th access, indicating they are entering a frequent-access phase.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us