The Architecture of Forgetting

Language models have no memory. What looks like recollection is a reconstruction at every call. A comparative analysis of how six agentic CLIs solve the problem of a scarce working memory architecturally, with precise thresholds and verifiable citations from the respective codebases.

FC
· 19 min read

Language models appear to their users like collegial conversation partners: they reply in the first person, refer back to earlier statements, seem to understand code and grasp intentions. This effect is a carefully constructed illusion. Technically a language model has no memory. It has a context, which its surrounding application retransmits in full at every call, and the continuity of a session comes from nothing but the application handing over the entire conversation again at every step.

This architecture has a consequence that only emerges in productive use. The context window becomes the system’s scarcest resource once a language model moves out of the editor chat into a command line and starts processing tasks for hours on end. The agentic command-line tools of the major vendors all answer the same technical question: how do you manage a scarce, transient working memory in such a way that a longer session remains productive? Six tools are meant: Claude Code by Anthropic, Codex CLI by OpenAI, Google’s Gemini CLI, Alibaba’s Qwen Code, OpenCode from the open-source community and GitHub’s Copilot CLI. Five of the six codebases are openly accessible thanks to open-source licences, and reading them side by side turns up the same four solution patterns everywhere, along with five axes on which the design decisions do diverge after all.

What limits the context window

All six vendors operate under the same constraints, which follow from the architecture of the underlying transformer models and are extensively documented in the research literature.

Hard-limited. One million tokens, the equivalent of around 750,000 English words, has become the new standard in the current top-tier models. Anthropic made the million-token window generally available for Claude Opus 4.6 and Sonnet 4.6 in March 2026. Claude Code users on Max, Team and Enterprise plans get it as the default without any configuration. OpenAI offers the million in GPT-5.5, capped at 400,000 tokens inside the Codex CLI. Google delivers it in Gemini 2.5 Pro, Alibaba in Qwen 3.5-Plus. Older and smaller models such as Claude Sonnet 4.5 remain at 200,000 tokens, which had been the industry standard up to 2025. Even with these enlarged windows, the attention operation of the transformer architecture scales quadratically with sequence length: twice the context means four times the compute. Sparse attention and state-space approaches dampen this effect but do not eliminate it, and a single token beyond the hard limit makes the API call fail, because nothing can be added at runtime.

Transient and stateless. At every single model call the application retransmits the entire previous history: system prompt, all messages, all tool calls and all tool results. Vendor-side prompt caching, which stores stable prefixes of the conversation, reduces the cost of repeated transmissions substantially. Anthropic charges cache reads at one tenth of the regular input price. OpenAI automatically grants a fifty-percent discount on reused input tokens, newer models in some cases more. None of this changes the underlying mechanism. The impression of memory still comes from organised repetition.

Ageing. Long before the hard limit, response quality declines. The term context rot was coined in 2025 by a technical report from Chroma Research for exactly this phenomenon. The authors tested 18 frontier models, including GPT-4.1, Claude Opus 4 and Gemini 2.5, and observed the effect in every single one. Anthropic has since adopted the term in its own documentation, and the Best Practices for Claude Code put the onset range for its million-token models at 300,000 to 400,000 tokens, around thirty to forty percent fill. The LoCoMo benchmark by Snap Research covers conversations averaging 9,000 tokens across up to 35 sessions. Empirical evaluations on it show across model families that even long-context LLMs trail human performance by a wide margin once the session grows long. A larger window shifts the problem in time without solving it.

The model’s attention spreads across more tokens, and old ballast pulls it away from the current focus. The model then grows more likely to ignore relevant instructions, which research calls instruction omission, the silent dropping of instructions without the model flagging it. A 2025 paper by Distyl AI shows that even the best frontier models tested reach only around 68 percent accuracy at 500 simultaneous instructions. The instructions fit easily into the window, the model sees them and still does not follow them all.

