Skip to the content.

Automatic context: nobody manages the window

Status: concept note + doctrine + epic spine for #2198 (children #2199–#2206). Nothing new ships from this note; it binds programs that already exist (managed-context #1570, perpetual-session relays #1860, cache-default #1490, inbound prompt-MMU #751, system-prompt MMU #1258, ctxplan reachability #844) to one falsifiable property and files the rungs that are missing between them.

The operator’s ask

The broader point is you don’t have to manage the context window yourself. The user side of it and the server side are two sides of the same coin. Think about how to infuse this in every aspect — super automatic context management. The user (agent or human) should NOT have to think about managing context ever again.

The thesis

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 GC 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 agent era’s physical RAM, and in 2026 everyone is writing overlay code by hand:

Every one of those is a manual overlay — a human or agent doing placement work a kernel should own. The doctrine of this note, 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 call gets in” (the security floor) and “no good value silently gets lost” (context safety, #1217). It is checkable: enumerate the manual overlays, watch the counter.

Two sides of the same coin

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. The operator’s point is that these are not two problems. They are two projections of one placement problem over one address space:

Today fak runs these as two programs with two ledgers: managed-context (#1570: plans, resets, envelopes, assumption ledgers) prices residency; cache-default (#1490: attribution, gates, vCache) prices warmth. The seams where they already touch — breakpoint planning as part of context planning (#1603), cache affinity across continuations (#1609), fak_changes invalidation into ctxplan (#1561), fak vcache context-join — are exactly the places the tree already knows they are one thing. The doctrine makes it a law: one placement decision, one ledger. No residency change ships without its warmth price, and vice versa.

The tree also already contains the negative proof. compactcohere exists because two context managers share one wire — fak’s cache-preserving levers under Claude Code’s cache-destroying auto-compaction — and fight. Generalized: exactly one context manager owns a wire. Everything else is sensed and made coherent, or suppressed.

What exists today (the honest map)

From a wiring survey at HEAD (imported by a non-test file in cmd/fak or internal/gateway = live):

Two honesty caveats. First, the 54 managed-context children #1571–#1624 were bulk-closed in late June; per the epic close-out method a CLOSED box is a self-report, so treat those as design-shipped — the still-open operator readout (#1918) is what would witness the product contract. Second, on the guard wire fak is a referee, not the owner: the harness still fires its own auto-compaction, and fak’s actuator against it (the PreCompact suppression, #1133) is not yet wired — today fak measures the harness butchering context but does not prevent it.

The manual-overlay inventory (what a user still manages)

Human overlays:

Agent overlays (the goal says agent or human — an agent that must think about its window is the same defect one level down):

Server-side overlays: breakpoint placement (#1603, design-closed; live wiring unproven), TTL selection (H3), prefix stability as discipline rather than contract (promptmmu covers tools[]; the base context is still harness-authored while syspromptmmu sleeps).

The doctrine

Per-surface infusion map

Surface Automatic looks like Exists at HEAD Gap
fak guard (proxy) full pipeline fires; harness compaction coherent or suppressed pipeline live; compactcohere senses PreCompact actuator #1133; dynamic budget #1142
fak serve (native) KV auto-sized; kvmmu evicts; no window error reaches a user kvmmu bridges; #1045 designed auto-fit live wiring; RunArm live caller #1316
dispatch/fleet workers headless goal ⇒ relay by default; workers never die of window relay epic #1860 filed tracks E–H, then default-on admission
fak session verbs envelope derived, not typed budget/envelope/reset-diff verbs auto-envelope from model window + task class
memory/recall recalled facts re-verified at injection; stores self-compact memq/recall live; write gate #82 #2077; memview wiring; retire manual compaction skills
subagents/workflows delegation priced by forecast window cost callavoid amplification data forecast-based auto-delegation advice
resume/rehydrate resume splices warm KV; no re-read ritual rehydrate live; WaitResume built WaitResume zero live callers
base context fak authors its own spine, paged + versioned syspromptmmu built first live splice (epic #1258 residual)
docs/AEO one canonical “you never manage context” page explainers scattered the page, citing this doctrine
CI/bench flat-context + zero-loss witnessed per release soak bench #1623 designed wire into nightrun/ci

The rungs (new, not duplicating #1570 / #1860 / #1490)

Filed as epic #2198: R1 #2199 · R2 #2200 · R3 #2201 · R4 #2202 · R5 #2203 · R6 #2204 · R7 #2205 · R8 #2206.

Generation classification of the rungs

The epic body’s first guess was gen/next, but the fleet’s applied evidence reclassified the rung program to gen/now: the keystone R1 (#2199) closed carrying managed-context, generation, gen/now on the Generation G0 - Now / Immediate milestone, and the newest sibling #2947 was filed gen/now. Under docs/generation.md a stream label and milestone that disagree with an issue’s applied peers are intake drift to fix before dispatch — so every rung (R1–R8, #2199–#2206) inherits gen/now plus managed-context unless a later witness demotes it. R5 (#2203) is classified gen/now: its done-condition (a derived, non-8000 budget with zero flags) improves the current default loop with a code witness, not a future architecture bet — the gen/now test in docs/generation.md.

Invalidating assumption: this reads the applied labels on R1/#2947 as the program’s true horizon. If a later reviewer demotes the autoctx program back to gen/next with evidence (e.g. R5’s model-window derivation proves to depend on #1860 relay mechanics that are themselves gen/next), this classification and the per-rung labels should move with that evidence, not stay pinned here.

Honesty fences

Next checkable step

Epic #2198 and children #2199–#2206 are filed (lane and witness in each body). Build R1 (#2199) first — the counter is the cheapest rung and everything else is graded against it. Check: gh issue view 2199.