Context and Compaction

Every model has a fixed context window. A long session will reach it. Jan Agent handles that by summarizing the older part of the conversation rather than failing.

Watching it fill

The header carries live usage:

ctx 6K/128K is context used against the window. It updates as each request lands, not only when a turn ends.

At the end of a turn you get a receipt:

↑ is context sent, ↓ tokens produced, then elapsed time and throughput. The two differ on purpose: context is the size of the request, output is what came back.

The /context overlay

Opens a centered overlay on top of the live transcript (the turn keeps running behind it). Inside is a rail that shows the fill as a percentage of the window, a visual bar with the ^ marker at the current usage point and ╳ marking the auto-compact reserve zone, a token scale, and a headroom line (N tokens available before auto-compact), followed by a per-category breakdown: System prompt, System tools, Project context, Skills, and Messages. Press Esc, q, or Ctrl+C to close; closing never cancels the turn.

The headline fill uses the provider's own prompt_tokens when available. After a compaction, rewind, or resume the provider count is reset, so the number falls back to an estimate (labelled estimated) and climbs back to the real value on the next request.

The report is a point-in-time snapshot taken when /context is typed, so numbers stay fixed until you open it again.

Automatic compaction

As the conversation approaches the window, older turns are summarized to make room. The reserve is the headroom kept free so compaction has space to work in:

Compaction triggers as usage nears context_window - compaction_reserve_tokens. When it runs, the session history is replaced with the compacted version and the console says so:

Compacting on purpose

Worth doing before you start a large new sub-task in a long session: it clears room so the new work isn't immediately fighting for space.

Context overflow

If a request overflows anyway, the loop compacts and retries rather than erroring out. Each retry keeps a smaller tail of recent messages. If a pass fails to shrink the conversation at all, it gives up rather than looping.

Capping output

max_tokens caps what the model generates in a single response. It is omitted from the request when unset, which leaves the model's own default in charge:

Budgets

Separately from the context window, a project can bound how far one run goes:

That's a stop point for the run as a whole, not a per-request limit. There is no turn cap - the agent runs as many turns as the task needs, bounded only by this budget (or by cancelling it). See Project config.