Context management

A model can receive only a limited amount of information in each request. This capacity is called the context window. Long conversations, code, Tool definitions, and Tool output all consume that window, so an Agent must decide what to include in the next request.

Context contains more than chat text

A model request normally includes:

system rules supplied by the application;
structured descriptions of Tools currently available;
conversation history that must still be retained, or a summary of that history;
Tool results produced by the current Run;
current attachments, task instructions, and temporary working information;
output space reserved for the model's response.

As a result, an interface showing only a few messages may already use a large amount of context. Conversely, the complete history visible in the interface is not necessarily sent verbatim with every model request.

What is a token?

A token is a unit the model uses to measure text. It is not the same as a character or a Chinese character. Code, JSON, long paths, and Tool schemas also consume tokens. The context-window value entered during model setup is used for preflight estimates; actual measurement by a compatible provider may differ slightly.

The context indicator in the interface helps estimate remaining space. It is a safety estimate, not a provider bill.

How compaction works

When old history approaches the capacity limit, the system selects a complete, stable earlier segment and asks a model to create a shorter semantic summary. That summary replaces the segment in the model's view. The compaction boundary does not split a Tool call from its result, nor does it overwrite current-Run content that the model has not yet observed.

Compaction aims to preserve the task objective, confirmed decisions, evidence of completion, failures and approvals, unfinished work, and next steps. If summary generation fails, does not actually reduce the content, or conflicts with recent history, the old summary is not replaced by force.

Compaction is not chat deletion

Compaction changes the representation shown to later model requests. It does not directly delete early messages from the interface. Submitted messages and supported execution traces remain in local history. However, not every raw third-party result is archived permanently and in full. Large MCP results and browser results, for example, may retain only a safe projection or an Artifact.

Why an Agent may still “forget”

A summary necessarily loses some detail to become shorter.
The number of exact-history entry points retained by the system is limited; it is not a complete index.
The current model may have an incorrectly configured context window.
Uncommitted streaming fragments may be lost after a crash.
Forked or newly created conversations have separate history boundaries.

Make long tasks more reliable

State the objective, constraints, and completion criteria clearly at the beginning.
At every milestone, ask the Agent to summarize confirmed facts and remaining work.
Put important conventions in project files or a Skill instead of relying only on an old chat message.
Read large files by range instead of inserting an entire log at once.
When context becomes tight, close out the current phase before starting a focused new task.

For a large-task method, see Manage large projects.