From these three properties follows a technical necessity. An agentic CLI must actively manage its context: compress older content, discard irrelevant tool outputs, offload important findings into durable files, reconstruct exactly what is relevant before each new task. What this means on the user’s side is covered in the field report on context management. How the six tools do this in detail is the actual subject of this comparison.

What all six tools solve the same way

The six codebases agree in four places, although programming languages, vendors and design philosophies pull apart. The convergence results from the same constraints, which force all vendors to explore the same solution space.

One shared pattern is selection over completeness. None of the tools examined copies files indiscriminately into the context. Each decides which instruction files it loads, which tool results it keeps, which memory layers are active. Selection is the front line of defence against context rot. Gemini CLI, for one, classifies read-in files into four tiers labelled internally as FULL, PARTIAL, SUMMARY and EXCLUDED, and decides per file how much of it lands in the context. Claude Code, during its micro-compaction, selectively clears old tool results without touching the conversation itself.

Just as widespread is the hierarchical discovery of instruction files. All six CLIs search for their project rules on the path from the project root down to the current working directory, whether those rules are called CLAUDE.md, AGENTS.md, GEMINI.md, QWEN.md or copilot-instructions.md. More specific rules in submodules override the more general ones. Anyone working in a monorepo automatically gets the appropriate rule set. This consensus holds across the whole industry and goes back to no single vendor. A flat, project-wide rules file would be too coarse-grained for large codebases.

Then there is the prioritisation of user content over tool output. When context gets tight, all tools discard old tool results first and keep the user’s messages. What a user has written expresses intent. A tool output can be regenerated when needed by invoking the tool again, a user message cannot, because it is an authentic part of the session.

The last of the four is structured re-anchoring after compaction. Afterwards the tool explicitly appends important state data to the new context: file attachments, the active plan, enabled tools, connections to external services and hook outputs from the session start. What comes out of it is a reconstructed working picture. Claude Code is particularly pronounced here. After every compaction it reattaches file attachments, plan-mode state, active skills, and tool and agent deltas.

Together, these four patterns form an informal pattern language for context management. The terms trim, summarise, persist and prune capture their operations. Anyone who can name them can assess a new tool within minutes. They are to context management what design patterns were to object orientation: a vocabulary.

Where the six tools differ

Despite the convergence, clear differences remain. Five axes are particularly consequential for tool choice. The values given can be verified by reading the source code.

Compaction thresholds: Gemini CLI at 50, Codex at 90 percent

This axis is measured by the threshold at which the tool triggers a compaction, expressed as a fill rate of the context window. The values lie far apart: Gemini CLI starts early, at fifty percent fill, while Qwen Code, which is built on a fork of the Gemini codebase, waits until seventy percent. Copilot CLI splits the task across two thresholds: at eighty percent an asynchronous compaction runs in the background. At ninety-five percent a blocking emergency brake holds the call until the compression is complete. Codex waits until ninety percent of the configured context window. Codex does allow the automatic token limit to be configured explicitly per model, but internally clamps the value to a maximum of ninety percent of the context window. Claude Code operates without a fixed percentage trigger. Several overlapping layers run there instead, whose depth of intervention ranges from surgical to complete.

Every threshold is a compromise. Compacting early costs additional LLM calls, since the summarisation is itself a model invocation, while late intervention lives longer in the context-rot zone and risks quality loss shortly before it. The choice between fifty and ninety-five percent is a choice between token economy and response stability.

Memory: a Markdown file in Claude Code, SQLite in Copilot CLI

The spectrum spans a wide range. OpenCode dispenses with persistent memory entirely. Whatever a session has produced lives on only in the files the user explicitly creates. Claude Code, Codex, Gemini and Qwen each use a flat Markdown file at a defined path: Claude Code under ~/.claude/.../memory/, Codex in a directory called memories, Gemini and Qwen in a project- or user-wide GEMINI.md or QWEN.md. Copilot CLI, by contrast, runs two SQLite databases in the background, combines them with vector embeddings and full-text search, and makes persistent memory a dedicated session capability with structured permission requests. Every memory write there passes through a permission gate that requires three fields: subject, fact and citations. Memory at Copilot is thus a record separated by topic, fact and provenance.

