OpenClaw’s OpenCode Go Context-Window Bug Shows Why Local-Agent Stacks Need Metadata Discipline

Context windows are the easiest model feature to market and one of the easiest runtime features to get wrong. A provider says a model can handle one million tokens. A catalog row says the same thing. The user starts a long coding session expecting the agent to carry a large investigation. Then the runtime quietly treats the model like it has a 200K window and starts compacting history six times earlier than necessary. Congratulations: you bought a 1M-token model and operated it like a nervous 200K-token assistant with a summary habit.

That is the practical failure behind OpenClaw PR #92955. The patch fixes an opencode-go metadata bug where models with 1M-token context windows could be treated by synchronous lookup paths as if they had the default 200K-token context. The issue is not glamorous. It is also exactly the kind of runtime discipline that separates usable local-agent stacks from benchmark theater.

The numbers make the bug concrete. Issue #92912 reports that opencode-go plugin catalog rows included correct windows for models such as deepseek-v4-pro at 1,000,000 tokens, but the runtime context cache missed those rows. When resolveMemoryFlushContextWindowTokens() could not find accurate metadata, it fell back to DEFAULT_CONTEXT_TOKENS = 200,000. With a 24K reserve and 20K soft threshold, memory flush and preflight compaction could trigger around 156K tokens. With a real 1M window, that threshold should be roughly 956K.

Compaction is behavior, not bookkeeping

It is tempting to describe this as a display bug because users reportedly saw opencode-go/deepseek-v4-pro and opencode-go/deepseek-v4-flash around 195K instead of 977K in model listings. But the real damage is behavioral. Context-window metadata determines when an agent summarizes, how much history survives, when long-running tasks lose detail, and how much redundant prompt churn users pay for. A premature compaction is not just a smaller number in a UI. It changes the agent’s memory.

The live evidence in #92912 is exactly the sort of operator signal maintainers should prioritize: a 1M-token deepseek-v4-pro gateway session compacted around 204K tokens, with two compactions in 24 minutes. That is not theoretical. That is a user watching a long-window model behave like a short-window model in production. If the agent was investigating a bug, reviewing a large codebase, or carrying a multi-step refactor, each unnecessary compaction becomes an opportunity to lose nuance.

PR #92955 moves OpenCode Go model metadata toward a single source of truth by rebuilding the runtime catalog from extensions/opencode-go/openclaw.plugin.json instead of maintaining a separate hard-coded TypeScript list. It also lets synchronous resolveContextTokensForModel() consult bundled refreshable manifest rows after config/cache misses, so existing configured users can get correct thresholds without re-onboarding. That direction is right. Split catalogs drift. Drifted catalogs become runtime bugs.

The local-agent stack needs metadata governance

This lands at a useful moment because the market is suddenly serious about local and open coding-agent stacks: Gemma, Qwen, DeepSeek, Hermes-style runtimes, Ollama, OpenCode and its successors, Crush, terminal agents, and hosted/open-model hybrids. The conversation usually collapses into “which model is best?” That is the wrong first question for operators. The better question is whether the runtime understands the model it is using.

That means context window, max output, tokenizer assumptions, supported tool-call format, modality, provider base URL, auth shape, streaming behavior, retry semantics, and fallback behavior. If any of those are wrong, model quality becomes secondary. A great model with wrong metadata will be scheduled, compacted, prompted, retried, or billed incorrectly. The agent will not fail because the model is dumb. It will fail because the runtime lied to itself.

The OpenCode ecosystem context reinforces the point. The original opencode-ai/opencode repository is now archived and points users to Charmbracelet’s crush, which had more than 25,000 stars at research time, while the archived repo had nearly 13,000. The open terminal-agent wedge is alive, but project names and integrations are moving. In that environment, provider plugins must be disciplined about metadata because users are stitching together fast-changing runtimes, catalogs, and model backends.

What operators should check today

If you run OpenClaw with opencode-go, inspect the effective context windows shown for configured models. If a 1M-token model appears around 195K or 200K, assume compaction thresholds are wrong. Watch session logs for early memory flushes and preflight compaction. If the fix has not landed in your version, add explicit provider model metadata as a workaround where possible, or avoid relying on long-window behavior for tasks that cannot tolerate aggressive summarization.

Platform builders should take the broader lesson: provider plugins should not carry duplicated model catalogs unless there is a compelling reason and a test proving they stay in sync. Catalog data should be loaded from one manifest, validated through both async and sync lookup paths, and exercised in tests that verify actual runtime thresholds, not just displayed model rows. The failure mode here crossed exactly that boundary: a row could exist in one place and still be missed by the path that determined compaction behavior.

The caveat is that #92955 was still marked status: needs proof at research time. ClawSweeper flagged one added, six removed, and ten changed OpenCode Go catalog rows, plus provider config/default onboarding changes. That deserves runtime verification. Catalog patches can fix one drift problem while creating another if rows disappear, names change, or existing users get surprising defaults. The direction is strong; the proof should be boring and concrete.

The editorial read: local coding-agent coverage should stop treating context windows as brochure copy. A 1M-token model is only a 1M-token model if the runtime’s metadata, compaction thresholds, and provider catalog all agree. Otherwise it is just an expensive number in a README.

Sources: OpenClaw PR #92955, OpenClaw issue #92912, OpenClaw PR #92913, Charmbracelet Crush, archived OpenCode repo