Skip to content

Failed model-limit lookup falls back to 200K and prematurely compacts large-context models at ~160K #85

Description

@WhiteGiverMa

Summary

In opencode-supermemory@2.0.13, a failed initial model-limit lookup causes proactive compaction to use a hard-coded 200,000-token context window. With the default compactionThreshold: 0.8, a model advertising a ~1M context window can consequently be compacted at ~160K tokens, well before OpenCode's native budget requires it.

This is related to #69, but the specific failure here is missing model metadata being treated as a known 200K window, rather than a smaller compaction model or a provider context-overflow response.

Environment

  • opencode-supermemory 2.0.13 (npm package)
  • OpenCode 1.18.30
  • Observed on Windows; the same plugin implementation is installed on WSL
  • Host configuration: "compaction": { "auto": true, "prune": false }
  • Model metadata: context 1,050,000; input 922,000; output 128,000

Observed evidence

Two real compaction events were correlated between the plugin log and the OpenCode session database. Session identifiers and local paths are intentionally omitted:

Plugin totalUsed Plugin contextLimit threshold usageRatio Observed action
164,951 200,000 0.8 0.824755 [compaction] triggering compaction
162,720 200,000 0.8 0.8136 [compaction] triggering compaction

The preceding model responses completed successfully, without context-overflow errors. The plugin log also contains Failed to fetch model limits with TypeError: fetch failed / TypeError: terminated. Earlier instances handling the same session used the correct 1,050,000 window; later checks used 200,000.

The failed-fetch log entries do not identify their plugin instance/directory, so the exact failed HTTP request cannot be attributed to each empty cache. However, the fallback value and resulting compaction are directly logged and match the database events.

The resulting compaction parts have auto: false: the plugin calls session.summarize() without an auto field, and the host defaults the request flag to false. That field alone therefore does not establish that a human manually requested compaction.

Code path

References pinned to the source corresponding to the installed release:

Reproduction outline

  1. Use a model whose actual host metadata has a context window larger than 200K.
  2. Make the plugin's initial ctx.client.provider.list() fail or return no matching model. A stubbed rejection is sufficient to exercise the lookup-failure condition.
  3. Deliver a completed assistant message.updated event with provider/model IDs and tokens.input + tokens.cache.read + tokens.output above 160K but below the host's real compaction budget.
  4. Observe the plugin selecting contextLimit: 200000 and requesting session.summarize().

Expected behavior / suggested fix

  • Unknown model context should not be treated as a known 200K limit. Skip plugin-initiated compaction until valid metadata is available.
  • Allow recovery from an initial metadata-fetch failure instead of keeping an empty cache for the instance lifetime.
  • Preferably provide an independent opt-out for plugin-initiated compaction while retaining recall, conversation capture, and capture of completed host summaries. Let OpenCode own compaction timing in that mode.

Setting compactionThreshold: 1 is not a reliable workaround for this failure: an empty cache still causes compaction at 200K. Setting it to 0 is also not an opt-out; validation restores 0.8. Disabling host compaction.auto does not prevent the plugin from explicitly requesting summarization.

Local mitigation and verification

A local mitigation removes the plugin's proactive trigger and continuation injection, while retaining memory features and passively capturing successfully completed host summaries by their exact message ID. Duplicate completion events are deduplicated.

The modified build was exercised against real isolated OpenCode 1.18.30 processes on both Windows and WSL, using local mock model and memory APIs: a 180K-input response did not cause plugin compaction; memory injection and conversation capture continued working; an explicit host compaction saved one summary without an extra plugin-generated continuation. This verifies the local mitigation, not the remote provider's maximum supported context size.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions