Compaction threshold is scaled against the full context window, so it can sit above what the provider admits

[ModelkinIY]

An OpenAI-compatible provider rejects prompt + max_tokens > contextWindow. The output a request reserves is therefore room history can never occupy, but compaction-basic scales thresholdRatio against the whole window. On a route with a reserved output cap the threshold lands above the prompt the provider will accept: every turn is refused for context overflow while pressure never qualifies, so compaction never runs.

Concrete numbers from a vLLM route: window 158 368, output cap 16 384. Default thresholdRatio 0.8 puts the threshold at 126 694 tokens, but the provider only admits 141 984 tokens of prompt — the threshold is 0.89 of what is actually usable, and the run wedges before it is reached.

The fix is to subtract the reserved output before the ratios scale. A patch against master is here: — a reservedOutputTokens policy field defaulting to the adapter's per-request output cap, and to zero when none is configured, so existing configurations keep their current behavior.

I understand external PRs are not accepted right now; raising it here in case it is useful.

[argszero]

Verified against the current source (0.1.2-alpha.1, cd5ef81 — 0a53fb5 is a version-only release bump, same code), and your numbers check out. Confirmations plus one structural detail that strengthens the fix:

Threshold math confirmed. resolveCompactSpec computes thresholdTokens = Math.floor(contextWindow * policy.thresholdRatio) (packages/compaction/compaction-basic/src/config.ts:144) with no output reservation subtracted. With your vLLM numbers: 158,368 × 0.8 = 126,694, while the provider admits 158,368 − 16,384 = 141,984 prompt tokens — so the pre-step trigger fires at 126,694 / 141,984 ≈ 0.892 of the actually-usable window. Both the agent/pre-step pressure hook (compaction-basic/src/index.ts:147) and the overflow-recovery path resolve the same spec from context.contextWindow alone (:300-303).

Structural gap (adds to your patch rationale): the model catalog already carries the output cap. LlmDiscoveredModel keeps contextWindow and maxTokens side by side (packages/llm/llm/src/index.ts:605-606), and resolveModelInfo even surfaces the adapter's per-request output cap as defaultMaxTokens (:765-771). What is dropped is the forward path: the resolved context object exposes only { contextWindow } (:768), so resolveCompactSpec can never see the reservation. Your reservedOutputTokens policy field is a good escape hatch; the natural default you describe ("the adapter's per-request output cap") is literally the defaultMaxTokens already resolved at that layer — forwarding it through the pressure context would cover the common case without any configuration.

One nuance on "compaction never runs": there is a post-failure backstop. Both adapters classify provider overflow wording into CONTEXT_WINDOW_EXCEEDED (llm-deepseek/src/adapter.ts:339, llm-pi-ai/src/stream.ts:75-95; the classifier at llm/src/error.ts:80 matches the standard "maximum context length" phrasing), and the agent/request-error handler (compaction-basic/src/index.ts:179) compacts with the context-overflow trigger and retries (maxOverflowRetries defaults to 1, config.ts:110). So a run sitting at the ceiling does recover — but only after burning a refused request per episode, and it preserves the original error once retries are exhausted. Your proactive fix removes that failed round-trip entirely; today the pre-step trigger just never qualifies.