Context protection
The four layers that keep raw data out of the context window.
Think in Code is the principle; context protection is the machinery that enforces it. context-mode keeps raw data out of the window with four layers that stack — a tool call passes through each one, and only a small, relevant result survives to the model.
| Layer | What it does | What reaches the model |
|---|---|---|
| 1 — Sandboxed execution | Runs your code in a subprocess | Only what you print to stdout |
| 2 — Intent-driven filtering | Indexes large output, returns intent matches | The ranked sections you asked for |
| 3 — FTS5 knowledge base | Stores indexed content, queried on demand | Ranked snippets from ctx_search |
| 4 — Session continuity | Persists events in SQLite across compaction | A rebuilt state, not re-injected raw context |
Layer 1 — Sandboxed execution
Your code runs in a subprocess, not in the conversation. This is the floor the other layers build on: nothing enters the window unless you explicitly print it.
- The model can read gigabytes of files, query a database, or shell out to a build — and none of it touches context.
- Only what the program prints to stdout returns.
Layer 2 — Intent-driven filtering
Sometimes the print itself is large. When output is sizeable, pass an intent
string describing what you are actually looking for.
- Output over about 5 KB is automatically indexed.
- Only the sections that match your intent return to the model — ranked by the same BM25/full-text engine the knowledge base uses, not by embeddings.
- The rest stays in the knowledge base, retrievable later with
ctx_search— so a verbose command still yields a focused answer.
ctx_execute({
language: "shell",
code: "npm test 2>&1",
intent: "failing test names and the assertion that broke",
})The full test output is captured and indexed. Only the failures that match the intent come back; if you later need a passing case or a timing number, you search for it instead of paying for it up front.
Layer 3 — FTS5 knowledge base
Indexed content lives in a local FTS5 store with BM25 ranking and never enters context on its own.
- You query it on demand with
ctx_search, which returns ranked snippets rather than whole documents. - Everything you have already executed, fetched, or indexed becomes searchable — without re-reading any of it.
Layer 4 — Session continuity across compaction
Events persist in SQLite, so the working state survives a window reset.
- When a session is compacted or resumed, context-mode rebuilds what it knows from the store instead of re-injecting raw context.
- The history stays searchable; the window stays clean.
How the layers compose
A single data-heavy command flows through all four:
Run in the sandbox
The command executes in a subprocess (layer 1), so its raw bytes never touch context.
Filter by intent and index
Large output is filtered by your intent and indexed (layer 2), returning only the matching sections.
Search on demand
The index backs on-demand search (layer 3), so anything filtered out is still
retrievable with ctx_search.
Outlive compaction
The record persists in SQLite and outlives compaction (layer 4), keeping the state searchable across a window reset.
The net effect is the roughly 95-99% context saving context-mode is built to deliver.