# Compaction and Reset

How a long run is kept inside the model's window, and what reset and remove clear.

## In-run compaction

Beyond the stored tiers, `internal/agents/exec/compact` keeps a single long run inside the model's window. Each step is a separate stage, applied in order and only as far as needed:

| Stage | Trigger | Effect |
|---|---|---|
| `CheckThreshold(model)` | Every iteration | Token budget for the current model — 80 % of its context window. Since v1.0.11 the window comes from a live table fetched once per hour from `https://llm-io.agenvoy.com/` and keyed by vendor + model, replacing the hard-coded per-family sizes; a model missing from the table falls back to 128 K. Since v1.0.25 a `copilot@` model missing from the table uses the `max_context_window_tokens` that Copilot's own `/models` endpoint reports (fetched in the background, refreshed every 24 h) instead of the former flat 256 K |
| `ExtractOldHistories` | Budget exceeded, first time in the run | Fold older conversation turns into the rolling summary |
| `ToolHistory` | Budget exceeded again, or there were no older turns to fold | Summarize the oldest tool-call exchanges into text |
| `TrimFallback` | Provider returns a context-length error | Since v1.1.1 the error first runs the same `ExtractOldHistories` → `ToolHistory` pass and resends; only when that pass cannot compact is the oldest exchange dropped before resending |
| `RawToolFallback` | Model switch mid-run | Convert tool history to plain text so the new model can read it |

Manual compaction runs from the TUI (`/compact`; the `/memory` command was removed, reset is now `/reset`) or `POST /v1/session/:id/memory`. That one endpoint takes an `action`: `compact` drops older messages and returns `removed`, `summary` rebuilds the rolling summary and returns `count`, and `reset` clears the conversation — `mode: "summary"` keeps the rolling summary, `mode: "all"` wipes it too. Since v1.1.1 the TUI popup also has a read-only `summary` tab that shows the current rolling summary.

### Search routing

| `match` parameter | Source | Use case |
|---|---|---|
| `semantic` (default) | ToriiDB VSearch | "What did we discuss about X?" — meaning-based |
| `keyword` | SQLite FTS5 (archive) + ToriiDB substring (recent) | "Find messages containing 'sandbox'" — exact text |

### Cross-session error memory

Tool failures and the fix that resolved them persist across sessions in `error_memory` with **90-day TTL**. Only records written with `outcome=resolved` are stored; `failed` / `abandoned` writes are discarded, so abandoned strategies are no longer kept. On hit (either via keyword `Contains` or `db.VSearch`), the entry's TTL is refreshed via `db.Expire`.

When the same tool name fails in a future session, `toolCall.go` automatically queries `error_memory` and appends up to 3 related records to the failed tool result as `related_errors`; the agent applies the recorded fix.

A record's recorded action can be edited from the web dashboard's Lessons view (`PATCH /v1/torii/error`, which rewrites `action` and keeps the TTL); `GET /v1/torii/error` lists records.

## Reset / remove behavior

| Operation | `history.json` | ToriiDB `DBSessionHist` | SQLite (messages + meta) | `summary.json` |
|---|---|---|---|---|
| Compact (auto) | Trimmed to 80% | Entries < cutoff removed | Untouched (already has all data) | Untouched |
| Reset (`/reset`, `mode=summary`) | Deleted | Cleared | Cleared | Preserved |
| Reset (`mode=all`) | Deleted | Cleared | Cleared | Deleted |
| Remove session | Directory deleted | Cleared | Cleared | Directory deleted |