The range runs from the absence of a memory system to a fully fledged retrieval system with provenance fields. That is the clearest difference in the comparison. Anyone who only needs memory as a note in the repository has five tools to choose from, for memory as a queryable database across many sessions exactly one remains.

Sub-agents: delegation in Claude Code, a fleet dispatcher in Copilot CLI

Sub-agents serve to isolate context. The main agent delegates a sub-task to a child agent with its own window, which expires once the task is complete. This protects the main context from bloating, because the detailed knowledge of the sub-task does not flow back into the main conversation. Only the result returns. Claude Code provides a simple delegation tool here. Copilot CLI runs a fleet dispatcher that orchestrates parallel sub-agents, together with a dedicated smaller sub-agent model and explicit depth limits that prevent a task from recursing indefinitely. Codex uses sub-agents among other things for memory consolidation in a dedicated phase after session end. OpenCode and Qwen are sparsely equipped on this axis.

Observability: structured events and OpenTelemetry in Copilot CLI

One of the biggest differences sits on this axis. Copilot CLI emits structured events such as session.compaction_start and session.compaction_complete, supports OpenTelemetry and offers a preCompact hook for external observers. Every compaction can thus be measured, logged and audited. The event structure includes the token counts before and after the compression, the number of removed messages, the generated summary and the GitHub request trace. Anyone integrating a tool into productive pipelines or having to maintain audit trails depends on this kind of infrastructure. The other tools offer far less here.

Hooks and extension points in Claude Code and Copilot CLI

Hook points such as sessionStart, preToolUse, subagentStart or preCompact turn a closed tool into a platform. They are the modern form of extension points and let teams hang their own governance, validation and logic into the agent loop. Claude Code and Copilot CLI are the richest equipped here. Codex offers specific but less orchestrable extension points. Gemini, Qwen and OpenCode remain more sparing. They leave extensions largely to the configuration mechanism, and an event-based model is scarcely present there.

The six tools in detail

With the four patterns and five axes, each individual CLI can be characterised.

Claude Code: compaction in four layers

Claude Code treats compaction as a gradient with four layers that differ in their depth of intervention. At the lowest layer, a micro-compaction replaces individual older tool results with a placeholder text. It is surgical, leaves the conversation untouched and runs continuously during the session. Above it, a layer cuts individual older message blocks when needed, before the micro-compaction operates. As a further layer, session-memory compaction runs as a post-sampling hook after every model response, extracting memory entries from the session and storing them in a dedicated file. The deepest layer is the classic, complete compaction with subsequent rehydration of all state data. This architecture is the most elastic of the six and simultaneously the one with the highest internal complexity. It follows the idea that compaction should be a family of staggered interventions.

Codex: a 90 percent threshold and a protected user window

Codex treats the session as a cleanly defined state space. Automatic compaction kicks in at ninety percent of the context window. The user window holding the most recent portion of the conversation is preserved with 20,000 tokens so that the current working context stays protected. The memory system is built as a separate subsystem. Codex routes memory entries through a dedicated trace-summarisation endpoint to a sub-agent which, in a dedicated phase after the session ends, consolidates them into durable memory files. Reproducibility is the clearly visible design goal: initial context, compaction boundary and memory operations are all explicit and traceable.

Gemini CLI: a separate utility model for compression

Gemini CLI distributes the task across four specialised services that work together and affords itself a dedicated utility model that produces the summaries. This model goes internally by the name chat-compression-2.5-flash-lite. It is a smaller, cheaper variant of the main model and exclusively handles compression. With this, Gemini comes closest to the separation of memory operations from the main model recommended by research. Compaction begins aggressively at fifty percent fill, which generates extra LLM calls but keeps the main model well below the context-rot zone.

