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.

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.