Memory

Context management

A model has a fixed context window, but a real working session can run for hundreds of tool calls. Context management is what keeps a long conversation coherent inside that fixed window. It assembles each turn in a stable order, replays past work as real structured events rather than a summary, and shrinks what it must — always the re-derivable, never your instructions — so the agent keeps its memory of what it already tried instead of forgetting and repeating.

Updated today

Overview

At a glance

Goal: Keep a long session coherent inside a fixed model window
History: Real structured tool events, append-only, never rewritten
Shrinking: Only re-derivable content, and only when over budget — with recoverable traces
Directives: Your recent instructions are snapshotted and re-pinned, newest wins
Visibility: A per-turn breakdown of every component in the window

The difference from naive truncation is the whole point. Truncation drops the oldest messages and with them the agent’s memory of what it already attempted. Context management instead keeps the structure, shrinks only what can be re-derived, and leaves a recoverable trace where it does — so the agent stays oriented across a long run.

How a turn is assembled

Four classes of content, always in the same order.

Class	What it holds
System	The static core instructions that define how the agent behaves
Tools	A stable superset of available tools — the core set plus your connected integrations, in a fixed order
Session context	A once-captured head message with your memory, todos, integration status, and recalled memories
History	The append-only record of the conversation and every tool call and result

The stable prefix

Why the order is fixed, and what it buys.

The system and tools sections are held byte-identical from turn to turn, and everything that varies is appended at the tail. That stability lets the model’s automatic prefix cache keep hitting, which makes each turn cheaper and faster. It is also why your memory, todos, and integration status are pulled out of the system block into a separate session-context message: those change, and keeping them out of the core keeps the cacheable prefix from churning.

Note

Rarely used tools sit in a deferred list rather than the always-loaded set. The model promotes one on demand when a task needs it, which keeps the core tool block small and stable.

Keeping history in the window

Three mechanisms, from lightest to last-resort.

History is reconstructed as real structured tool-use and tool-result blocks, append-only and never rewritten, so the agent’s record of what it tried stays intact. When the conversation grows past the window, three mechanisms keep it in bounds — and they touch only the model’s copy, never the chat you see on screen.

Mechanism	When	What it does
Microcompact	Every round, lightest	Keeps the recent working set of tool results full; distills older, re-derivable results to a one-line outcome plus a recoverable stub. Replaces content, never removes blocks.
History cascade	Before a turn, if still over budget	A staged compressor: trim oversized results, then drop the oldest, then rule-based group summaries, then a whole-conversation digest — each stage firing only if the window is still too full.
In-turn digest	A ceiling backstop, rarely	During a very long tool loop, a deterministic head-plus-tail-plus-summary compaction near the top of the window. You can also force it on demand with /compact.

Tip

Budgets are computed against the current model’s window and recomputed every turn, so context management adapts automatically when a turn runs on a larger- or smaller-context tier.

Standing orders

Your instructions do not get compressed away.

Compaction shrinks re-derivable tool output, not your intent. Your recent instructions are snapshotted and re-pinned verbatim, with a newest-wins precedence, so a standing order you gave earlier survives even as the older tool history around it is distilled. The agent does not forget what you told it to do.

The context breakdown

A live account of what fills the window.

The platform measures every component of the working set with a single tokenizer and reconciles the total against the model’s real prompt-token count, reporting any residual openly as overhead rather than hiding it. The result is a per-turn breakdown you can inspect.

Bucket	What it counts
System prompt	The static core instructions
Capability index	The discoverable-tool index
Tools bound	Loaded tools, grouped by source
Tools deferred	Tools available on demand but not loaded
Session context	Memory, todos, integration status, recalled memories
Messages	The conversation and tool history
Attachments	Files and media in the window
Overhead	The reconciled residual, always shown