Researchers from Mila and Google have published Proteus, a scheduling mechanism that improves how fixed-size memory states handle long contexts in recurrent models. The work teams Mila's Reza Bayat and Aaron Courville with Google's Ali Behrouz and Vahab Mirrokni—co-authors of the Titans and Hope-Attention architectures that Proteus modifies.

Attention's O(n²) cost has driven adoption of recurrent models with fixed hidden states where per-token cost stays constant and total compute scales linearly. But a structural problem remains: early tokens arrive to nearly empty state and face no compression pressure. They monopolize degrees of freedom. Later tokens—the ones that matter in long-context tasks like retrieval over 100k documents or agent memory—compete for what remains and get overwritten. Memory skews toward the sequence start.

Proteus schedules capacity by dividing memory into blocks that unlock progressively as the sequence grows. At each position, the model reads and writes only to currently activated blocks and previously activated ones. Early compression happens aggressively. As context lengthens, new blocks unlock with fresh capacity, preserving earlier summaries. The approach adds no parameters and no additional FLOPs.

PropertyStatic Fixed MemoryProteus Block Scheduling
Memory availabilityAll capacity open from token 1Blocks unlock progressively as sequence grows
Early-token behaviorMonopolizes state degrees of freedomForced into aggressive early compression
Late-token behaviorCompetes for remaining capacity; risks overwriteGets fresh capacity from newly unlocked blocks
Earlier summariesCan be overwritten by later tokensPreserved as new blocks absorb new content
Added parameters—None
Added FLOPs—None
FIG. 02 Static fixed-memory allocation vs. Proteus block scheduling — key behavioral differences — Proteus paper (Bayat et al., Mila / Google)

Testing on four architectures—SWLA (Sliding Window Linear Attention), Comba, Titans, and Hope-Attention—showed consistent improvements on language modeling perplexity, commonsense reasoning, long-context retrieval, and document understanding. Benefits scale with context length. Production workloads benefit most where expensive cases are most common.

Architectures and task categories covered in Proteus evaluation
FIG. 03 Architectures and task categories covered in Proteus evaluation — Proteus paper (Bayat et al., Mila / Google)

Long-context inference today hits hard limits. At 32K context, Llama 3.1 8B in FP16 requires 4.0 GB of KV cache. At 128K context, that reaches 16.0 GB. Linear scaling suggests 1 million tokens would need roughly 122 GB—well beyond a single 80 GB GPU. Recurrent alternatives avoid this KV cache growth entirely, but have historically underperformed on retrieval-heavy tasks due to early-token pollution. A mechanism that improves retrieval quality with zero compute overhead appeals to anyone weighing a switch away from attention-based serving.

KV cache memory for Llama 3.1 8B (FP16) grows linearly with context length, exceeding a single 80 GB GPU at ~1M tokens
FIG. 04 KV cache memory for Llama 3.1 8B (FP16) grows linearly with context length, exceeding a single 80 GB GPU at ~1M tokens — Article body; lyceum.technology KV cache memory calculation

The paper offers no code release yet. Benchmark numbers appear in the Proteus paper itself, which reports consistent gains across all four tested architectures. The core insight—that static memory allocation is suboptimal and scheduling block activation works broadly—can drop into any recurrent baseline already in production.

If your inference stack runs SWLA, Comba, Titans, or Hope-Attention on longer-context workloads, Proteus is a zero-cost modifier worth testing before adding memory or hardware.