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
{{ message }}
Repository navigation
ACP usage_update reports size: 65536 for deepseek/deepseek-v4-pro (should be ~1M) #30120
When OpenCode runs deepseek/deepseek-v4-pro over ACP, the usage_update notification reports size: 65536 (64 K). DeepSeek V4 Pro advertises a 1 M context window, so ACP clients render a misleadingly tight "ctx N / 64 K" indicator and warn the user about running out of context far too early.
Same pattern as #16709 (MiMo-V2-Flash-TEE reporting 32 K instead of 262 K) and #20317 (GitHub Copilot Claude models reporting wrong context limits) — likely a stale or wrong entry in the model registry, but for a different provider/model pair.
Repro
OpenCode 1.15.11 launched with --model deepseek/deepseek-v4-pro:
size: 65536 is exactly 64 K — looks like a default/stale value rather than the model's real window.
Expected
size should reflect DeepSeek V4 Pro's actual context capacity (~1 M tokens). Whatever the canonical source is (models.dev entry, hard-coded provider config, etc.) needs the correct value.
Why this matters for clients
ACP clients (HAPI, Zed, Fabriqa, …) use size directly as the context-window denominator in their status bars. Reporting 64 K when the model can handle 1 M means:
the "% used" indicator pegs near 100% on prompts that are nowhere near the real ceiling,
compact/handoff warnings fire prematurely,
users may waste tokens trying to shrink prompts that were already fine.
The ACP size field discrepancy described here (65536 vs ~1M) appears to be a downstream symptom of the same stale model registry entry tracked in those issues.
looks like this was caused by a stale local models.dev cache rather than acp itself. current models.dev reports deepseek-v4-pro at 1m context, and acp just forwards model.limit.context as usage_update.size.
Activity
github-actions commentedon May 31, 2026
This issue might be a duplicate of existing issues. Please check:
The ACP
sizefield discrepancy described here (65536 vs ~1M) appears to be a downstream symptom of the same stale model registry entry tracked in those issues.nexxeln commentedon Jun 1, 2026
looks like this was caused by a stale local models.dev cache rather than acp itself. current models.dev reports deepseek-v4-pro at 1m context, and acp just forwards
model.limit.contextasusage_update.size.running
opencode models --refreshshould fix itf0d471 commentedon Jun 11, 2026
test