anomalyco / anomalyco/opencode

[FEATURE]: Add a config option to hide the compaction divider/marker in the TUI

Open
#45,389 0 comments 0 reactions 1 assignee View on GitHub

@simonklee is already working on this.

Since Aug 26, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Feature hasn't been suggested before.
  • I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request

When auto-compaction runs, the TUI renders a "Session compacted" divider in the message stream. As far as I can tell there's no config option to suppress it — I checked the full config schema and tui.json for something like a locale override or an env var that would hide the label, and found nothing.

This gets noisy fast when running against local/self-hosted models (llama.cpp, Ollama via @ai-sdk/openai-compatible), where compaction tends to fire much more often than it does against large cloud models — every compaction adds a visible divider that clutters the session view. It's a separate concern from the compaction reliability issues already tracked for local backends (#22792, #15533, #27924), but it compounds them: when compaction already fires more often and sometimes loops, having no way to quiet the visual noise makes it worse to work through.

Proposed solution: a config option under the existing compaction schema block (e.g. compaction.hideMarker, boolean, default false) that suppresses rendering of the divider while leaving the compaction event itself — summary generation, token accounting — unaffected.

Alternatives considered:

  • Patching the bundled opencode binary to no-op the divider render — works, but doesn't survive opencode upgrade and would need a custom reapplication script on every update, which isn't something most users want to maintain.
  • Living with the divider — acceptable, just noisy, especially in longer local-model sessions.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.