Context and compaction

A real audit outruns any context window. Compaction is what lets a run keep going, and it is the part of the harness with the most ways to go quietly wrong: drop the wrong message and the agent re-derives work it already did, or worse, forgets the sink it was about to prove.

locac's answer is deliberately boring. No model is involved. Compaction is a rule-based elision pass over the transcript, so the same history compacts identically on every machine, every time.

What gets elided

Only tool result bodies. Assistant text and user text are never touched, and the final message is never elided.

Elision is also non-destructive: the full body stays in the session's transcript store. Only the copy sent to the provider is shortened, and the agent can pull the original back with recall.

When it runs

A pass runs when the estimated token count crosses the threshold. The count includes overhead, the system prompt plus roughly thirty tool schemas, because that overhead is sent on every request and a budget that ignores it is a budget that overflows.

Every knob is settable, on the command line and in the config file:

locac run "…" --reserve-tokens 60000 --keep-recent 12 --evidence-budget-tokens 30000

{
  "compaction": {
    "enabled": true,
    "mode": "elide",
    "reserveTokens": 60000,
    "keepRecent": 12,
    "evidenceBudgetTokens": 30000
  }
}

mode has one implemented value, elide. summarize is reserved and does nothing today.

The evidence budget

Not all old tool output is equally worth keeping. Four tools produce the material a finding is actually built out of:

• grok_sink
• scan_sinks
• trace_callers
• record_finding

Their results are security evidence, and old evidence is preserved verbatim while the evidence budget lasts. Everything else in the old region is elided outright.

One more thing counts as evidence: a tool call that failed. A failing call is high signal, since it is usually the moment a hypothesis died or a PoC misfired, so isError results are protected on the same budget.

Two invariants

These are the rules that make the pass safe to run repeatedly on a growing transcript.

MONOTONE. The budget is spent in transcript order, oldest first. That means message i's fate depends only on messages 0..i, never on anything that arrives later. So the prefix of the transcript that has already been sent renders byte-identically on the next request, and the provider's cached prefix stays valid. Spending the budget newest-first (the obvious implementation) kept rewriting the front of the transcript and invalidated the cache on every turn.

EVIDENCE FLOOR. The single newest piece of old evidence is always kept verbatim and is not charged to the budget. Whatever the budget is set to, zero included, the most recent evidence the agent was working from survives the pass.

The marker

An elided result is replaced by a line that says what was removed and how to get it back:

[elided 48213 chars of scan_sinks output — recall seq=61][ artifact ids cited in it: ev_3a91f0c2, ev_5b0d77ae]

Artifact ids are salvaged out of the elided body so a later score_finding can still cite the artifact the run minted, without re-running the command that produced it. The list is capped at eight ids: an uncapped join let a target repository turn a 680,000-character tool result into a 260,000-character marker that the model would have read as trusted harness text.

Getting it back: recall

recall(seq: 61)                      # the exact message, verbatim
recall(query: "extract path join")   # ranked snippets across the full transcript

recall searches the stored transcript, everything compaction has elided out of the live context included, so an elided result is a deferred read, not a loss.

The seq= marker only works because sequence numbers are contiguous per session. That is a real constraint rather than an assumption: recallability is opt-in, and the TUI turns it off one-way for the rest of the session when /new or /resume swaps to a different session underneath. A marker that promises seq=61 must never resolve to some other session's message 61.

When eliding is not enough

If the context still overflows after a pass, compaction escalates one tier:

The escalation is sticky for the session, so a run that has hit the wall once stays aggressive rather than oscillating, and it survives a resume, because the tier is recorded in the session journal and read back on load. There is no third tier: once aggressive, an overflow is an overflow.

What a pass reports

Each pass that actually elided something is recorded with its before/after token counts, how many results were elided, how many evidence bodies were protected, and where the cutoff fell. A pass that changed nothing is not journalled, or a long run's journal would fill with no-ops.

The TUI's /context view reads the same numbers.

Turning it off

locac run "…" --no-compaction

Useful for reproducing a context-window bug and for nothing else. A long audit with compaction off will overflow, and the overflow arrives as a provider error mid-turn rather than as a graceful degradation.

Next

Skills and roles covers the other half of what shapes a run's context: the playbooks injected into the system prompt, and the typed subagents that get their own.