Compaction request exceeds context window on high-output models (v2)

[bbartels]

Description

A V2 session using a custom OpenAI-compatible model reached about 236k of its 299,964-token context window (79%). Automatic compaction did not run, and /compact failed because the provider reported that the prompt plus requested output exceeded the context limit.

The model advertises a 131,072-token output limit. SessionCompaction.required() caps its reserved output budget at 32,000, but the compaction LLM.request() does not set generation.maxTokens. OpenAI-compatible lowering therefore leaves max_tokens unset, allowing the provider to use 131,072 instead.

Expected: the compaction request should use the same bounded output budget used to calculate the automatic-compaction threshold.

Before /compact, the model also returned finish=stop with no text or tool calls several times, leaving the TUI with no visible response. This may be a separate empty-response issue.

Plugins

No response

OpenCode version

0.0.0-next-17403

Steps to reproduce

1. Configure a custom OpenAI-compatible model with context limit 299964 and output limit 131072.
2. Grow a V2 session to approximately 236k tokens, displayed as 79% context usage.
3. Observe that automatic compaction does not run.
4. Run /compact.
5. Observe that the provider rejects the request because the prompt plus requested output exceeds the context window.

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[bbartels]

@kitlangton Similar to #36253

[github-actions]

This issue might be a duplicate of or closely related to existing issues. Please check:

• core: v2 compaction injects max_output_tokens and leaves oversized sessions unrecoverable #36253: v2 compaction injects max_output_tokens and leaves oversized sessions unrecoverable — same root area (compaction request construction + maxTokens interaction with OpenAI-compatible providers), now closed
• [BUG]: /compact can exceed model context before summarization on large sessions #29857: /compact can exceed model context before summarization on large sessions — similar symptom (compaction failing with context-length error), now closed

If those fixes did not address the specific case of an unset maxTokens on the compaction LLM.request() allowing the provider to use its full 131k output limit, this is a distinct and still-open issue.

[bbartels]

@rekram1-node Would you mind having a look? should be a straight-forward fix i believe :)

[Zaczero]

The docs already specify the bound this issue asks for —
https://opencode.ai/v2/docs/compaction states that during summary generation "tools disabled and at
most 4096 output tokens" are used. The tools half is implemented (tools: []); the output half is
not implemented anywhere.

At 39be1595993de57a5a667c86e21ff788a80ebbbe, the compaction request passes no generation field:

opencode/packages/core/src/session/compaction.ts

Lines 274 to 282 in 39be159

	.stream(
	LLM.request({
	model: plan.model,
	promptCacheKey: SessionPromptCacheKey.make(plan.session.id),
	http: { headers: SessionModelHeaders.make(plan.session, dependencies.app) },
	messages: [Message.user(plan.prompt)],
	tools: [],
	}),
	{

LLM.request accepts generation (packages/ai/src/llm.ts:41-51), and OpenAI-compatible lowering
reads it at packages/ai/src/protocols/open-responses.ts:573
(max_output_tokens: generation?.maxTokens), so an unset field leaves max_output_tokens absent and
the provider falls back to the model's own limit — 131,072 in this report.

4096 appears exactly once in packages/ai, as an Anthropic-protocol fallback used only when the
model catalog carries no output limit (anthropic-messages.ts:620). It never applies to the
OpenAI-compatible route, so on those providers compaction is unbounded on every model.

So this is a doc/code mismatch as much as a bug: the documented contract is 4096, and passing
generation: { maxTokens: 4096 } on the compaction request would implement it. Worth aligning with
SessionCompaction.required(), which already reserves Math.min(limits.output, 32_000) when
computing the threshold — the reservation and the actual request currently disagree.

[opencode-agent]

Fix merged into v2 in #51271. It landed after v2.0.18 and will be included in the next V2 release, v2.0.19. Compaction requests now send an explicit output-token limit fitted to the reserved context room instead of letting the provider choose an oversized default.