Compaction cannot rescue an oversized session — the summarization request itself exceeds the provider request-size limit (HTTP 413)

[Ragnoryok1]

Summary. A long session with heavy tool output can reach a state where every request fails with HTTP 413 (payload too large), and automatic compaction cannot recover it: the summarization call replays the compacted region in one request and hits the same limit. The session becomes unusable — no turn succeeds, compaction fails with the same 413, and a fork inherits the corpus (isSeeded: true), so it fails from its first turn.

Environment

• dsh 0.1.7-alpha.2 launched from source, Windows 11 x64, bundled Node 24.17.0
• provider deepseek-official, model deepseek-v4-flash, declared contextWindow: 1000000 in the provider config
• session shape: 126 turns, ~20,800 events (about 3,900 of them tool/result); decompressed corpus ≈ 56 MB, stored .jsonl.zstd ≈ 8 MB

Observed

• At turn 126: compaction/prune shadows a few old results (~19K tokens), then compaction/start → compaction/end with error: "DeepSeek Messages request failed (413)", and the routed request ends with the same 413 (turn/end, reason error).
• Retrying does not help — the same 413 repeats (hundreds of occurrences in the log), so the session cannot make progress.
• Forking does not help either: the fork is seeded with the parent's history and 413s on its first request.

Suspected cause (from source)

• packages/compaction/compaction-basic/src/summarizer.ts: summarizeWithLlm() builds ONE ctx.llm.stream() call carrying the replayed conversation prefix (input.messages: system head plus the whole shadowed region) plus the compaction instruction. The replay is intentional (prefix-cache reuse), but there is no chunking and no size guard.
• packages/compaction/compaction-basic/src/config.ts: budgeting is token-only — thresholdRatio default 0.8, retainRatio default 0.16, headroomTokens default 65,536, maxTokens defaulting to the headroom. packages/compaction/compaction-basic/src/region.ts picks the region purely by token counts; neither module accounts for request bytes.
• With a declared 1M-token window the threshold fires at ~800K tokens — several MB of JSON on the wire — which the provider rejects with 413. The token budget and the transport limit disagree.

Impact. Once a session crosses the transport limit there is no way out: automatic compaction cannot run, /compact presumably fails the same way, forks inherit the problem, and the only option is to abandon the session — losing continuity for exactly the long-running work the feature exists for.

Suggested directions

1. Bound the summarization request by bytes as well as tokens — summarize the region in chunks (progressive/hierarchical: compact the oldest part first, then repeat) instead of replaying all of it at once.
2. Derive the compaction trigger from the transport limit too, so the summarization request always fits.
3. Treat 413 as terminal rather than retryable, with an actionable message ("session too large to send; start a new session or reduce the model's declared contextWindow").
4. Warn or refuse when forking a session whose corpus already exceeds the transport limit.

Question. Is there a supported way today to bound a session's request size, or to recover an oversized session (trim / partial compaction)? If yes, please document it; if not, would a byte-aware trigger plus chunked summarization be acceptable? I can share a redacted event excerpt (event names, sizes, error strings) if that helps.

Workaround for anyone hitting this: lower the provider model's declared contextWindow (for example to 131,072–262,144) so compaction triggers much earlier and new sessions stay inside the provider's request limit. The oversized session itself stays unusable.

[argszero]

Your read of summarizer.ts, config.ts, and region.ts is right on all three counts, and I can confirm the fork-inheritance half from the fork path. What decides whether this is recoverable is one classification step your report doesn't mention — a 413 does not become CONTEXT_WINDOW_EXCEEDED here, and the recovery written for exactly this class is gated on that code. Below: the mechanism, the classification fork, a direct answer to your question, and what a plugin can and cannot do.

The mechanism, confirmed

• packages/compaction/compaction-basic/src/summarizer.ts:145-155 builds one RequestMessage[] — [...input.messages, <instruction>] — and :162 sends it through a single ctx.llm.stream(options) (purpose: 'compaction'). The docstring at :110-115 states the replay is deliberate ("so the provider's warm prefix cache is reused"). No chunking, no size guard.
• config.ts:20,23: DEFAULT_THRESHOLD_RATIO = 0.8, DEFAULT_RETAIN_RATIO = 0.16; region.ts selects the region from TokenMeasurement alone — token-only, as you say.
• With contextWindow: 1000000, the trigger fires around 800K tokens. 8×10⁵ tokens is several MB of JSON, and nothing in the pipeline compares that to any transport limit. The only byte budget in the entire LLM layer is for images — LlmImageRequestBudget.maxBytes (packages/llm/llm/src/types.ts:361, priced in content.ts:286-320). A text request has no byte bound anywhere.

