The Context Window Is a Systems Boundary
mksglu/context-mode is an open-source MCP server and plugin for AI-assisted engineering. This series examines a specific question about it: how can an agent work with large files, command results, web pages, and long-running session history without pushing every raw byte into the conversation that must still reason about the task? The answer is not simply “write shorter replies.” Context-mode treats the model’s working context as a systems boundary, then moves computation, durable evidence, and session state to the side of that boundary where they can be handled differently.
That reframing matters because a tool call can be successful and still damage the rest of the session. A browser snapshot may contain the page the agent needs, but it may also contain thousands of irrelevant nodes. A list of issues may answer one question while occupying space needed for the next ten decisions. A build command may produce useful errors after hundreds of routine lines. Once such output enters the conversation, it is not only visible; it becomes part of the material the model must carry forward, attend to, and eventually compress.
The project’s README uses concrete examples to make this cost visible: a Playwright snapshot of about 56 KB, twenty GitHub issues of about 59 KB, and an access log of about 45 KB. Its benchmark document reports 376 KB of fixture data reduced to 16.5 KB of context across 21 scenarios, while the README presents a separate 98% product headline and other session examples. Those figures are useful illustrations of the problem and of the project’s intended benefit, not a universal constant. The important point is the accounting distinction: the bytes processed, the bytes stored, and the bytes returned to the model are not automatically the same quantity.
Context is more than a display area
An AI coding session has at least two places where information can live. The first is the conversation itself: the model sees the content directly and can use it immediately. The second is an external working layer: a subprocess, a local index, a database, or another durable store that can be queried when a particular detail becomes relevant. Ordinary tool use tends to collapse those places into one. It returns the raw result, and the model must both process it and remember enough of it to continue.
Context-mode tries to separate those responsibilities. If the agent needs a count, a filter, a parsed structure, or an aggregate, the raw input can remain in a sandbox while code derives the answer. If the agent needs exact documentation or a code example later, the content can be indexed and retrieved by topic. If the conversation is compacted, the state of the work can be recorded and restored as a compact guide with pointers to details. Each path returns something to the model, but each path returns a different kind of thing: a derived result, a selected evidence window, or an actionable reminder.
This is why “compression” alone is an incomplete description. A one-line summary of a document may be small but useless when the next task requires the exact parameter name or code example. Conversely, returning an exact matching section may consume more context than a summary while preserving the information needed to act correctly. Context-mode’s central design choice is therefore not “make every response as short as possible.” It is “decide which information should cross the context boundary, and in what form.”
Consider a repository investigation in which an agent must understand recent issues, compare implementation choices, and then make a change. The first question may be statistical: how many issues mention a particular subsystem, which labels recur, or which files changed most often? Bringing every issue body and every commit into the conversation asks the model to perform two jobs at once: hold the source material and compute over it. A sandboxed program can perform the counting while the conversation receives the result that guides the next decision.
The next question may be documentary rather than statistical. After the count, the agent may need the exact wording of one issue, an API parameter, or a code example from a guide. A terse summary is no longer enough. The useful response is a precisely selected passage, with its source identity and surrounding context intact. In this case, keeping the full source in a local index and retrieving one ranked section is not a failure to compress; it is a way to preserve the evidence that the decision depends on.
A third question may concern the work itself: which file is active, what the user rejected, whether the last build failed, or what remains unfinished after the conversation has been compacted. None of those facts is simply a paragraph in the documentation being searched. They are state about an evolving interaction. They need a separate record that can be summarized into a small operational guide and then queried for detail. This distinction—data memory for sources, work-state memory for the session—explains why context-mode combines an index with lifecycle hooks instead of treating one as a universal replacement for the other.
The boundary is also selective, not absolute. A short git status result or an exact file excerpt may be more useful in the conversation than in an index. A file that must be edited needs its exact bytes on the native read surface. A command that changes the repository should remain a visible mutation, not be hidden behind a computation tool merely because the latter returns less text. Context-mode is most intelligible when it is seen as an owner-and-purpose decision: native tools expose what the agent must directly inspect or mutate, while sandbox and storage paths handle data the agent needs to process or recall selectively.
Four boundaries, one architecture
The first boundary is context saving. The ctx_execute family runs code in a subprocess and returns what the program prints rather than automatically returning everything it reads. ctx_execute_file applies the same idea to a named file: the file is made available inside the execution environment, while the model receives the computation’s output. This is useful when the question is “How many failures are present?” or “Which records match this condition?” It is not the right replacement for an exact read needed to edit a file, because editing requires the precise text on the native surface.
The second boundary is durable knowledge. Context-mode can preserve documentation, API references, logs, JSON, and other material in a local searchable store. The model does not need to carry the whole source to ask a later, narrower question. That store is not a magical second model; it is a mechanism for retaining evidence and locating it. Its usefulness depends on how it divides content, labels sources, ranks matches, and exposes enough of the original material for the next decision.
The third boundary is session continuity. A content index answers “Where is the passage about this topic?” It does not by itself answer “Which file was being edited, what did the user decide, and which error remains unresolved?” Context-mode’s hooks capture events about work, save them locally, and build a resume representation before compaction. The restored representation is meant to re-establish the agent’s operating position without replaying every prior tool response into the new context.
The fourth boundary is routing guidance and enforcement. The project can recognize high-flood paths such as WebFetch, curl/wget output, inline HTTP, or verbose build commands and redirect them toward context-mode tools. It can also use the user’s configured deny rules and, where the host permits it, block or modify a call before execution. These are related but different jobs. A request may be redirected because another tool preserves context; a different request may be denied because it violates a security policy. Treating both messages as the same kind of block would make the agent’s next action less reliable.
The architecture also makes a deliberate negative choice: context-mode does not dictate the model’s final prose style. The repository separates the question of where data goes from the question of how the model explains its answer. Brevity, completeness, structure, and tone remain matters for the model and the user’s own project rules. That separation is part of the subject’s design, not an omission. A system that keeps raw data out of context but then forces every final answer into an aggressive short form could save tokens while dropping assumptions, caveats, verification evidence, or security warnings.
How to judge the promise
The most useful way to read context-mode is to follow data ownership. Ask where the raw bytes are at each step, who is responsible for interpreting them, and what crosses into the model’s active reasoning space. A sandboxed computation may read a large log but return only a count. An indexed source may retain the full document but return a matching section. A session snapshot may mention a pending task and point to searchable history without restating the entire history. These are not interchangeable forms of reduction; they support different kinds of work.
The same discipline applies to the project’s measurements. The repository distinguishes bytes that were kept out of context from bytes that were returned, bytes retrieved from indexed content, and bytes stored as event data for analytics. Its strict per-conversation formula uses the first two categories to represent context transfer and excludes event-storage overhead from that bar. Its lifetime views use a broader storage-oriented accounting. A percentage without its scope can therefore create a false comparison: a lifetime total, a cache hit, an exact search result, and a one-off computed summary describe different experiences.
There is a corresponding operational judgment. Context-mode is most compelling when a workflow repeatedly handles large or structured outputs, needs exact recall later, or runs long enough for compaction to become a real interruption. Its value is less obvious when every result is already short, when the host provides no usable hook or plugin lifecycle, or when the environment cannot accept the security and maintenance responsibilities of arbitrary code execution with network access. The project’s own documentation describes a broad range of host capabilities, but broad support does not mean equal routing, capture, or restore behavior everywhere.
That is the central model for this series. Context-mode is not a smaller chat window, a generic summarizer, or a promise that context costs disappear. It is a set of boundaries around computation, evidence, session state, and policy. The boundaries can extend an agent’s usable reasoning space, but they also create choices about freshness, fidelity, security, host integration, and measurement. The next step is to examine the first boundary directly: how context-mode turns raw output into deliberate computation while preserving the distinction between observing exact bytes and deriving an answer from them.