MONA explainer 11 min read

Sliding Windows, Summarization, KV Cache, and the Hard Technical Limits of Context Compression in 2026

MONA examining a memory diagram showing KV cache growth and sliding window attention patterns in a production LLM pipeline

ELI5

Context window management is the discipline of keeping LLMs within operational bounds during inference — using sliding window attention, KV cache optimization, adaptive summarization, and prompt caching to avoid memory exhaustion and runaway token costs in production.

The anomaly arrives before you hit the token limit.

Engineers running extended pipelines against Claude Fable 5 or GPT-5.5 encounter a recognizable sequence: prototyping works cleanly; integration tests pass; then somewhere between 50K and 200K tokens in, prefill latency starts climbing. Memory warnings appear. Per-request costs that looked manageable during development begin compounding in ways the API documentation didn’t predict.

The token limit itself is rarely the constraint that bites.

Every token fed into a model writes key and value tensors into GPU high-bandwidth memory — per attention layer, for the lifetime of the generation. The Context Window advertised in an API’s model card describes what the model can accept. The physics of storing the attention state across every one of those tokens is what production systems encounter first.

The Memory Tax on Every Token a Model Processes

Think of the KV cache as working memory with no eviction policy. Unlike a CPU cache that can page stale entries to slower storage, GPU HBM holds every key-value tensor for every active token in every layer until generation completes — accumulating linearly, with no compression, no expiry, and no negotiation with the available hardware budget.

The KV Cache stores per-layer key and value tensors computed during the prefill phase. Without it, attention at decode time would recompute every prior token’s relationship to every other token at each generation step — a cost that scales quadratically with sequence length. The cache makes inference tractable by trading memory for compute: compute once during prefill, reuse through decode. At FP16 precision, a 7B-parameter model requires approximately 0.5 MB of HBM per token in context (introl.com blog). At 128K tokens, that is roughly 64 GB for the cache alone; at 1M tokens, the number exceeds what most individual GPU configurations can serve without distributed memory management.

The memory cost scales linearly with context length, even as vendor token limits scale into the millions.

Traditional KV allocation compounds this with fragmentation: each sequence pre-reserves its maximum possible length before generation begins, regardless of actual use. This wastes 60–80% of allocated KV memory. vLLM’s PagedAttention manages the cache in fixed-size pages — the same principle as virtual memory, applied to attention state — cutting waste to under 4% (introl.com blog).

What are the main techniques for managing context windows in production LLMs?

Four approaches define Context Window Management in production. They operate at different layers of the inference stack and are typically combined rather than chosen between.

Sliding window attention constrains the attention computation itself. Rather than attending to all tokens in the context simultaneously, the model attends only to a local window of W tokens per layer. Multiple stacked layers extend the effective receptive field beyond any single window; Mistral 7B uses W = 4,096 tokens per layer, which produces a theoretical stacked receptive field of approximately 131K tokens (Mistral 7B paper).

Prompt Caching is a serving infrastructure optimization. The key-value tensors of a static context prefix are cached server-side and shared across requests that begin with the same prefix. Subsequent calls pay a fraction of the full prefill cost rather than recomputing a prefix the model has already processed.

Adaptive summarization reduces token count by compressing older context — conversation history, retrieved documents — into a shorter representation before including it in the prompt. This is the only strategy that reduces input length at the cost of information fidelity.

Retrieve-then-compress combines retrieval with Context Compression: retrieve the relevant documents first, then compress the retrieved set before passing it to the model. The combination consistently produces substantial token cost reductions in production without measurable quality degradation on the tasks where retrieval quality is already high.

Three Strategies, One Constraint

Sliding Window Attention, prompt caching, and adaptive summarization each solve a different part of the same problem. The architectural mechanism, the serving infrastructure, and the content layer are distinct — and understanding the differences determines where in a system to apply each one.

How do sliding window attention, prompt caching, and adaptive summarization compare as context management strategies?

Sliding window attention solves the compute problem. By bounding the attention span per layer, the model avoids the quadratic cost of full-sequence self-attention during decode. The trade-off is information visibility: tokens that fall outside the current window’s effective receptive field do not contribute to the current prediction. For tasks where relevant information is distributed throughout a long document rather than concentrated near the query, this constraint introduces recall risk that scales with document length.

StreamingLLM (Xiao et al., ICLR 2024) extends the architecture by retaining key-value states for a small set of “sink” tokens from the beginning of the sequence alongside the sliding window. These initial tokens attract disproportionate attention weight regardless of their semantic content — a structural property that emerges from softmax normalization of the attention distribution. Retaining sink token states stabilizes generation past training context length without recomputation, producing up to 22.2× speedup compared to sliding-window recomputation alone (StreamingLLM paper).