The step that decides the outcome: 413 is classified by body wording, not by status

providerError (packages/llm/llm-deepseek/src/transport.ts) checks in this order:

:32  else if (isContextWindowExceededError(detail)) code = 'CONTEXT_WINDOW_EXCEEDED'
:33  else if (status === 400 || status === 413 || type === 'invalid_request_error') code = 'INVALID_REQUEST'

So a 413 lands on INVALID_REQUEST unless the provider's own message text matches one of the overflow regexes (llm/src/error.ts:54-85: STRUCTURED_CONTEXT_OVERFLOW, TOO_LARGE_FOR_CONTEXT, EXCEEDS_MODEL_CONTEXT, plus two literals). And the message you quote —

DeepSeek Messages request failed (413)

— is the fallback string, used only when the response body carried no error.message (transport.ts:24). An empty detail matches none of those regexes, so your session's code was INVALID_REQUEST.

Why that is the whole story:

1. The overflow recovery is gated on the other code. compaction-basic/src/index.ts:194:

   if (failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE || signal.aborted) return next()

   On INVALID_REQUEST it takes next() — the recovery never runs. The harness has a compaction-based escape for "request too large", and this failure class is classified out of it.
2. Nothing else retries it either. INVALID_REQUEST is not in DEFAULT_RETRYABLE_CODES (llm/src/retry-policy.ts:17-23: empty-response, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT). So the hundreds of 413s in your log are not a retry loop: they are repeated turns/attempts each re-issuing the same oversized request. Worth stating that way — it means the count is a symptom of the loop never terminating, not of a backoff that eventually gives up.

This is the actionable part for maintainers: a 413 with no body message is undecidable between "the model's context is too small" and "the request exceeded a transport limit" — and the default branch (400/413 → INVALID_REQUEST) is the one that silently disables recovery. Your suggestion 3 asks for a terminal, actionable error; the stronger version is that this case needs its own code, because a default here is indistinguishable from "no such condition exists".

Your question, answered

Is there a supported way today to bound a session's request size, or to recover an oversized session?

To bound it, no. No request-size guard exists (above), and the config surface is token-only: thresholdRatio, headroomTokens, retainRatio, retainTokens, maxTokens and two retry counters (compactionRetries, maxOverflowRetries, both defaulting to 1, config.ts:105-106). Byte limits appear nowhere.

/compact does not help, and it is not a presumption — command-compact registers the slash command and calls ctx.compaction.compactNow(...) (packages/compaction/command-compact/src/index.ts:67), i.e. the same backend-independent compaction seam, hence the same summarizeWithLlm call and the same 413.

One real nuance: a failed compaction still shrinks the session durably. The model-free prune phase lands before the summarization call, and the overflow path says so explicitly (index.ts:~205-212): "A model-free prune can land before later summary work fails. That durable reduction is sufficient retry proof; do not discard it". That is why you saw compaction/prune shadow ~19K tokens before the failure. It is priced by characters per tool result (compaction-tool-result-pruner: thresholdChars/headChars/tailChars), so repeated attempts stop paying once every tool result is already under budget — it cannot free the assistant/user text that dominates an 800K-token region.

There is one way out today, and it is not a fork at the tail: branch from an early turn/end. The fork cut copies a prefix whose length is chosen at an explicit atSeq — latestCompletedPrefixBoundary then inheritedEventCount = SessionLogOffset(boundary + 1) (packages/core/session/src/fork.ts:74,273). Branching at, say, turn 20 of 126 carries ~20 turns into the child, whose corpus is small and which therefore works. That matches your observation precisely: a fork at the tail copies the whole oversized prefix by construction, so it fails on its first request exactly like the parent — the defect is a property of the copied bytes, not of the session's identity. Choosing an earlier atSeq trades the recent turns for a usable session.

And why your workaround works, since it is worth knowing rather than just applying: the trigger is a fraction of the window you declare (thresholdRatio 0.8), so a smaller declared contextWindow fires the trigger earlier and selects a smaller region — hence a smaller summarization request. Which is the general shape of the problem:

