Context

Every agent works inside a context window: the running record of your conversation, the files it has read, and the output of every tool it has run. On a short task that record stays small. On a long one, a multi step forensic review, a large refactor, an afternoon of back and forth, it grows fast, and that is where most agents quietly break.

Why long runs drift

As the window fills, a model loses reliable access to its original instructions. It starts to forget the constraints you set at the top, lean on stale tool output, and drift toward side goals. The important part is that quality drops well before the hard token limit, not at it. An agent can look fine and still be running on a context that no longer holds the thread of the work. Push a little further and it does not just degrade, it overflows the window and the call fails outright.

Perch is built to run long, so it treats the context window as something to actively manage on every single turn, not something to fill until it errors.

The compaction pipeline

Before each model call, Perch runs the working context through an ordered pipeline. Each stage is cheaper and less destructive than the one after it, so the expensive, lossy steps only run when the cheap, lossless ones were not enough.

1. Prune heavy artifacts first, always

Long runs get fat from bulky, low value payloads: full browser page snapshots and operator screenshots. Perch prunes these on every turn, before it even checks the budget. Page snapshots are cut down to their actionable parts (the controls and structure the model might act on) and the oldest ones are reduced to stubs. Screenshots are dropped or compressed to a hard token ceiling. This is pure waste removal, so it is unconditional. A single raw DOM snapshot or screenshot can cost more than dozens of turns of actual reasoning, and it is almost never needed a few steps later.

2. Microcompact stale tool output, no model call

If the run is still over budget, Perch clears the bodies of older tool results and keeps the most recent ones verbatim. The tool call and its result pairing stays intact, only the stale result body is replaced with a short marker. This matters most for the exact workloads Perch is built for: a forensic run that reads dozens of files and runs many sandbox checks accumulates enormous tool output, and the model rarely needs the raw text of a file it read twenty steps ago, only the conclusion it drew from it. This step is cheap, involves no extra model call, and often frees enough room to skip the expensive summary entirely. It happens silently, because clearing stale tool bodies is a routine cost saver, not an event worth interrupting you for.

3. Summarize older turns, only when still over budget

If the run is still over budget after the cheap steps, and only then, Perch summarizes the older stretch of the conversation into a compact record of what happened and what was decided, folding in any earlier summary, and keeps working from that. This is the one expensive, lossy step, so it runs last. When it runs, it is surfaced: the transcript marks the moment and reports what changed.

4. Hard enforcement backstop

As a final guarantee, Perch enforces the real payload size against the model's limit before sending, trimming from the oldest messages while preserving a floor of recent turns. This is the safety net that makes overflow failures structurally impossible: even in an unusual case, the request that reaches the model always fits.

Measuring the true window, not a guess

Token estimates based on character counts systematically undercount dense content: CSV, JSON, code, and long columns of numbers. That is exactly what a financial or document run is full of. A naive estimate makes compaction fire late or never, and the payload overflows. Perch calibrates its estimate against the provider's real prompt token count from the previous call in the same run, and anchors the compaction trigger to that. Compaction fires on the true size of the context, not on a guess that is wrong in the one direction that hurts.

Preserving the live thread

Compaction never touches what you are working on right now. Perch always keeps a recent tail of the conversation word for word, sized to a real token budget rather than a fixed message count, and it keeps tool calls paired with their results so the recent history stays coherent. The old context is compressed; the live thread is left alone.

Respecting your model's real budget

Perch compacts against the context limit that actually applies to your run, including the larger window a higher tier unlocks, not the raw window of whatever backing model is serving the turn. It also targets a genuine working budget with headroom rather than squeezing just under the ceiling and refilling a step later, so the model keeps room to think for the turns ahead.

Visible, not silent

Real compaction is something you can see. The context meter shows how full the window is, and when Perch runs a summary it marks the moment in the transcript and reports what changed: how much was freed, how much was summarized, how large the summary is, and how much recent history was kept. You are never left guessing whether the agent still has the thread. The cheap background steps stay quiet; the one lossy step is always shown.

Why it matters

This is the difference between an agent that demos well on a five step task and one you can trust on a long, high stakes run. A forensic review that spans dozens of file reads and sandbox checks has to stay anchored to the original question the whole way through, and it cannot fail halfway because the window overflowed. Perch keeps long work accurate and bounded by design, so the answer at the end is grounded in the same instructions you gave at the start.