Context Mode: An MCP Server That Keeps Tool Output Out of the Context Window
Context window optimization for AI coding agents. Sandboxes tool output (98% reduction), persists session memory, and enforces routing across 17 platforms via MCP + hooks.
At a glance
- What is it?
- Context Mode is a TypeScript MCP server plus hook layer that sandboxes tool output, persists session events in SQLite with FTS5 retrieval, and pushes agents to write analysis scripts instead of reading files into context. The mechanism is sound; the licence and the platform matrix are where you need to slow down.
- Who is it for?
- Adopt Context Mode if you run long agent sessions against noisy tools (Playwright snapshots, GitHub issue fetches, access logs) inside a hook-capable client such as Claude Code, and you accept ELv2 terms plus a fast-moving release cadence. Do not adopt it if your client has no hook support and you are unwilling to copy a routing file by hand, or if you need an OSI-approved licence for redistribution.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The four context leaks Context Mode is built to plug
The README frames the problem in numbers. A Playwright snapshot costs 56 KB. Twenty GitHub issues cost 59 KB. One access log costs 45 KB. The claim is that after 30 minutes, 40% of the context window is gone. Alongside that, conversation compaction discards working state: which files were being edited, which tasks are in progress, what the user last asked for. A third leak is on the output side, where the agent burns tokens on pleasantries and verbose explanation.
The project positions itself as the other half of the context problem, meaning it does not try to make the model write more concisely. The README is explicit that context-mode keeps raw data out of context but never dictates how the model writes its final answer, and it cites a Moonshot AI note about kimi-k2.5 in an opencode issue to argue that aggressive brevity prompts degrade coding and reasoning benchmarks. That is a defensible split: routing decisions are mechanical and enforceable, writing style is not. The audience is anyone running an agent that calls MCP tools returning large payloads, which in practice means people using Playwright, GitHub, or log-reading tools inside Claude Code, Cursor, Codex or one of the other listed clients.
Sandboxed tools, SQLite plus FTS5, and the think-in-code rule
Three mechanisms sit under the four claims. The first is sandboxing: tool output is intercepted and kept out of the context window, with the README giving 315 KB becoming 5.4 KB as its headline reduction. The second is session continuity. Every file edit, git operation, task, error and user decision is tracked in SQLite. On compaction, the project does not dump that history back into context. It indexes events into FTS5 and retrieves only relevant rows via BM25 search. That is a retrieval layer over an append-only event log, and it is the part of the design that is easiest to get wrong in a way users will notice, because a BM25 query that misses an event looks identical to an event that was never recorded.
The third mechanism is the one the README calls mandatory: think in code. The agent writes a script that performs the analysis and logs only the result, rather than reading files into context to reason over them. The example given is a JavaScript snippet passed to ctx_execute that reads every .ts file in src and prints a line count per file, replacing what the README estimates as 47 Read calls at 700 KB with one call at 3.6 KB. Whether that ratio holds depends entirely on the task; a one-file lookup gains nothing from being turned into a script. The routing block is described as staying focused on where data goes, not how the model talks, which is a narrower mandate than the surrounding copy might suggest.
Install paths differ sharply by client
The README groups platforms by install complexity and states the rule plainly: hook-capable platforms get automatic routing enforcement, non-hook platforms need a one-time routing file copy. Claude Code is documented as a plugin marketplace install that is fully automatic, with a stated prerequisite of Claude Code v1.0.33 or later, checkable with claude --version. The project lists 17 supported clients across its topics, including Claude Code, Codex, Cursor, Zed, Copilot, Kiro and opencode, plus what it calls an OpenClaw gateway integration.
That grouping is the single most important thing to check before you start, because the difference between the two groups is not cosmetic. On a hook-capable client, routing enforcement happens without you doing anything after install. On a non-hook client, you copy a routing file once, and if that file drifts out of date after an upgrade, the enforcement silently stops applying. The README does not enumerate which of the 17 clients fall into which group in the material available here, so treat that as something to confirm on the project's own install page rather than assume from the client name.
The 98% number is a property of sandboxed tools, not your session
The headline reduction is easy to misread. It describes what happens to the output of tools that go through the sandbox. It does not describe your whole context window, and it does not apply to anything the agent reads directly. If your workflow is mostly a few small file reads and short shell commands, the sandbox has little to intercept and the percentage is meaningless for you.
The session memory has a sharper edge. The README states that if you do not pass --continue, previous session data is deleted immediately, and calls this a fresh session meaning a clean slate. That is a deliberate design choice, not a bug, but it inverts the usual expectation. Most tools accumulate history until you clear it. Here, forgetting is the default and continuity is opt-in per invocation. Anyone who installs the server, works for an hour, closes the terminal, and reopens expecting the SQLite event log to still be there will be surprised. There is also no discussion in the supplied material of what happens to the SQLite file itself on disk, how large it grows over a long session, or how to inspect or prune it.
Where a plain MCP filesystem server is the better answer
The obvious alternative is to run no context-management layer at all and use a standard MCP filesystem or shell server, accepting that tool output lands in the context window and relying on the client's own compaction. The difference in approach is not a matter of degree. A standard MCP server is transparent: what the tool returns is what the model sees, and you can reason about the context budget by counting tool calls. Context Mode inserts a retrieval layer between the tool and the model, which buys you a smaller window but costs you direct inspection. When a sandboxed result looks wrong, you are now debugging two things: the tool and the routing.
For short sessions, one-off questions, or work where the tool output is the thing you actually want the model to read in full, that trade is bad. The think-in-code rule makes it worse for those cases, because it asks the agent to write a script to answer a question it could have answered by reading one file. Context Mode is for the opposite shape of work: long sessions, repeated tool calls, large payloads, and a real cost to losing working state at compaction. If your sessions are ten minutes long, a plain filesystem server is simpler and has fewer moving parts to misconfigure.
Licence, release cadence and what you are signing up to maintain
The repository metadata reports the licence as NOASSERTION while the README badge says ELv2, the Elastic License 2.0. Those two signals disagree, and the discrepancy matters more than usual here because ELv2 is not an OSI-approved open source licence. It permits most internal use but restricts providing the software as a hosted or managed service and removing licence notices. The project describes itself as used across teams at a long list of large companies, rendered as badges with no links, which is a marketing claim rather than a verifiable one; the supplied material gives no evidence behind it. If you need to redistribute Context Mode inside a product, read the LICENSE file yourself rather than the badge. This is not legal advice.
The release history shows v1.0.169 on 2026-06-29, v1.0.168 on 2026-06-26 and v1.0.167 on 2026-06-26, with the repository's last push dated 2026-09-10. Three patch releases in four days, all within the same minor version, tells you the project ships fixes continuously and that pinning a version is the only way to get a stable surface. Because the routing file on non-hook clients is copied rather than installed by a package manager, an upgrade is a two-step operation: update the package, then re-copy the routing file. Skipping the second step is the most likely way to end up with a setup that looks installed and is not enforcing anything.
Editorial conclusion
Adopt Context Mode if you run long agent sessions against noisy tools (Playwright snapshots, GitHub issue fetches, access logs) inside a hook-capable client such as Claude Code, and you accept ELv2 terms plus a fast-moving release cadence. Do not adopt it if your client has no hook support and you are unwilling to copy a routing file by hand, or if you need an OSI-approved licence for redistribution. Before installing, confirm three things: your client version meets the stated minimum, whether you will pass --continue (without it the previous session's data is deleted), and which tools you are willing to route through the sandbox, since the 98% figure is a property of the sandboxed tools, not of your whole session.
Community notes