Auto-compaction fires after every tool-call step for Ollama (openai-compatible) provider, even when nowhere near context limit #49965

Bug: Auto-compaction fires after every tool-call step for the Ollama (openai-compatible) provider, even when nowhere near the context limit

Summary

When using a local model through a custom openai-compatible provider (Ollama), opencode's auto-compaction runs unconditionally after every single step-finish with reason: "tool-calls" — even when token usage is a small fraction of the configured context window (limit.context). The compaction event itself is logged with "overflow": false, confirming opencode's own overflow check does not think compaction is needed, yet it runs anyway.

This does not happen with other providers (verified with a GitHub Copilot / Claude Sonnet session using the same agent and same task pattern — zero compaction-agent invocations in the entire session).

The extra compaction round-trip injects a synthetic "Continue if you have next steps, or stop" message after summarizing. Smaller/local models frequently misinterpret this as a cue to stop and ask for clarification instead of continuing the tool-call loop, effectively breaking multi-step agentic tasks after almost every tool call.

Environment

• opencode version: 1.18.31
• Provider: custom ollama provider using @ai-sdk/openai-compatible, pointed at a local Ollama server (v0.32.15)
• Models tested: glm-4.7-agent (custom Modelfile, num_ctx: 32768), qwen3:32b — same behavior on both
• opencode.json model entry for the affected model:

  "glm-4.7-agent": {
    "name": "GLM 4.7 Agent (local)",
    "tool_call": true,
    "reasoning": true,
    "cost": { "input": 0, "output": 0 },
    "limit": { "context": 32768, "output": 32768 },
    "options": { "num_ctx": 32768, "temperature": 0.1 }
  }

Evidence (from local opencode.db)

Sequence of parts for a single assistant turn using the Ollama provider:

{"reason":"tool-calls","type":"step-finish","tokens":{"total":6478,"input":6266,"output":212,"reasoning":0,"cache":{"write":0,"read":0}},"cost":0}
{"type":"compaction","auto":true,"overflow":false}

Token usage here is 6478 out of a configured 32768 context limit (~20%) — nowhere near overflow — yet the compaction agent still runs immediately afterward. This repeats after every subsequent tool call in the session, each time logging "overflow": false.

For comparison, an equivalent session using the same agent/task pattern but with github-copilot/claude-sonnet-5 shows zero compaction-agent messages across the whole session (SELECT count(*) FROM message WHERE agent='compaction' → 0), confirming the behavior is provider-specific rather than a general agent-loop issue.

Impact

• Every tool call costs an extra full model round-trip (summarization + continuation prompt), which is especially costly on local/slower models.
• Local/smaller models often respond to the synthetic "Continue if you have next steps, or stop" message by stopping and asking for clarification rather than continuing autonomously, which breaks multi-step tool-calling tasks (e.g. "create a project, init git, add files" stops after the first mkdir/tool call).

Steps to reproduce

1. Configure a custom openai-compatible provider pointing at a local Ollama server, with an explicit limit.context well above expected usage (e.g. 32768).
2. Start a task that requires 2+ sequential tool calls (e.g. "create a new project folder, init git, create a README").
3. Observe that after the first tool call's step-finish (tool-calls), a compaction part is logged immediately with "overflow": false, followed by a full summarization turn and a synthetic continuation prompt.
4. Compare against the same task/agent using a different (non-Ollama) provider — no compaction event is logged.

Workaround

Setting "compaction": { "auto": false } in opencode.json stops the unwanted compaction entirely, at the cost of losing real overflow protection for genuinely long sessions.

Suggested fix direction

The auto-compaction trigger condition appears to evaluate incorrectly (or not at all — defaulting to "always compact") for the openai-compatible provider path specifically, independent of the actual overflow computation used for the log field. It would help to align the trigger check with the same overflow value that's already being logged, rather than firing unconditionally for this provider type.