Qwen Code: a Gemini fork with a higher threshold

Qwen Code is a fork of Gemini CLI by Alibaba. The codebase inherits large parts of the Gemini logic. The compaction threshold is, however, set higher at seventy percent, and the compressor sits at a different point in the pipeline. A closer look shows that the compression bypasses the memory path that Gemini routinely traverses. The result is a modern architecture with an internal break in integration: what Gemini cleanly separates is brought together again in Qwen at one point.

OpenCode: overflow management without persistent memory

OpenCode understands itself as a janitor tool. It runs strong overflow management with a 20,000-token buffer and no fixed percentage threshold: compaction triggers when the context is actually about to overflow. Instruction files are loaded lazily. The code is flat and hierarchically organised, the overflow logic transparent and easy to follow. A persistent memory system is entirely absent. Anyone who prioritises simplicity and traceability finds the lowest complexity here.

Copilot CLI: SQLite memory, fleet dispatcher and hooks

Copilot CLI is of all six tools the closest to what research papers from 2025 and 2026 demand. Compaction runs two-stage, asynchronously at eighty percent and blocking at ninety-five percent. Persistent memory is managed across multiple sessions in two SQLite databases with vector embeddings and full-text search. Memory writes are permission-controlled and carry their own provenance field, documenting the sources of the stored fact. Sub-agents are dispatched in parallel through a fleet dispatcher. Compaction emits structured events with extensive metrics. A hook system allows external logic to be injected before and after every compaction. The price of this richness: the core is closed source. Only the SDK is publicly accessible. The central algorithms can however be inferred from the freely available SDK code and the documented telemetry, since the default thresholds and the event structure of the compaction are published there as a typed interface.

Memory subsystems: Markdown file or SQLite database

The memory subsystem is where the architectures diverge most strongly, and at the same time where the largest research gap lies.

Four of the six tools store memory as a Markdown file. Claude Code, Codex, Gemini and Qwen follow this path. The advantage is obvious: Markdown is human-readable, versionable and can be placed in the repository. A developer can read memory entries in a normal text editor, track them in git and review them in a pull request. Against this stands a disadvantage: a flat file is not a queryable system. Whoever wants to know what was decided about the authentication module two weeks ago has to either read the file themselves or throw its entire contents back into the agent’s context.

OpenCode dispenses with any persistent memory system. This is a conscious design decision. Anyone needing memory creates their own Markdown files in the repository and refers to them from the prompt. Every session therefore starts with whatever is documented in the repository, since the tool stores nothing internally. This clarity has its price: there is no automatically built-up learning curve across sessions.

Copilot CLI takes the opposite route and implements a full memory subsystem. Two SQLite databases store content and embeddings separately, full-text search allows classic keyword queries, and vector embeddings allow semantic similarity searches. Memory is written or voted on through structured permission requests. At every write the three fields subject, fact and citations must be present. This is closer to the demands of the research literature, particularly to works such as MemInsight and CDMem, than any of the other tools examined.

That said, even this system is not the state of the art. Cross-session memory is, according to the documentation, explicitly experimental. Intent-driven retrieval is missing, that is, the selection of memory entries on the basis of the current task intent. Retrieval runs over paths, namespaces and semantic similarity, without goal states. Causal and temporal structures between memory entries are limited to timestamps. There is no explicit event graph.

Sub-agents for context isolation in Claude Code and Copilot CLI

Alongside memory, sub-agents are the other large field of architectural difference. The basic idea is simple: the main agent hands a sub-task to a child agent so that it does not burden the main window. The child agent starts with an empty window, completes the task and returns only the result. Intermediate dialogue, tool calls and detailed research are spared from the main context.

Claude Code provides a simple delegation tool for this. The main agent can hand a task to a sub-agent that operates in the same model with its own context. This is conceptually clean and practically useful, especially for research tasks in large codebases. Parallel Claude sessions can also send each other messages and coordinate their work on a codebase that way.

