Description
Using opencode-claude-auth with Claude OAuth, anthropic/claude-opus-4-6 works on OpenCode v1.3.13 but fails on v1.3.14+ (including v1.3.17 and v1.4.x) with:
400: You're out of extra usage. Add more at claude.ai/settings/usage and keep going.
This appears to be an OpenCode regression rather than a general account/billing issue, because the exact same Claude OAuth account works on v1.3.13 and starts failing on v1.3.14+.
I narrowed the version boundary down to:
- last known good:
v1.3.13
- first known bad:
v1.3.14
The strongest suspect in that range is the provider/auth/plugin integration work in:
2f405daa983c950794aa3982584f59411f89bc50 — refactor: use Effect services instead of async facades in provider, auth, and file (#20480)
That change makes provider/auth.ts and provider/provider.ts depend on Plugin.Service directly. My current hypothesis is that this made opencode-claude-auth intercept the Anthropic Opus path reliably, which then triggers the Claude OAuth extra-usage rejection.
Additional evidence from CLAUDE_AUTH_DEBUG=1 on a failing version shows the Opus request is built with:
modelId: claude-opus-4-6anthropic-beta includes effort-2025-11-24- response is the 400 extra-usage error above
Plugins
oh-my-openagent@latestopencode-claude-auth@latest (observed with 1.4.9)
OpenCode version
- current pinned workaround:
1.3.13
- regression reproduced on:
1.3.14+, 1.3.17, 1.4.0, 1.4.1
Steps to reproduce
- Install OpenCode
v1.3.14 or newer.
- Install and authenticate
opencode-claude-auth with a Claude OAuth account.
- Run a minimal Opus request, for example:
CLAUDE_AUTH_DEBUG=1 opencode run "Reply with exactly the single word OK." --model anthropic/claude-opus-4-6 --variant medium
- Observe the request fails with:
You're out of extra usage. Add more at claude.ai/settings/usage and keep going.
- Downgrade to
v1.3.13 and run the same request again.
- Observe that the request succeeds on
v1.3.13.
Screenshot and/or share link
No share link. I can provide the relevant claude-auth-debug.log lines if needed, but the important ones are:
- successful Haiku request on same account
- failing Opus request on same account
- failing Opus request includes
effort-2025-11-24
Operating System
Linux-5.15.0-171-generic-x86_64-with-glibc2.35
Terminal
xterm-ghostty
Description
Using
opencode-claude-authwith Claude OAuth,anthropic/claude-opus-4-6works on OpenCodev1.3.13but fails onv1.3.14+(includingv1.3.17andv1.4.x) with:This appears to be an OpenCode regression rather than a general account/billing issue, because the exact same Claude OAuth account works on
v1.3.13and starts failing onv1.3.14+.I narrowed the version boundary down to:
v1.3.13v1.3.14The strongest suspect in that range is the provider/auth/plugin integration work in:
2f405daa983c950794aa3982584f59411f89bc50—refactor: use Effect services instead of async facades in provider, auth, and file (#20480)That change makes
provider/auth.tsandprovider/provider.tsdepend onPlugin.Servicedirectly. My current hypothesis is that this madeopencode-claude-authintercept the Anthropic Opus path reliably, which then triggers the Claude OAuth extra-usage rejection.Additional evidence from
CLAUDE_AUTH_DEBUG=1on a failing version shows the Opus request is built with:modelId: claude-opus-4-6anthropic-betaincludeseffort-2025-11-24Plugins
oh-my-openagent@latestopencode-claude-auth@latest(observed with1.4.9)OpenCode version
1.3.131.3.14+,1.3.17,1.4.0,1.4.1Steps to reproduce
v1.3.14or newer.opencode-claude-authwith a Claude OAuth account.CLAUDE_AUTH_DEBUG=1 opencode run "Reply with exactly the single word OK." --model anthropic/claude-opus-4-6 --variant mediumv1.3.13and run the same request again.v1.3.13.Screenshot and/or share link
No share link. I can provide the relevant
claude-auth-debug.loglines if needed, but the important ones are:effort-2025-11-24Operating System
Linux-5.15.0-171-generic-x86_64-with-glibc2.35
Terminal
xterm-ghostty