LLeMbas-CLI/harness/context.md

Context hygiene

Spec 3.1.0. What a session does to keep tool results from filling the model's context, and (§10, from 3.1.0) what it keeps still so the model's server can reuse what it has already read — the same in a chat and in an agent session, in both projects. The texts and numbers are loop.json context; the cases are conformance/context.json; what the model is told is prompts/blocks/context.md.

The one rule

Every measure acts when a result is inserted. Nothing already sent to the model is ever rewritten. Changing earlier context invalidates the prompt cache from that point on: a local server processes everything after it again, and a cloud API charges full input price for it again — on a long context that costs more than the measure saves. So no earlier result is ever shortened, replaced by a stub or removed afterwards. The one deliberate break is compaction, which already replaces the history with a summary.

1. Every result has an id

Every tool result is given an id when it is inserted: # and the result's number in the session — counting from 1, in lowercase hex, at least ids.digits (4) digits — so #0001, #0002, …, #000a, …, #10000. Unique in the session and never reused — not after a compaction either. It is the first thing in the result, in brackets: [#0001], then a newline and the result.

A read's bracket says more: the path as the call gave it, the lines shown, the file's length in lines and the first sha_digits (8) hex digits of the SHA-256 of the file's content —

[#0012 src/app.ts lines 1-200 of 340 sha 1c9e04ab]
1: import …

— and an empty file [#0013 notes.txt empty sha e3b0c442]. The full hash is kept by the session; only it decides whether a file is unchanged.

Paths in a bracket are the call's. A read's bracket, an edit's (§5) and the compaction table (§7) name the path as the call gave it — what the model wrote, so it recognises it. What identifies the file — for a stub, for the table's "newest read of each path", for whether a file was read before it is changed — is its absolute, resolved path (filesystem.md, Paths). Every other answer (an error, a refusal, a search's results) names the absolute path.

Every result is stored with the session, in full — before any cap, and for a stub the text it stands for — so recall can show any of them for as long as the session exists.

2. An unchanged re-read is a stub

A stub names only a result that is in the request being built — one whose text is among the tool results this request sends to the model. That set, not anything the session stored, is the dedupe table. Where a request does not carry earlier results — a chat on the server sends no earlier reply's tool results with the next reply; after an undo, a rewind or a compaction they are gone — a read is answered in full, because what a stub would point at is not in front of the model. It holds for §2 and §6 alike.

A read is answered with a stub when the file's content hash equals that of an earlier full read of the same file still in the dedupe table, and the lines asked for lie wholly inside that read's lines:

[#0019 src/app.ts lines 50-80 of 340 sha 1c9e04ab] Unchanged since #0012, which already shows lines 1-200.

The bracket is the new read's; the sentence names the earlier result and its lines. A stub points at a full result, never at another stub. A file that changed — by this session's own edit or from outside — has another hash and is read in full; a range reaching past the earlier read is read in full.

3. Large output is capped on the way in

A result over cap.max_lines (400) lines or cap.max_chars (40,000) characters keeps its head — as many whole lines as fit head_lines (200) and head_chars (20,000) — and its tail — likewise, tail_lines (100) and tail_chars (10,000) — with one line between:

[1234 lines elided, full output #0020]

A first line longer than head_chars is cut to it and ends […cut]; the elided line follows it whatever it counts. Reads and recall are not capped this way: each has its own window (2000 lines from an offset).

4. recall

recall(id, offset?, limit?) shows a stored result again, in full, up to 2000 lines from offset:

[#0021 recall #0020 lines 1-2000 of 3400]
…

An id the session never gave: [#0021] No stored result #ffff in this session. The # may be left out of the argument. A recall is not capped, is not deduplicated, and is itself stored.

5. Edits answer with the diff

edit, multiedit, apply_patch and write over an existing file answer with the unified diff of the change (three lines of context, hunks only — the path is in the bracket) under a bracket naming the path and the new content's hash:

[#0022 src/app.ts sha 7d0a91c3]
@@ -12,3 +12,3 @@

write of a new file answers [#0023 docs/new.md sha 52b6e3a0] Created, 14 lines. — the model wrote the content and has it. A deleted file is [#0024 old.md deleted]. An apply_patch over several files answers the id alone, then each file in its own bracket with its change, in the patch's order:

[#0025]
[src/a.ts sha 7d0a91c3]
@@ -1,2 +1,2 @@
[docs/new.md sha 52b6e3a0] Created, 14 lines.
[old.md deleted]

A note the tool adds (a skill file written outside skill_manage) follows the diff. The diff is capped like any output, the first line kept.

6. The same search or listing twice is a stub

For dedupe.by_result — list, glob, grep, search — a call with the same arguments (compared as JSON with sorted keys) as an earlier one in the dedupe table, whose result is the same text, is answered [#0027] Same result as #0026. The call is run again and compared, so a change from anywhere shows up as a full result. Other tools are never deduplicated: a command's output twice is two results.

7. Compaction

Compaction is the one deliberate break of the cache, and it already exists. From 3.1.0 the summary is asked for as the next turn of the same conversation: the same system prompt, the same tools, every message as it was, and then one more user message — prompts/tasks/compact.md, whose {{transcript}} and {{previous_summary}} are empty in this form, since the model has the conversation, an earlier summary included, itself. So the request that makes the summary costs only that message; a separate request with a pasted transcript was a full re-read of everything, and a transcript capped to fit it lost the session's middle. A tool call in the summary's reply is not run; its text before the call is the summary, and a reply with none fails the compaction as an empty one does. The summary request is never shown as a turn of the session, and it is not stored as one. In 3.0.0 two things came with compaction, and still do:

• After the summary the harness adds — itself, not the model — a table of the reads the summary covers: the full reads made since the previous compaction (or since the session began) in turns that are still part of the history being summarised — whether or not their results are still in the request. A turn taken back (an undo, a rewind, a reply regenerated or deleted) takes its reads with it. Of those, the newest full read of each file (by its absolute path), newest last, at most compaction.rows (50); a stub is not a read here. A session that resends every result (the CLI) finds exactly these in its dedupe table; a chat, which does not, finds them in what it stored for the turns being summarised:

  ## Files read before this summary
  
  Read a file again for its content; recall shows a result by its id.
  
  | Path | Lines | sha | Result |
  |---|---|---|---|
  | src/app.ts | 1-200 of 340 | 1c9e04ab | #0012 |
  

  With no reads there is no table.

• The dedupe table is emptied, so no stub ever points at content that is no longer in the context. A read after compaction is a full read; a recall of any earlier id still works.

10. The prefix: what the model has already read

A model's server keeps what it has read of a request and reuses it for the next one only as far as the two are the same from the first byte. The system prompt and the tool list come first, so a change to either is a full re-read of everything after them — on a long session minutes of work on a local server, and the full input price again on a cloud API. Measured (2026-11-05, a local model): a date that changed at midnight sent a 16,912-token session from 99 % cached to 0 %, 139 seconds. So, from 3.1.0:

1. The system prompt is made once per session and sent unchanged. It is built when the session starts, kept with the session, and every request sends those exact bytes. It is built again only where everything is read again anyway: after a compaction (§7), or when the session moves to another model. A session that is resumed sends what it kept.

2. Nothing in it is a clock. No date or time. The date goes in a note (rule 3): the first user message of a session carries it, and so does the next one after the date has changed.

3. What changes during a session goes at the end, as a note on the next user message, never into earlier text: the permission mode (modes/<mode>.md as the note's body when it changes, and its first line is in the prompt only as it was at the start), the plan when the person changed it (the model's own plan_write and plan_update already answer with it), a memory or instruction file the person edited, a personality chosen, an MCP server's instructions that arrived later, the date. The note is a block after the person's words:

   <session-note>
   The permission mode is now plan: …
   </session-note>
   

   (loop.json context.note.) Each change is one block of the note, the blocks separated by a blank line, in the order context.note lists them; a value that became empty reads context.note.empty; the date is the person's own (their zone, else the machine's). A note is part of that message from then on, like anything sent. A request with no user message (a tool step), and words the person adds to a turn already running, carry no note; it waits for the next message that starts a turn. A change the model made itself (its own plan_write, memory, settings, a file it wrote) needs no note: its tool result already said it.

4. The tool list is the same for the whole session. A tool whose requires can come and go during a session — page, display, forge, and plan mode for plan_submit — is offered from the start whenever the session could ever meet it, and a call made while it is not met answers the tool's unavailable text. Only what is fixed for the session may leave a tool out: the session kind (sessions), the model (vision), a subagent's narrowing, what the project's configuration or the person switched off before the session began. The tools stay listed in the wrap-up request too (loop.json wrap_up): its message says they are withdrawn, and a call in that reply is not run. A tool withdrawn after its final refusal stays in the list and answers that refusal. The one exception is an MCP server: a session waits up to mcp_wait_ms for the servers it is configured with before its first request, so their tools are in the first list; a server that connects later adds its tools when it connects — one re-read, once — and its instructions come as a note.

5. Nothing already sent is rewritten — the one rule above, for results; old tool output is never pruned in place.

6. Every request's cache use is recorded where the provider reports it (cached input tokens), beside the request's other usage, so a slow prompt has a cause on record.

What a server does with a matching prefix is its own business; a harness that keeps these rules has done what it can.

8. Earlier reasoning

Left to the model's own chat template: the harness sends the history as it does, and neither strips reasoning a template keeps nor adds what it drops.

9. What the model is told

prompts/blocks/context.md, in every session that has recall.

Not in 3.1.0

Eliding old content in batches behind a threshold, and measuring quality and tokens with and without these measures, are left for a later spec. Every measure above ships with its unit and conformance cases.

Over the link

A device keeps its sessions' stored results itself; recall in an agent session reads the device's store. The ids are in the result text, so a client showing the transcript shows them as they are.