You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using opencode for really long sessions its database in .local\share\opencode just keeps growing.
So, maybe a solution could be to let the history be as long as the last 2 compacts plus the actual chat
If I understand correctly, you'd like OpenCode to stop the local database (~/.local/share/opencode) from growing without limit during very long sessions. You suggest only keeping history from the last two compactions plus the current conversation, and deleting older messages.
OpenCode currently keeps the full session history, so steady growth is expected. A retention or pruning option would be a new feature, so I've marked this as a feature request for the maintainers to consider.
It would help to know which version you're on (opencode --version) and roughly how large the database gets. Note that only critical fixes go into 1.x, so new features like this would land in 2.x.
Exactly, my version is 1.19.4. I ended up with a 30GB database. I think it can be a critical fix, because opencode just says "Failed to fetch" without checking the logs, someone could think that it just doesnt work.
The active-session case here is distinct from #57882, which expires whole inactive sessions, and #56365, which reclaims free SQLite pages. #16101 already discusses general storage statistics and lifecycle tooling; I would keep those out of a separate patch here.
For the two-compaction window, I suggest an opt-in, per-session retention preview as the first increment:
Start at the second-newest completed compaction, retaining the subsequent conversation; failed/running compactions do not advance the boundary.
Expand the retained set for metadata.keepID references. Current summaries reconstruct recent text from older message rows, so those rows cannot simply be deleted.
Preserve the history needed for native-compaction fallback. A model switch or undecodable native window can require the original transcript back to a local summary. For native-only histories, the preview should report that a safe two-checkpoint bound is unavailable rather than propose dropping that fallback.
These dependencies are visible in the history reader at 8482dbf. The preview would show the resulting boundary and why extra rows remain; it would perform no deletion. Existing retention would remain unchanged by default.
A later explicit apply operation would need agreed archive/history-loss semantics: exports include the settled transcript, and old fork/revert boundaries would no longer be available after deleting their messages. Validation would cover repeated/failed compactions, keepID, native model switching, legacy schemas, and export/fork/revert behavior.
Would maintainers approve this checkpoint-retention preview scope? This is source analysis of the development tree, not a diagnosis of the reported v1.19.4 30 GB database or its “Failed to fetch” error.
Activity
opencode-agent commentedon Oct 22, 2026
Thanks for the suggestion, @leonel-mona!
If I understand correctly, you'd like OpenCode to stop the local database (
~/.local/share/opencode) from growing without limit during very long sessions. You suggest only keeping history from the last two compactions plus the current conversation, and deleting older messages.OpenCode currently keeps the full session history, so steady growth is expected. A retention or pruning option would be a new feature, so I've marked this as a feature request for the maintainers to consider.
It would help to know which version you're on (
opencode --version) and roughly how large the database gets. Note that only critical fixes go into 1.x, so new features like this would land in 2.x.leonel-mona commentedon Oct 22, 2026
Exactly, my version is 1.19.4. I ended up with a 30GB database. I think it can be a critical fix, because opencode just says "Failed to fetch" without checking the logs, someone could think that it just doesnt work.
Dante-dan commentedon Oct 23, 2026
The active-session case here is distinct from #57882, which expires whole inactive sessions, and #56365, which reclaims free SQLite pages. #16101 already discusses general storage statistics and lifecycle tooling; I would keep those out of a separate patch here.
For the two-compaction window, I suggest an opt-in, per-session retention preview as the first increment:
metadata.keepIDreferences. Current summaries reconstruct recent text from older message rows, so those rows cannot simply be deleted.These dependencies are visible in the history reader at
8482dbf. The preview would show the resulting boundary and why extra rows remain; it would perform no deletion. Existing retention would remain unchanged by default.A later explicit apply operation would need agreed archive/history-loss semantics: exports include the settled transcript, and old fork/revert boundaries would no longer be available after deleting their messages. Validation would cover repeated/failed compactions,
keepID, native model switching, legacy schemas, and export/fork/revert behavior.Would maintainers approve this checkpoint-retention preview scope? This is source analysis of the development tree, not a diagnosis of the reported v1.19.4 30 GB database or its “Failed to fetch” error.