How QwenPaw stays useful when context runs out
QwenPaw's context problem is not simply that a model has a finite token limit. In a long coding or research task, the system must decide which material remains in the live prompt, which material can leave without losing the current objective, and how the agent can recover exact evidence later. This chapter explains Scroll as that state-management mechanism: durable history sits behind a smaller working context, while active work is protected and evicted material remains addressable.
A context window is a working set, not the record
A model's context window is the material it can see on the current request. It is tempting to treat that window as the conversation itself, but that conflates two different jobs. The live prompt should be small enough for the next reasoning step. The record of what happened should remain complete enough to answer a later question, repair an interrupted task, or verify why a decision was made.
QwenPaw's Scroll strategy separates those jobs through write-through persistence. As live turns enter the context, they are written to a durable SQLite conversation history. The stored entries retain structured information such as message content, tool arguments and results, block metadata, timestamps, and deduplication keys. The full history is therefore not reconstructed from a later summary. It exists before compression begins.
That order matters. Scroll persists first and evicts second. If a history write fails, the store records degraded durability, and the compaction path does not pretend that the unpersisted middle is safely recoverable. Discarding material before it has a durable row would create a silent loss precisely when the model is under pressure. The system's refusal to evict in that state may leave the prompt too large, but that is a visible capacity problem rather than an invisible evidence problem.
The history store also separates durability from search performance. It uses SQLite's write-ahead logging and can maintain a full-text index when the available SQLite build supports it. If FTS5 is unavailable, keyword search can degrade to a slower pattern scan while the structured history remains usable. That is an operational trade-off, not a change in what the conversation means: search may become slower, but the system does not need to replace the record with a lossy text summary.
Imagine a user asking QwenPaw to inspect a project, run several tools, and prepare a report. The live context contains the current request, recent model reasoning, tool calls, and outputs. Some tool output may be several pages long, and the model may no longer need every line on the next step. The durable history can retain that output while the live prompt keeps only a pointer or a compact representation. The important distinction is between removing content from the next request and deleting it from the system's recoverable record.
Scroll recovers pressure in stages
Scroll's compression pipeline is graduated because not all context is equally expensive or equally dangerous to remove. When token pressure crosses its configured trigger, Scroll first persists the live window and measures the model-facing input. It then tries the cheapest recovery: folding large, recoverable tool results from completed turns into short pointers. Completed output is often evidence that has already been consumed by the agent, while the current user request may still define the task. Replacing a completed result with a recovery pointer can reduce pressure without changing the active objective.
If that is not enough, Scroll splits the context into an evictable middle and a retained tail. The recent tail stays visible, and the current active turn is protected. Before rebuilding the live context, Scroll updates a bounded continuation summary from the material it is about to evict, indexes the evicted span, and then places an archived map beside the retained conversation. The summary helps carry forward task state, but it is not treated as the only copy of the past.
The order can be expressed as a state machine:
The diagram is not a promise that every conversation reaches every state. It shows the ordering logic. A small tool result may not be worth replacing. A manual compaction can request eviction directly. A provider can still reject an input that exceeds its limits. Scroll's job is to make each recovery step preserve as much meaning and recoverability as the remaining budget allows.
The active-turn rule is especially important. A token-based split that removes the newest user request while retaining an older reply can leave the model looking at an answer whose question is no longer visible. QwenPaw therefore anchors the current real user message and the in-progress assistant tail. Continuation messages injected by loop controls do not become a new task boundary. This keeps a long tool-running turn attached to the request that started it.
After ordinary eviction, Scroll can apply further pressure valves. It may fold remaining completed-turn tool results into pointers, omit active-turn reasoning that a successful earlier model call has already read, and, at a hard limit, fold active-turn results that have also been durably recorded and successfully seen. These actions are narrower than deleting the active task. They are request-time reductions applied only to evidence that the system has stronger grounds to recover.
A continuation summary also has a boundary. It is generated from bounded evidence and validated before becoming the current summary. If generation fails, times out, or returns a malformed candidate, Scroll preserves the previous valid summary rather than replacing it with an untrusted one. The exact evicted rows remain the stronger source for recovery. This is a useful pattern for long-running agents: a summary can help orientation, but it should not silently become the sole authority about what happened.
The order becomes clearer in a concrete pressure episode. Suppose the agent is reviewing a repository and a tool returns a large test log. The log may be useful evidence, but after the agent has inspected it, keeping every line in the next prompt competes with the user's current question and the output space needed for the next action. Scroll can persist the result, replace it with a recovery pointer, and recount the input. If that is enough, no dialogue is evicted at all. The system has reduced the working set while preserving a route to the complete log.
Now suppose the task continues through several tool calls and the prompt remains too large. The active user request and the assistant's current tool-running tail stay together, while older completed turns become the candidate middle. This is not simply “keep the last N messages.” A message boundary can cut across tool calls, and an older user request can be meaningless if its answer remains visible without it. Scroll repairs those boundaries so the archived span is a coherent piece of work rather than an arbitrary slice of tokens.
The continuation summary has a narrower job than a transcript. It carries compact task state—what the agent was doing, which decisions or milestones matter, and what the live turn needs to know—using bounded evidence from the evicted material. Because the summary is generated by a model, it is treated as a candidate that must satisfy local format and quality checks. If the candidate fails, the last valid summary remains. The exact rows and tool outputs are still the recovery authority. This makes the summary a useful index of meaning without turning model-generated compression into an unreviewable overwrite.
After the middle is evicted, the rebuilt prompt contains an archived representation plus the recent tail. Under continued pressure, Scroll can fold additional completed tool results and, later, reasoning or results from the active turn only when the system knows a successful model request has already consumed them. That “already seen” condition is important. Removing a result the model has not yet received would change the task; omitting one it has already processed is a request-time way to avoid sending the same evidence repeatedly. The live state remains richer than one particular wire request.
This also clarifies why pressure recovery cannot be reduced to a single threshold. The trigger tells Scroll when to act, but the appropriate response depends on what is reclaimable, what is active, what is durable, and how much room is needed for the next output. A small pointer may save many bytes; a short tool result may not be worth replacing. A manual compaction may intentionally evict older dialogue even when automatic pressure would first try lighter folding. A hard limit can require a more aggressive final step, but it still cannot justify discarding an unpersisted or unread turn as if it were safe.
The design has a cost: it performs persistence, token accounting, summaries, indexes, and sometimes repeated model-input preparation. That is more work than cutting the oldest messages. The payoff is that a long-running agent has a chance to recover the evidence behind its own compacted state. For QwenPaw, context management is therefore part of reliability engineering. The system spends computation and storage to avoid a cheaper but more damaging failure mode: confidently continuing from a prompt that no longer contains the question or evidence that gave the task its meaning.
The archive remains navigable
Eviction would still be dangerous if it left the model with no idea where the missing material went. Scroll addresses this with an eviction index rendered as one model-visible map. Newer evictions appear in lower tiers with more detail. When a tier fills, older blocks are carried upward and represented by endpoint lines. Every line retains a durable sequence span, so a compact headline is also an address to the full underlying turns.
This produces a deliberate distinction between an archive map and a live conversation. The map tells the model what has been evicted and how to expand it. A seam banner then states that the entries above are archived and that the live turn follows. That positional warning matters because the archived map and the current user request can both appear as user-role content to the model. Without an explicit boundary, a weak or distracted model might answer an old headline instead of the request in front of it.
The structured recall_history tool is the common front door for recovery. It can expand a sequence range, search for keywords, retrieve a particular tool call and result, or calculate a date difference. These are read-only, parameterized operations over the durable history rather than model-authored code. A page can be bounded by bytes and returned with a continuation cursor. The cursor is tied to the original request and result snapshot, so changing the query or using a stale snapshot does not quietly produce a different page under the same continuation token.
That design makes recall more like navigation than like asking the model to “remember harder.” The index provides a route. The sequence span identifies the rows. The recall operation returns bounded evidence. If more evidence is required, the agent follows the cursor or narrows the search. Exact tool output can be recovered without keeping that output in every subsequent model prompt.
There is a further safety boundary around advanced recall. Structured queries use scalar parameters and do not require a sandbox. A separate Python recall escape hatch can support more flexible inspection, but model-authored code needs isolation. If a usable sandbox is unavailable and an explicit unsafe fallback has not been enabled, QwenPaw does not wire Scroll in a way that would evict history it cannot safely read back. In that case, the builder can fall back to native context management, keeping more history live instead of creating an inaccessible archive.
What Scroll can and cannot guarantee
Scroll makes long-running work more recoverable; it does not make the context window infinite. The provider still imposes a hard input limit. A summary can fail. A database can be slow or degraded. History retention can remove old rows, and search quality depends on the available SQLite capabilities and the size of the store. The strategy is also optional: a configuration using native context management does not acquire Scroll's eviction index and recall behavior automatically.
The stronger claim is therefore precise. QwenPaw can separate a live working set from a durable, navigable conversation record when Scroll is selected and its recall path is runnable. That is materially different from blindly truncating old messages or replacing them with one opaque summary. It protects the current task, preserves evidence before eviction, and gives the agent a bounded route back to the past.
The distinction prepares a second memory question. Durable conversation history answers, “What exactly happened, and where can I retrieve it?” A personal knowledge base answers a different question: “What remains useful about the user, work, or repeated experience?” QwenPaw's next memory layer is designed around that second question, and it should not be confused with Scroll's exact archive.