You Never Manage the Context Window
Short answer: managing the context window is placement work — deciding which facts are resident this turn and which cached bytes stay warm — and placement work belongs to a kernel, not to the person or agent using it. fak’s default path already does a large slice of it automatically. This page is precise about which slice is live today and which is still a referee-only measurement, because the honest version is the one worth citing.
The window is the agent era’s physical RAM
Programmers used to manage physical memory by hand: overlays, segment registers, “keep this routine under 4K so it fits.” The MMU and demand paging made physical placement invisible; allocators and garbage collection made even allocation invisible. Today nobody manages RAM — they couldn’t if they wanted to, and the programs are better for it.
The context window is the same resource one abstraction layer up, and in 2026 everyone is back to writing overlay code by hand:
- humans decide when to
/compact,/clear, or start a fresh session; - humans diet their
CLAUDE.mdand memory files so the base context stays small; - agents are instructed by their own harness prompts not to read large files because “it will overflow your context”;
- agents fan out subagents whose only real purpose is protecting the parent window,
and hand-write
HANDOFF.mdbatons when a session dies of length; - operators place cache breakpoints, pick 5-minute-vs-1-hour TTLs, and keep prefixes byte-stable by discipline instead of by mechanism.
Every one of those is a manual overlay — a human or agent doing placement work a kernel should own. The doctrine, in its falsifiable form:
A user- or agent-facing instruction, habit, flag, or skill whose only purpose is context management is a defect. Count them; drive the count toward zero. The knobs may survive as operator/debug surfaces; the default path must never require one.
“Nobody manages the window” is a product property, like “no bad tool call gets in” (the capability floor) and “no good value silently gets lost” (context safety). It is checkable: enumerate the manual overlays and watch the counter.
Residency and warmth are two projections of one thing
The user side of context is residency: which tokens are in the rendered window this turn. The server side is warmth: which bytes are warm in which cache — provider prompt cache, in-kernel KV prefix, engine radix tree, disk CAS. These are not two problems. They are two projections of one placement problem over one address space:
- Every fact in a session is a cell with an address (fak already has the
addresses:
ctxplan’s lossless store,recall’s session-as-core-dump CAS,cachemeta’s tiered entries). - The window is a rendered view of some cells (the residency projection).
- A cache line is a warm copy of some cells (the warmth projection).
- Every residency action has a warmth price, and vice versa. A page-out that rewrites the middle of the prefix busts the provider cache from that point; the compaction shed is only near-free because it is suffix-shaped and byte-splices the protected prefix verbatim. Upgrading a cache TTL changes the break-even for keeping a long prefix resident at all.
The rule that falls out: one placement decision, one ledger. No residency change ships without its warmth price, and exactly one context manager owns any given wire — everything else is sensed and made coherent, or suppressed.
Self-management is a control hierarchy, not a model free-for-all
Self-managed context means the user chooses the task and constraints, while the
system owns routine placement. It is a first-class runtime property, not a collection
of reminders to /compact, avoid large files, or manually curate memory. A complete
implementation has three control levels, in this order:
- Kernel and harness policy acts deterministically. Typed rules admit, defer, pin, page, summarize, invalidate, and restore context from observable state. The same inputs and policy produce the same decision and a receipt explains it. Safe maintenance runs without asking the user or spending a model call.
- The agent adjusts bounded controls and asks for context. When task semantics matter, the agent may set declared knobs (for example, pin a goal, release a span, select a retrieval scope, or request a query) and invoke context tools. Those actions change policy inputs; they do not bypass budgets, provenance, capability boundaries, or restore guarantees.
- A model resolves only the semantic residue. Classification, synthesis, or compression may use a model when deterministic evidence cannot decide what remains useful. The call is bounded, typed, attributable, and checked before its result can replace source context. Failure falls back to a safe deterministic action rather than silently dropping evidence.
This hierarchy keeps the useful middle ground: an agent can update configuration or run retrieval tools as part of doing its job, but the harness still owns enforcement and the kernel still prefers replayable mechanisms. “The agent manages its context” is therefore not permission for an unconstrained housekeeping loop inside the same window it is trying to repair.
The placement loop is one structural object
Treat context management as a closed control loop rather than separate compaction, memory, retrieval, and cache features:
- Sense: record token pressure, cache warmth, reuse, provenance, tool-result size, goal relevance, dependency edges, and restore cost.
- Plan: compute a typed placement plan across resident, deferred, summarized, indexed, pinned, invalidated, and restorable states.
- Act: apply deterministic transitions first; request bounded agent configuration, tool queries, or model judgment only where the plan names semantic uncertainty.
- Verify: check invariants, task outcome, retrieval success, cache effects, latency, and total billed work against the unmanaged alternative.
- Learn safely: RSI may propose policy or threshold changes from receipts and benchmark history, but replay, holdout, regression, and rollback gates decide whether a proposal becomes configuration. The online model never rewrites its own safety floor.
The receipt is the integration seam. Native harnesses should expose lifecycle events, context controls, and compaction boundaries; tools and memory systems should return provenance plus budget metadata; providers should expose cache and usage signals. fak can then make one placement decision instead of stacking several opaque summarizers.
What evidence would prove the property
A token-count reduction alone does not prove self-management. Benchmarks need paired, replayable trajectories and must report at least:
- user burden: manual compactions, context-curation prompts, recovery actions, and configuration touches required per completed task;
- task continuity: success, retained constraints, long-horizon retrieval, and recovery after compaction, restart, or provider failure;
- net-true efficiency: billed input/output tokens, model housekeeping calls, tool calls, cache reuse, latency, and restore work—not only resident-window size;
- determinism: the fraction of placement transitions resolved without a model, replay agreement for identical evidence, and reasons for every escalation;
- safety: provenance retention, capability isolation, reversible replacement, and fail-closed behavior under malformed summaries or unavailable models;
- adaptation: held-out improvement from an RSI-proposed policy change, including regression and rollback evidence.
Compare four arms where the harness permits it: user-managed baseline, harness-native compaction, deterministic fak policy, and deterministic policy plus bounded semantic escalation. Segment results by task shape and context pressure so a win on repetitive coding traces is not presented as a universal context result.
What is live on the default path today
This is the load-bearing honesty section. From a wiring survey at HEAD (a component is
“live” when a non-test file in cmd/fak or internal/gateway imports it):
- Live, default-on, on the
fak manage/servewire — theinternal/gateway/messages.gopipeline: a 1-hour cache-TTL upgrade → anctxplanO(1) planned resident view → a cache-prefix-preserving compaction shed (the shed is suffix-shaped so the warm prefix splices through byte-for-byte, and each dropped span leaves afak_context_restorehandle — plus a verbatim[fak:goal]pin — so nothing load-bearing is lost to the trim) → oversizedtool_resultelision → apromptmmuinbound tool/system prune. Alongside it:ctxmmuwrite-time result admission (quarantine or page-out to a CAS pointer),compactcoherecoherence sensing,cacheobsobservation,rehydrateon resume, andrecall/contextqdemand paging for finished sessions and MCP resources. - Built and CLI-reachable, but off the default path:
fak session budget|envelope|reset-diff,fak vcache prove|observe|score,fak headroom, andfak debug --cmd context-plan-preview. These are the operator/debug surfaces the doctrine allows to exist; they are not required to get the automatic behavior.
So a long session on the default path already gets a planned resident view, a cache-preserving shed instead of a cache-busting truncation, write-time quarantine of poisoned results, and demand-paging back in on resume — without anyone passing a flag.
Where fak is still only a referee (the honest gap)
Two caveats keep this page citable rather than hype:
- On the Claude Code wire, fak is a referee, not the owner. The harness still
fires its own auto-compaction, and fak’s actuator against it (a PreCompact
suppression, tracked as #1133)
is not yet wired. Today fak measures and senses the harness compacting the window
— and keeps its own levers cache-preserving — but it does not yet prevent the
harness from butchering context.
compactcohereexists precisely because two context managers share one wire and fight; the end state is one manager per wire. - Some rungs are designed, not shipped. Relay-by-default for headless fleet
workers, an auto-derived context envelope (retiring
--ctx-view-budget), and the unconditional tool-result windowing that would let the “don’t read big files” instruction be deleted are filed rungs under the automatic-context epic (#2198), not live defaults. Where the kernel cannot place a fact automatically, the contract is to abstain with a structured reason — never a silent degrade.
What you still control
Zero-knob context does not mean fak decides your goal. What stays yours:
- the actual objective, explicit facts, and pins;
- hard budget limits (token, turn, wall-clock) when you want a ceiling;
- layout preferences and any approval to promote or delete durable memory.
What you stop doing: saying “summarize our context,” “keep that in the prompt,” “remember the old reset had my real goal,” or “don’t read that file, it’ll overflow.” Those are placement responsibilities the kernel carries — choosing the bounded resident view, keeping dropped spans recoverable by digest, carrying the pinned objective and remaining budget through a hidden reset, and keeping context-only facts out of durable memory unless promotion is earned.
The one-line version
The context window is RAM for agents, and asking a user or an agent to manage it is asking them to hand-write overlays in 2026. fak treats residency and warmth as one placement decision a kernel owns: on its own wire the automatic pipeline is the default, and on a borrowed wire it is — for now — an honest referee working toward being the owner.
Where to go deeper
- The doctrine, the full manual-overlay inventory, and the per-surface infusion map:
CONCEPT-AUTOMATIC-CONTEXT-2026-07-01.md - The product contract for long sessions that cross hidden resets:
managed-context-continuous-usage.md - Why a bounded resident view is cheaper than carrying a full transcript forever:
o1-context-window-economics.md - The cache-preserving compaction shed, how the prefix survives it, and what the drop
leaves behind (the goal pin, the originating-task tombstone, and
fak_context_restore):context-shedding.md - The exact-span-removal primitive behind write-time quarantine:
addressable-kv-cache.md -
Why context survival and durable-memory promotion are separate decisions:
../CONTEXT-IS-NOT-MEMORY.md - How a large external source can be named, faulted, filtered, cached, and
admitted without putting all of it in every model turn:
context-as-a-variable.md