The declared contextWindow is used as the safety bound, but it is a token bound while the transport enforces a byte bound. Declaring a window larger than the transport can carry converts a recoverable overflow into an unrecoverable one — the better the model claims to be, the later the net fires, past the point of return.

That reframes your suggestion 2: it is not only "derive the trigger from the transport limit too", it is that the declared window is currently trusted as the request-size authority, and a second authority (bytes) is missing. Your suggestion 1 (chunked/hierarchical summarization) is the real fix and belongs in compaction-basic; the region.ts → summarizer.ts handoff is where a byte budget would have to be threaded.

What a plugin can and cannot do here — and one honest boundary

I scanned this against the public seams rather than assume:

• A plugin cannot chunk the region. The summarization input is the replayed prefix and its output replaces the region with the summary. Dropping input messages at the request seam (llm/stream does allow substituting the request) would silently summarize less than the region it claims to have condensed — content loss disguised as a summary. That fix belongs in core.
• What is plugin-mountable and non-lossy: the public llm/stream waterfall, discriminated by options.purpose === 'compaction' (set in summarizer.ts:157). There a plugin can (a) measure the outgoing request bytes before dispatch and emit one durable, actionable notice instead of N identical provider errors, and (b) recognise a size-worded INVALID_REQUEST (413, "payload too large", "length limit exceeded") and reclassify it to CONTEXT_WINDOW_EXCEEDED, which simply lets the recovery above run: prune (durable, model-free) → summarize → retry, bounded by maxOverflowRetries. On a normal turn's 413 that reclassification is exactly right; on the compaction call itself it is bounded and each attempt still lands the prune. It is a bounded mitigation, not the fix — if the region is far over the transport limit, the summarization request fails again, and the honest limit is that no plugin can make bytes smaller.
• The sibling shape of this translation is already published as a plugin: @argszero/cordis-plugin-length-stop-overflow reclassifies a truncation (finish_reason: length → the harness's max-tokens terminal) into CONTEXT_WINDOW_EXCEEDED for the same reason — to open the compaction gate the code is gated on. It does not cover your case today (different code, different trigger); the size-worded trigger is the same translation applied to a second input, and I am adding it rather than claiming it exists.

Your suggestion 4 (refuse or warn when forking a corpus already past the limit) is the cheapest of the four and is also plugin-mountable — agent/created sees the child's inheritedEventCount — but it wants the byte measurement from (a) to be meaningful.

[Ragnoryok1]

Thanks — the classification step is the piece my report was missing, and it changes the conclusion. I've corrected the retry framing: INVALID_REQUEST is not in DEFAULT_RETRYABLE_CODES, so the repeated 413s are re-issued turns, not a backoff that never gives up.

I ran your citations against 0.1.7-alpha.2 rather than take them on faith; most match exactly:

• compaction-basic/src/index.ts:194 — the failure.code !== CONTEXT_WINDOW_EXCEEDED_CODE gate, verbatim.
• config.ts:105-106 — compactionRetries and maxOverflowRetries, both defaulting to 1.
• llm-deepseek/src/transport.ts:32-33 — the context-overflow check ahead of 400 | 413 | invalid_request_error → INVALID_REQUEST; the fallback string sits at :25 in this revision.
• llm/src/retry-policy.ts:18-24 — the same five retryable codes.
• llm/src/error.ts:58 — TOO_LARGE_FOR_CONTEXT.
• command-compact/src/index.ts:67 — ctx.compaction.compactNow(...).
• llm/src/types.ts:361 — the image-only byte budget.
• summarizer.ts:155/159/162 — one request, purpose: 'compaction'.

One divergence: core/session/src/fork.ts is 28 lines in this revision, so :74/:273 don't land here; the mechanism is present as buildForkSeed(events, boundary) → events.slice(0, boundary + 1) plus the inherited-cut marker. If your line numbers come from another revision, that's worth knowing for anyone following the thread.

I've already applied two workarounds — branching from an early turn, and lowering the provider model's declared contextWindow. If you can suggest anything else worth trying, I'll gladly test it.

[argszero]

@argszero/cordis-plugin-length-stop-overflow@0.2.0 is published — it restores the classification you identified, so the recovery gate actually runs on a 413.

npm i @argszero/cordis-plugin-length-stop-overflow

- insert:
    - id: length-stop-overflow
      name: '@argszero/cordis-plugin-length-stop-overflow'

Source (MIT): https://github.com/argszero/cordis-plugin-length-stop-overflow — the sibling I cited earlier in this thread (@argszero/cordis-plugin-length-stop-overflow@0.1.0) covers only the length-stop half of the problem; 0.2.0 adds exactly the half that applies here.

What it does

It observes the public llm/stream waterfall and rewrites the terminal frame when the request was refused for its size:

error finish (INVALID_REQUEST + 413 / size wording)  ->  { kind: 'error', failure: { code: 'CONTEXT_WINDOW_EXCEEDED', … } }

That is the whole mechanism, and it is deliberately the smallest one that works: compaction-basic/src/index.ts:194 is the only gate in the built-in recovery, and it reads that one code. The rewrite is exact rather than approximate because the synthesized failure carries the harness' own CONTEXT_WINDOW_EXCEEDED_CODE imported by value from @deepseek-ai/dsh-llm — plugin and core cannot disagree about which code the gate keys on.

One terminal frame in, one out. The upstream failure is replaced, never followed by a second verdict, and the plugin never re-dispatches a request of its own — the retry decision stays with the loop and its maxOverflowRetries bound.

The retry verdict does not change. CONTEXT_WINDOW_EXCEEDED is not in DEFAULT_RETRYABLE_CODES either (llm/src/retry-policy.ts:18-24, the same five codes you verified), so nothing here gains a backoff loop: the rewrite changes the class, not the number of attempts.

How it decides — not by code

INVALID_REQUEST is a bag: llm-deepseek/src/transport.ts:32-33 puts malformed, forbidden and oversized requests in it together. So the code is necessary but never sufficient, and the reading comes from the evidence instead:

• the adapter reported status 413 — Content Too Large by definition, no reading needed;
• the failure text spells 413 — this is how a body-less refusal survives (DeepSeek Messages request failed (413)) and how a proxy in front of the provider reports it (413 Request Entity Too Large);
• a request-rejection code plus size wording plus a noun naming the request (request, prompt, payload, body, content, input, messages, conversation).

That last conjunct is what keeps it honest. It never claims:

• an aborted finish — that is the caller's decision, not a provider verdict, even when the failure carries a rejection code;
• a failure whose code another recovery already owns — CONTEXT_WINDOW_EXCEEDED itself, and IMAGE_OFFLOAD_REQUIRED (the image path offloads what it named and retries; rewriting it would take the recovery away from the thing that can fix it);
• a size complaint about something other than the request — image too large, Failed to load image or audio file — which belongs to @deepseek-ai/dsh-compaction-image-offload, not to compaction;
• a token bound (input tokens exceeded max_prompt_tokens) — a different budget, read by a different classifier;
• a rate limit, a transport failure, or a malformed request that merely mentions a size noun.

classifyOversizeRequests: false turns this trigger off without touching the length-stop one.

The byte number your report says is missing

The plugin measures what it can see where it can see it — JSON.stringify(options.messages) in UTF-8 — and attaches it to the failure and the log line:

… refused the request as too large (HTTP 413): DeepSeek Messages request failed (413); the request carried 59 MB (61,800,448 bytes) of message JSON (an estimate of this component — the wire form belongs to the adapter). Reclassified as CONTEXT_WINDOW_EXCEEDED …

Two caveats, both stated in the message itself: it is one component of the request measured at the waterfall seam (adapters re-serialize into their own protocol and dsh-attachment may re-encode request images, so the wire payload is not observable from there), and it runs only when a detection fires, so a healthy request is never serialized.

It also means the summarization call's own refusal is labelled like this in your compaction/end record rather than as an unattributed (413) — the two ends of the failure now name the same cause.

What it does not fix

Your comparison is right, and the plugin does not close it. When the summarization request is itself over the transport limit, no classification can rescue the session: the summarizer replays the region in one request (summarizer.ts:145-162, documented at :110-115 as deliberate, so the provider's warm prefix cache is reused), that request is refused too, compaction-basic logs context-overflow compaction failed …, and the turn ends — bounded by maxOverflowRetries, no loop. What changes there is the label and the message: a terminal CONTEXT_WINDOW_EXCEEDED carrying the provider's own sentence, the status, the request id and a measured size, instead of INVALID_REQUEST on DeepSeek Messages request failed (413) — your suggested direction 3, and the reason a reader of the log can now tell what was refused.

Where it does help is a session that has only just crossed the limit: the summarization request is smaller than the full one (it excludes the retained tail, and your log shows a model-free compaction/prune landing first), so the recovery can succeed there. In the state you captured — ≈56 MB decompressed — it will not, and branching from an early turn/end remains the exit, as before.

Bounding the summarization request by bytes is a core change and stays a core change: nothing at the plugin seam can chunk that region without losing content. The one core change I would still argue for is your direction 2 — deriving the compaction trigger from the transport limit as well as the token budget.

Verification

• 77 tests, three layers, each with a control arm. The recovery suite drives your exact failure (INVALID_REQUEST, DeepSeek Messages request failed (413), status 413) through the real LlmRuntime and then through the real @deepseek-ai/dsh-compaction-basic mounted with the services it injects: the failure must pass its failure.code gate, reach compactIfNeeded with trigger context-overflow, and come back as { kind: 'retry' }. The unmounted arm of the same script is the defect — INVALID_REQUEST, nothing compacted, no retry requested.
• The second trigger was defect-injected after it was written: disabling the status reading fails 12 tests, measuring on every finish fails 1, claiming aborted fails 2, claiming another recovery's code fails 1. Two further injections were rejected by the compiler before they could run.
• Mount with mode: 'warn' first if you want to see how often your own traffic hits either trigger before it changes behaviour.

[argszero]

You're right on both counts, and one of them is a real error on my side — thank you for running them against the tree instead of taking them on faith.

The fork coordinates were mis-attributed. In 0.1.7-alpha.2 (00102833df), packages/core/session/src/fork.ts is 30 lines: buildForkSeed at :21, events.slice(0, boundary + 1) at :22, the session/end-seed marker at :23-28, openTurnClosers(prefix, { kind: 'forked' }) at :29. latestCompletedPrefixBoundary is not in that file at all — it is packages/api/session-controller/src/commands.ts:74, applied at :245 (atSeq ?? latestCompletedPrefixBoundary(source.events)), and inheritedEventCount: SessionLogOffset(boundary + 1) is :273 of that same file. So the line number 273 was right and the path was wrong; 74 was right in the other package. The in-process path is the same shape: Session.fork (packages/core/session/src/index.ts:1237), seed :1245, inheritedEventCount :1248. Mechanism confirmed, coordinate pair mis-attributed — and transport.ts:25 for the fallback string is your reading, not mine; :24 was off by one.

Two more things worth trying, both read off that same cut.

1. Cut finer than a turn. atSeq is not restricted to a turn boundary: commands.ts:246 only requires the seq to exist and be contiguous (source.events[boundary]?.seq !== boundary), and buildForkSeed closes whatever open tail results with synthetic forked closers (:29). So the cut can land on the seq immediately before the event that put the request over the limit, keeping the rest of that turn instead of retreating to an early turn boundary — the same escape, one turn less context lost. It is testable in one command: fork with an explicit atSeq, then check the child's first request.

2. Make the model-free prune bite harder. compaction-tool-result-pruner defaults thresholdChars: 8192 / headChars: 4096 / tailChars: 1024 (src/config.ts:10-14, under the invariant headChars + marker + tailChars <= thresholdChars). Setting thresholdChars: 256, headChars: 0, tailChars: 0 collapses every tool result to the marker on the next prune. That matters here because the prune phase runs before the summarization request and lands durably, and durable progress past the generation watermark is exactly what licenses the retry (compaction-basic/src/index.ts:209-222) — so each attempt can shrink the region further and pull the summarization request back under the transport limit where the previous attempt could not. The bound, stated plainly: it reaches tool-result text only, and the user/assistant text that dominates an 800K-token region is not in its remit, so it will not rescue the ≈56 MB state you captured.

One cheap probe for the number your report says is missing: @argszero/cordis-plugin-length-stop-overflow@0.2.0 (published, reply above) mounted with mode: 'warn' prints its measured request size on the next 413 without changing any behaviour — that tells you which component dominates the bytes before you spend a fork on it.

[Ragnoryok1]

Thanks — I've installed and mounted 0.2.0 with mode: 'warn' so I can measure my own request sizes before letting it change behaviour. I'll come back with the numbers once my traffic hits a trigger. The fork coordinate correction is useful too: I'll try cutting at an explicit atSeq right before the event that pushed the request over the limit, instead of retreating to a turn boundary.