Prompt caching solves the repeated prefill problem. Anthropic’s implementation operates on two TTL tiers: 5 minutes (refreshed on each cache hit) and 1 hour for extended caching. A cache write costs 1.25× base input token price at the 5-minute tier and 2× at the 1-hour tier. A cache hit costs 0.10× base input price. The minimum cacheable prefix is 512 tokens for Claude Fable 5 and Mythos 5; 1,024 tokens for Opus 4.8 and Sonnet 4.6; 4,096 tokens for Haiku 4.5, with up to 4 explicit cache breakpoints per request (Anthropic Docs).

One infrastructure note worth flagging: Anthropic changed prompt cache isolation from organization-level to workspace-level on February 5, 2026. Code written against org-scoped cache assumptions may silently miss cache hits after that date (Anthropic Docs).

Adaptive summarization solves the history problem. As conversations and agent sessions extend across dozens of turns, verbatim context accumulates faster than it provides value. The hierarchical memory pattern that dominates agent systems in 2026 tiers context into three zones: Hot (verbatim last approximately 10 turns), Warm (rolling detailed summary for turns roughly 11–40), and Cold (broad compressed history beyond that). Each tier applies different fidelity and cost trade-offs. The transition between tiers is where information loss concentrates — and where failures tend to surface, quietly, much later.

Three-panel diagram comparing sliding window attention local window computation, prompt caching prefix reuse, and Hot-Warm-Cold hierarchical memory for production LLM context management
Three mechanisms at three layers: sliding windows bound attention breadth, prompt caching reuses computed key-value state, and tiered summarization manages history cost.

What 1M Tokens Actually Costs — and Where the Physics Disagrees

Both Claude Fable 5 (1M tokens, released June 9, 2026) and GPT-5.5 (1,050,000 tokens, released April 23, 2026) advertise context windows measured in millions of tokens — and both are accurate. The capability is real; the question production teams encounter is whether filling that capacity is rational, economically or operationally.

What are the technical limits of long context windows in models like Claude Fable 5 and GPT-5.5 in 2026?

Three categories of limits constrain practical use of million-token context windows, independent of the stated token maximum.

Memory limits at the hardware layer. KV cache memory scales linearly with context length; vendors manage this through serving infrastructure rather than through any change to the model’s underlying memory requirements. A full 1M-token prefill is served by provisioning sufficient GPU HBM to hold the resulting key-value tensors — an infrastructure cost the vendor absorbs and passes through per-token pricing.

Accuracy limits at the attention layer. The “Lost in the Middle” phenomenon — established by Liu et al. (2023) at Stanford, Berkeley, and Samaya AI — shows that LLM accuracy drops when critical information appears in the middle of a long context, with strongest recall concentrated at the beginning and end of the sequence (Lost in the Middle paper). The original study examined models with far shorter effective context lengths than contemporary frontier models. Whether Claude Fable 5 or GPT-5.5 exhibit the same U-shaped recall curve across their full 1M-token capacity has not been independently verified in public benchmarks as of June 2026.

Not confirmed at 1M scale. Plausible.

Cost limits at the economics layer. A single call to Claude Fable 5 filling a 1M-token context costs $10 in input tokens alone (Anthropic Docs). The equivalent call to GPT-5.5 costs approximately $5 in input tokens (OpenAI API Docs). For interactive applications making multiple calls per session, these costs accumulate across turns in ways that can make a use case economically inviable without compression and caching discipline.

Anthropic has introduced a context compaction capability (beta, accessed via the compact-2026-01-12 API header) that condenses conversation history into a summary server-side. Because this is beta, its behavior and API contract may change — treat it as an experimental optimization rather than a production dependency.

For LLM Load Testing purposes: profiling across varying context lengths reveals the inflection point where prefill time begins to dominate generation time — typically emerging well before the model’s documented context limit, depending on the serving infrastructure. Production LLM Gateway implementations route requests by context length via Model Routing logic: short contexts go to cost-efficient models; long contexts go to models with appropriate capacity. This prevents paying frontier-model per-token rates for queries that need only a fraction of the available window. When context overflow occurs despite these measures, LLM Fallback And Retry Patterns with truncation or summarization handle graceful degradation.

Rule of thumb: design for the 80th-percentile context length in your workload, then build compression for everything above it.

When it breaks: hierarchical summarization loses fidelity at tier transitions — particularly when entities that evolve over long conversations are compressed into Warm or Cold representations. The model’s view of that entity at generation time reflects the compressed version, not the original, and the discrepancy is silent.

The Data Says

The binding constraint on long context in 2026 is not the token limit — it is the memory physics of KV cache growth, the accuracy uncertainty of middle-context recall, and the economics of per-token pricing at million-token scale. Sliding window attention bounds the computation; prompt caching reuses prefill state; hierarchical summarization compresses what cannot be cached. All three operate at different layers of the same inference stack, and production systems that deploy only one of them tend to rediscover the other two the hard way.

AI-assisted content, human-reviewed. Images AI-generated. Editorial Standards · Our Editors

Share: