Context Management
Auto-condensing, long sessions, and context health
Every model has a context window — a hard limit on how much conversation, code, and output it can consider at once. On a multi-hour task the transcript grows relentlessly: file reads, diffs, command output, your corrections. Left unmanaged, the session degrades (the model “forgets” earlier decisions) and eventually errors out. Nexgile Code manages this for you: it tracks usage live, condenses older history intelligently before the window fills, and keeps bulky data — long terminal output, wide file lists — out of the window unless it is needed.
Healthy context is not just about avoiding errors. A leaner window is cheaper per request and keeps the model focused on what matters now.
Watching context health
Section titled “Watching context health”Expand the task header (click the task title) to see Context Length — a live bar showing current tokens against the model’s window. Next to it sits a condense button (Intelligently condense context) you can click at any time to trigger condensing manually, without waiting for the automatic threshold.
The task header also shows the task’s running API cost, so you can watch context growth and spend together.
Automatic condensing
Section titled “Automatic condensing”Condensing summarizes the older part of the conversation in place: earlier turns are replaced by a dense summary that preserves the task goal, decisions made, current state, and next steps, while the most recent exchanges stay verbatim. The task continues seamlessly — same conversation, most of the window reclaimed.
Configure it in Settings → Context:
- Automatically trigger intelligent context condensing (
autoCondenseContext) — on by default. - Threshold (
autoCondenseContextPercent) — the percentage of the context window at which condensing triggers. The slider runs 10–100% and ships at 100%, meaning condensing waits until the window is nearly exhausted. Lowering it to 70–80% condenses earlier and keeps long sessions smoother — condensing works better when there is still room to work in. - Safety buffer — independent of your threshold, condensing also triggers whenever the conversation comes within roughly 10% of the window’s hard limit (minus space reserved for the model’s reply). You cannot configure your way into an overflow.
- Per-profile thresholds — the threshold dropdown lets you set a different trigger percentage per API configuration profile, useful when you switch between a large-window model and a small one. A profile without its own value inherits the global setting.
- Custom condensing prompt — the condensing instructions are editable (Settings → Context, “Custom Context Condensing Prompt”). Tailor what the summary must preserve — for example, “always retain the list of files changed and the migration plan” — and reset to the default any time.
Two details worth knowing:
- Folded file context. Files the agent read earlier in the task are not carried into the summary as full text — they are folded into structural outlines (classes, functions, signatures) so the agent keeps the map without the bulk, and can re-read any file that matters again.
- Condensing costs one model call. The cost is counted in the task’s total, and it is far cheaper than repeatedly re-sending the full history.
Sliding-window fallback
Section titled “Sliding-window fallback”If condensing is disabled or fails (for example, a provider error mid-summarize), Nexgile Code falls back to sliding-window truncation: roughly the older half of the conversation is hidden from the model and a marker notes how many messages were tucked away. Truncation is non-destructive — the messages remain in the transcript, and rewinding the task past the truncation point brings them back. Condensing is smarter (it preserves meaning, not just recent messages), which is why it is the default and truncation is the fallback.
Caps on ambient context
Section titled “Caps on ambient context”Some context arrives automatically with every request — which files are open, what the workspace contains, current problems. Settings → Context bounds each source:
| Setting | Default | What it caps |
|---|---|---|
Open tabs context limit (maxOpenTabsContext) |
20 | How many open editor tabs are listed to the model |
Workspace files context limit (maxWorkspaceFiles) |
200 | How many workspace files appear in the initial directory listing |
Include diagnostics (includeDiagnosticMessages) |
On | Whether Problems-panel errors and warnings are shown to the agent |
Max diagnostic messages (maxDiagnosticMessages) |
50 | How many diagnostics are included |
Delay after writes (writeDelayMs) |
1000 ms | Wait after each write so diagnostics can catch new errors before the agent continues |
Diagnostics visibility is one of the agent’s best feedback loops — it sees the red squiggles its own edit just caused and fixes them without you pasting anything. Keep it on; cap it if a noisy repo floods the window with warnings.
Terminal output: previews and disk spillover
Section titled “Terminal output: previews and disk spillover”Command output is a classic context killer — one verbose build can be bigger than the rest of the conversation. Nexgile Code shows the agent a bounded preview and persists the rest:
- Command output preview size (Settings → Terminal): Small (5 KB), Medium (10 KB, default), or Large (20 KB).
- Output beyond the preview is saved to disk in full, per task. The agent retrieves more on demand with the
read_command_outputtool — by artifact id, with optional search (regex or literal), offset, and limit — so it can hunt for the one error line in a 5 MB log without ever loading 5 MB into the window.
If the agent’s conclusion about a command seems wrong, check the real terminal output yourself — the preview it reasoned from may not have included the part you are looking at, even though it could have fetched it.
Signs of an overloaded session — and what to do
Section titled “Signs of an overloaded session — and what to do”Watch for these, especially past the several-hour mark:
- The agent re-reads files it already read, or asks about decisions you settled earlier.
- Responses contradict established constraints (“we agreed not to touch the schema”).
- Condense events fire repeatedly within a few requests.
- Each request gets slower and pricier while progress per request drops.
Remedies, in escalating order:
- Condense manually with the task-header button, at a natural boundary (a subtask just finished).
- Lower the threshold so automatic condensing runs earlier in future.
- Start a fresh task with a written handoff: have the agent summarize state, decisions, and remaining work, then paste that into a new task. A fresh window with a good summary reliably beats a fatigued session. For repository-scale strategy, see Working with Large Projects.
- Split the work into subtasks — each child runs in its own context. See Subtasks & Todo Lists.
A handoff prompt that works well:
Write a handoff summary for a fresh session: the original goal, decisionsmade (and rejected alternatives), files changed so far, current state ofthe work, and the remaining steps in order. Be specific about file paths.Paste the answer into a new task, add @git-changes so the fresh session sees the live diff, and continue from there.