Adaptive Replacement Cache (ARC) is a self-tuning cache eviction policy that dynamically balances between recency-based (Least Recently Used (LRU)) and frequency-based (Least Frequently Used (LFU)) strategies by maintaining two adaptive lists. It continuously learns from the workload's access patterns, adjusting the size of its recency (T1) and frequency (T2) lists to minimize cache misses. This makes it highly effective for workloads with shifting or unpredictable access patterns, outperforming static policies like pure LRU or LFU.
Glossary
Adaptive Replacement Cache (ARC)

What is Adaptive Replacement Cache (ARC)?
A self-tuning, adaptive algorithm for managing cached data in memory-limited systems.
The algorithm's core innovation is its use of a ghost list (a history of recently evicted entries) to guide its adaptation. By tracking what was almost useful, ARC can detect changes in workload locality and proactively adjust its balance. This policy is foundational in agentic memory and context management, where efficient cache eviction is critical for maintaining high-performance access to frequently needed operational data within an autonomous agent's limited context window.
Key Features of ARC
Adaptive Replacement Cache (ARC) is a self-tuning, adaptive cache eviction policy that dynamically balances between recency-based (LRU) and frequency-based (LFU) caching strategies to optimize hit rates across varying workloads.
Dual Adaptive Lists
ARC maintains two adaptive lists instead of a single cache directory:
- List T1 (Recent Cache): Contains entries accessed only once recently (recency-focused, like LRU).
- List T2 (Frequent Cache): Contains entries accessed at least twice within a recent time window (frequency-focused, like LFU). A separate ghost list (B1, B2) for each tracks recently evicted entries, providing the algorithm with a 'history' of what was just removed to inform its adaptation.
Self-Tuning Parameter (p)
The core of ARC's intelligence is a dynamic parameter p that represents the target size for the recent list (T1). The algorithm continuously adjusts p based on workload:
- Recency-favoring workload: Increases
p, allocating more space to T1 (LRU-like behavior). - Frequency-favoring workload: Decreases
p, allocating more space to T2 (LFU-like behavior). This adjustment happens on every cache miss by checking the ghost lists, allowing ARC to converge on the optimal recency/frequency mix for the current access pattern without manual configuration.
Ghost (History) Lists
For each main list (T1, T2), ARC maintains a corresponding ghost list (B1, B2). These are metadata-only lists that store the keys of recently evicted items, not their values.
- Ghost Hit: If a requested item is found in a ghost list, ARC interprets this as evidence that the corresponding main list (T1 or T2) is too small.
- This ghost hit triggers an adaptive resizing: ARC increases the target size (
p) for the list that should have held the item, stealing a page from the other list. Ghost lists provide a low-overhead memory of past mistakes, enabling the algorithm to learn from near-misses.
Adaptive Replacement on Cache Miss
ARC's eviction and adaptation logic is triggered on a cache miss. The algorithm decides which list to evict from and whether to adapt p:
- If cache is full and a new item is inserted: Evict from T1 if
|T1| ≥ p; otherwise, evict from T2. - On a miss that is a ghost hit in B1: Increase
p(favor T1). - On a miss that is a ghost hit in B2: Decrease
p(favor T2). This ensures the policy reacts in real-time to changing access patterns, constantly rebalancing its resources between recency and frequency.
Resistance to Scan Attacks
ARC is highly resilient to one-time sequential scans (e.g., a full database table scan) that pollute and destroy the utility of traditional LRU caches.
- Mechanism: A scanned item enters T1 on its first access. Before it can be promoted to the frequent cache (T2), it is likely evicted by subsequent scanned items, as T1's size is controlled.
- The scanned items are recorded in the ghost list B1, but ARC correctly interprets this pattern and does not overreact by drastically resizing
p. This makes ARC particularly effective for database buffer pools and file system caches where mixed workloads are common.
Low Computational Overhead
Despite its adaptive complexity, ARC maintains O(1) complexity for all operations (insert, access, evict), comparable to LRU.
- Data Structures: Typically implemented using doubly-linked lists and hash maps for constant-time lookups and moves.
- The adaptive logic based on ghost list checks adds minimal constant-time overhead. This efficiency makes ARC suitable for high-performance systems where cache management cannot become a bottleneck, such as operating system page caches, database buffers, and CDN edge caches.
ARC vs. Other Eviction Policies
A technical comparison of the Adaptive Replacement Cache (ARC) algorithm against other common cache eviction policies, focusing on core mechanisms, performance characteristics, and implementation complexity.
| Feature / Metric | Adaptive Replacement Cache (ARC) | Least Recently Used (LRU) | Least Frequently Used (LFU) |
|---|---|---|---|
Core Eviction Heuristic | Dynamically balances recency (LRU) and frequency (LFU) | Recency of access only | Frequency of access only |
Adaptive Self-Tuning | |||
Resistance to One-Time Scans | High (protects frequency list) | Low (scan pollutes cache) | High (scan items have low frequency) |
Resistance to Looping Sequences | High (adapts to changing patterns) | Low (loops cause constant evictions) | Medium (can lock in looping items) |
Memory Overhead | ~2x cache size (maintains 4 lists) | Minimal (single list/queue) | Moderate (requires frequency counters) |
Computational Complexity (per access) | O(1) with hash map + lists | O(1) with hash map + list | O(1) with hash map + heap; O(log n) with strict ordering |
Handles Changing Access Patterns | |||
Requires Manual Parameter Tuning (e.g., λ) | |||
Typical Hit Ratio vs. LRU on Real Workloads | 5-25% higher | Baseline | Varies widely; can be higher or lower |
Frequently Asked Questions
Adaptive Replacement Cache (ARC) is a foundational self-tuning eviction algorithm critical for managing memory in agentic systems. These questions address its core mechanics, trade-offs, and practical applications for engineers.
Adaptive Replacement Cache (ARC) is a self-tuning, adaptive cache eviction policy that dynamically balances between recency-based (Least Recently Used - LRU) and frequency-based (Least Frequently Used - LFU) caching strategies to optimize hit rates. It works by maintaining four lists: two LRU lists (T1 for recent entries, T2 for frequent entries) and two ghost lists (B1 for recently evicted from T1, B2 for recently evicted from T2). The algorithm's core innovation is its adaptive parameter, p, which represents the target size for the T1 (recency) list. When a cache hit occurs on an item in a ghost list (B1 or B2), p is adjusted, effectively increasing the size of the list (T1 or T2) that would have benefited from retaining that item. This continuous feedback allows ARC to learn the optimal balance between recency and frequency for a given workload without manual configuration.
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
Adaptive Replacement Cache (ARC) operates within a broader ecosystem of memory management and eviction strategies. Understanding these related concepts is essential for engineers designing performant, self-tuning systems.
Least Recently Used (LRU)
Least Recently Used (LRU) is the foundational recency-based policy that ARC adaptively balances against. It evicts the item that has not been accessed for the longest time. While simple and effective for workloads with strong temporal locality, LRU can be exploited by sequential scans that pollute the cache and suffers under workloads with popular items that are accessed infrequently. ARC's T1 list initially behaves like an LRU list for newly seen items.
Least Frequently Used (LFU)
Least Frequently Used (LFU) is the frequency-based counterpoint to LRU, evicting the item with the lowest access count. It excels at retaining popular items but can be slow to adapt to changing access patterns, as historically frequent but now stale items can persist. ARC's T2 list functions as an LFU-style list for items that have been accessed more than once, allowing ARC to protect frequently accessed entries from eviction.
Working Set Model
The working set model is a theoretical framework defining the set of memory pages a process actively needs within a specific time window to run efficiently without excessive page faults. ARC is a practical, online algorithm that implicitly learns and caches the dynamic working set of an application. By adapting the size of its recency (T1) and frequency (T2) lists, ARC directly optimizes for the currently active working set, minimizing cache misses as the workload changes.
2Q Algorithm
The 2Q (Two-Queue) algorithm is a direct precursor to ARC, using two LRU queues: A1-in for single-access items and Am for multi-access (hot) items. Items enter A1-in; if accessed again before eviction, they move to Am. ARC generalizes and improves upon 2Q by making the boundary between its two lists adaptive based on workload, whereas 2Q uses a fixed-size buffer for new entries. ARC's adaptive parameter (p) dynamically resizes its equivalent lists, providing superior performance across diverse workloads.
Clock-Pro Approximation
Clock-Pro is a low-overhead, approximate implementation of the Adaptive Replacement Cache policy designed for operating system page replacement. It uses clock hands (circular pointers) to scan pages, approximating ARC's recency/frequency lists and adaptive parameter with reference bits and test periods. While more efficient to execute than ARC's exact list management, Clock-Pro provides similar self-tuning behavior, making ARC's principles practical for kernel-level memory management where computational overhead is critical.
Cache Eviction Policy
A cache eviction policy is the overarching algorithmic rule that determines which item to remove when a cache reaches capacity. ARC is a specific, advanced eviction policy within this category. Key design considerations for any eviction policy include:
- Overhead: Computational cost of maintaining metadata (access counts, timestamps).
- Workload Sensitivity: Performance across scan-heavy, looping, or mixed access patterns.
- Predictability: Whether the policy's behavior is deterministic or adaptive. ARC is distinguished by its self-tuning nature, automatically adjusting its behavior without manual parameter tuning.

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