Copilot CLI has the most extensive build-out. A fleet dispatcher can start sub-agents in parallel, a dedicated smaller model handles the sub-agent work at lower cost, and explicit depth limits prevent endless recursions. This brings the architecture close to the patterns discussed in research as hierarchical multi-agent systems.

Codex uses sub-agents primarily for memory consolidation, which runs in a dedicated phase after session end. This separation between session sub-agents and consolidation sub-agents is architecturally interesting: memory operations are taken off the hot path and handled asynchronously. This lowers session latency but shifts the memory update in time.

Gemini, Qwen and OpenCode offer less on sub-agents. Sub-agents exist, but they are neither the defining design principle as in Copilot nor the deeply integrated tool as in Claude Code.

State of research and the frontier gap

As far as the six tools have come, they all trail what academic research has put forward in concepts over the past eighteen months. Works such as MemoryOS (Oral at EMNLP 2025), HiAgent (ACL 2025), LightMem (ICLR 2026) and Mnemis (accepted at ACL 2026, from Microsoft Research) sketch a next generation of memory architectures that differ from today’s CLI implementations in four respects. The papers call for:

Today’s CLIs implement fragments of this. Tool outputs are sacrificed before user prose because they are reproducible. That is an efficiency feature the research praises. Memory is written selectively. Copilot stores provenance fields, the others do not. A real intent-driven retrieval logic does not exist in any of the tools. Causal structures are entirely absent. On the economic efficiency of context management the CLIs are far along. On its depth they are at the beginning.

The survey “Memory in the Age of AI Agents”, published on arXiv in December 2025 with 47 authors, reaches a similar conclusion. Traditional taxonomies such as the distinction between long-term and short-term memory, it argues, are insufficient for modern agent memory systems, and multi-session consistency across hours and days is considered largely unsolved. Selective forgetting is described as the hardest of the open problems. Even Mnemis, one of the currently best-placed systems, achieves 93.9 out of 100 points on the LoCoMo benchmark with GPT-4.1-mini and 91.6 on LongMemEval-S. The paper explicitly claims no comprehensive solution and documents its limits transparently.

Consequences for tool choice

“Which CLI is the best?” is the wrong question, a universal answer does not exist, and a tool is only ever suitable for particular requirements. Anyone working in a CI/CD pipeline will favour Copilot for its observability or Codex for its reproducibility, while for interactive, heavily configured work Claude Code offers the greatest flexibility. For interactive, heavily configured development, Claude Code offers the greatest flexibility. For memory as a queryable database across many projects there is exactly one choice. OpenCode is the tool for those who value simplicity above all.

The pattern language is useful beyond this comparison. Anyone who has internalised trim, summarise, persist and prune, along with hierarchical discovery, sub-agent isolation, post-compact rehydration and hook-based extension, reads the relevant code paths of the next tool on the market and needs no demo video for it. The vocabulary outlives the individual implementations.

Most uncomfortable for vendors and users alike: even the best memory system does not replace structured planning of the work itself. The tools deliver the mechanics. What is to be built, in which order, and by what criteria for acceptance is still decided by a human.

That leaves the gap between research and implementation. It is an opportunity. The next generation of CLIs will be decided by which vendors first bring intent-sensitive retrieval, causal-temporal memory structures and learning policies into productive form. The main model will not be the deciding factor. Anyone choosing today should factor in that this field will look different in two years, without the pattern language presented here becoming obsolete.

The problem of a scarce, transient working memory cannot be solved by larger models. It is structural and follows from the architecture of the transformer. Anyone working productively with agentic tools will have to treat context management as a discipline of its own, comparable to memory management in classical systems programming. The six CLIs examined here show that the industry has discovered this discipline, and at the same time how many paths remain open for mastering it.

AI Agentic Coding Software Engineering Architecture Claude Code Copilot