Repository navigation
Description
The issue
The Claude Agent provider reports limit.context: 200000 for every model, while Claude Code reports 1M for the same models. OpenCode runs compaction for Claude Agent because Claude Code's own auto-compact is disabled. With the default 15% buffer, compaction starts near 170K instead of near 850K.
Context discovery itself works. The saved model catalog is what's wrong: it had no contextWindow on any model, and nothing ever re-runs the check to fill it in.
registerinprovider.tsonly runs the full check at startup when the saved catalog is empty. A catalog full of models but without windows never triggers it.- When a chat starts, Claude Code's model list has no context windows.
fromClaudeonly keeps windows from the plugin's in-memory copy, so a copy without windows saves a catalog without them. - Each server process loads the catalog once per directory and never re-reads it, so a stale copy can keep serving 200K, or write over a good catalog.
Reproduce
-
Connect Claude Agent with a Claude Pro login (Claude Code 2.1.309).
-
OpenCode's reported limits:
opencode api get /api/model | jq -c '.data[] | select(.providerID=="claude-agent") | [.id, .limit.context]'["opus",200000]
["sonnet",200000]
["fable",200000]
["haiku",200000]
- Claude Code's reported limit:
claude -p /context --model opus | grep '^\*\*Tokens'**Tokens:** 10.7k / 1m (1%)
- Saved models that have a context window:
sqlite3 ~/.local/share/opencode/opencode.db "select value from kv where key like 'plugin:%' and value like '%resolvedModel%'" | jq '[.models[] | select(.contextWindow)] | length'0
Expected: the saved windows survive chat starts and restarts, and a catalog missing windows is re-checked.
Actual: once the windows are lost, they stay lost.
Local fix (recovery only)
This restored 1M for me. My two Claude Agent credentials are duplicates of the same Claude Code login, created by connecting twice. Neither stores any account data, so switching between them didn't change accounts. Activating a credential is what re-runs the full check.
- List the credential IDs:
opencode api get /api/integration/claude-agent | jq -c '.data.connections[] | {id, label}'- Activate the other credential, then the one you want to keep. Each activation re-runs the full check and sends no prompt:
opencode api post /api/credential/<other-credential-id>/activateopencode api post /api/credential/<credential-you-want-active>/activate- Restart any other
opencode serveprocess that was already running. They keep serving 200K until restarted.
After this, the step 4 count went from 0 to 11, and /api/model reported 1000000 on every server. claude-fable-5 stayed at 200K because discovery returns 429 Usage credits are required for this model on Pro. Haiku 4.5, Opus 4.6 and Sonnet 4.6 also report 200K, which matches Claude Code's docs.
Not tested: re-activating with only one credential. Also, connecting again after upgrading Claude Code did not restore the windows in my case (see below), so a reconnect may not be enough.
Request
Please fix this so users don't hit it again and don't need to know the recovery steps. I propose these changes in provider.ts. I read them off the code and haven't tested them:
- At startup, run the full check when any saved model lacks
contextWindow, not only when the catalog is empty. - Before writing the catalog, re-read the stored one and keep any windows it already has, so a stale instance can't erase them.
Environment
- OpenCode version: 2.2.5
- Claude Code: 2.1.309
- Plugins: built-in
opencode.provider.claude-agent - Operating System: Linux x86_64, kernel 6.8.0-142-generic (container)
- Terminal: OpenCode TUI, zsh
Timeline and what I haven't confirmed:
- My first connect used Claude Code 2.1.76 and failed with
unknown option '--thinking-display=summarized'. It wrote no catalog. - I ran
claude update(to 2.1.309) and connected again at 04:17:44. The catalog row was first created at 04:17:46, after the upgrade, and had no windows. So the old CLI did not write the broken catalog, and reconnecting after the upgrade did not repair it. The windows only came back when I activated a credential at 05:42, on the same server. - Why that first check on the updated Claude Code produced no windows is unknown. It may be a timing problem while the upgrade was finishing, but I haven't confirmed that.
- I had three
opencode serveprocesses sharing one database, and the log shows several of them writing the catalog. I haven't reproduced the overwrite from a clean install. - Actual compaction at about 170K. I haven't run a session that far. The figure comes from the source (
RESERVE_SHARE = 0.15) and the reported window.
Activity
opencodejr commentedon Nov 1, 2026
Thanks for the detailed report. I reproduced both problems on the latest
dev(69269e4). The Claude Agent provider code there is the same as in 2.2.5. I didn't have a Claude login, so I used the repo's fake Claude Code test setup:contextWindow, and Claude Agent connected, startup runs no check andsonnetstays at 200000. Inregister, the full check only runs when the saved list is empty.haikuwith a 1M window, and a chat starts on the first instance. The storedhaikuloses itscontextWindow, becausefromClaudeonly fills in missing windows from its own in-memory copy and never re-reads storage.The script below adds these two regression tests to a checkout and runs them. Both fail on
dev. I couldn't find an existing issue for this.Reproduction script (repro.sh)
Run it:
bash repro.shjimmyallinai commentedon Nov 1, 2026
I'll take this one. Plan: reproduce the two cases the bot confirmed (startup skips re-check when a saved catalog has models but no
contextWindow, andfromClaudedrops a saved window when the in-memory copy lacks it), then fixregisterto re-check catalogs missing windows and makefromClaudepreserve saved windows instead of overwriting them with none. I'll add regression tests for both cases and run the claude-agent provider tests before opening a PR.JtMotoX commentedon Nov 11, 2026
Update: also affects new models added after the first check (Claude Fable 5.2). Workaround below, not a fix
I hit this again on a different machine with a different trigger. Opus, Sonnet, Haiku and Fable 5.1 kept their 1M windows. A model added after the last full check never gets a window. It falls back to 200K and stays there.
What happened
Environment: Windows 11. OpenCode 2.2.6 (the copy bundled with OpenChamber). Claude Code 2.1.316. One Claude Agent credential, connected on 2026-11-02.
The full check ran once, when I connected on 2026-11-02.
claude-fable-5-2showed up in the saved model list later. No context check was ever logged for it.Claude Code reports 1M for it:
The saved list had a window for every model except two:
So any new model Anthropic releases will show 200K, and compaction will start around 170K, until something re-runs the full check by hand. The current code doesn't do that at startup, when a chat starts, or when a new model first appears in the list.
New finding: re-activating a single credential does nothing
My original report said this was untested. I tested it:
POST /api/credential/<id>/activateon the credential that's already active runs no check and changes nothing. You need a second credential to switch away from and back.Local workaround
Add a temporary second Claude Agent credential. It points to the same Claude Code login and stores no account data:
opencode api post /api/integration/claude-agent/connect/external \ -d '{"methodID":"claude-login","label":"Claude Agent temp"}'Re-activate your original credential. This is the step that re-runs the full check:
Delete the temporary credential:
Restart every other OpenCode server that uses the same database. For me that included the server bundled with OpenChamber. Each one keeps its old copy of the model list in memory. Until restarted, it keeps reporting 200K and could write the old list back over the fixed one (the second case in the original report).
On Windows PowerShell,
opencode api -d '<json>'mangled the JSON, so I ran step 1 by calling the HTTP API directly. It's the same endpoints.Result: 13/13 saved models had a window.
claude-fable-5-2andclaude-fable-5went to 1,000,000, and OpenChamber showed 1M after a restart. The 2026-11-02 check had failed forclaude-fable-5with a 429. This time it succeeded with no error.What a real fix needs
contextWindow, not only when the list is empty. This was proposal 1 in my original report, and fix(core): preserve Claude context windows #61136 seems to cover it.Also worth noting: I had an older OpenCode v2.0.18 background service using the same database alongside 2.2.6. I haven't confirmed whether it played any part in this.