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
Third-party apps now draw from your extra usage, not your plan limits. Add more at claude.ai/settings/usage and keep going. #15
@ajaypilaniyawynk I tested this locally on a Claude Max plan and could not reproduce the extra-usage classification after refreshing OAuth credentials.
What I verified:
ran the repo's side-by-side validator against official Claude Code and OpenCode + the bridge
both clients succeeded
extra_usage stayed disabled before and after both requests
seven_day_oauth_apps stayed null
so on this machine, with a fresh login, the bridge was still classified onto normal plan usage rather than extra usage
I did hit stale OAuth credentials before re-logging in, so the first thing I'd suggest is:
run claude login again
retry the bridge immediately after
check whether official claude CLI on the same account also shows the same usage warning
Because I can't repro it now, I don't yet have evidence of a deterministic bridge bug. It may be account/session-specific or a server-side classification change.
If you can still reproduce it after a fresh claude login, the most useful next step would be to run the validator and attach the artifacts:
npm run build
node scripts/validate-opencode-oauth.js --model claude-sonnet-4-6 --prompt "Reply with exactly VALIDATE."
Please attach:
tmp/.../report.json
the redacted request/response capture files from that run
That will let us compare official Claude Code vs OpenCode on an affected account and see whether there's still a bridge-controlled request difference worth fixing.
@ajaypilaniyawynk glad the original issue resolved! The plan mode error is a known bug I just fixed — the bridge was injecting EnterPlanMode and ExitPlanMode into the Claude tool schema but had no translation entry mapping those names back to OpenCode's native plan_enter/plan_exit names. So when the model called EnterPlanMode, OpenCode rejected it with "Model tried to call unavailable tool" because it only knows the tool by plan_enter.
Released in v1.10.8 — update your local install and restart OpenCode:
# clear the opencode plugin cache so it picks up the new version
rm -rf ~/.cache/opencode/node_modules/opencode-claude-bridge
rm -rf ~/.cache/opencode/packages/opencode-claude-bridge@latest
Then restart OpenCode and it will fetch 1.10.8 automatically. Plan mode should now work end-to-end.
Thanks — you're right, I can't reproduce it deterministically either.
validator did flag bridge-controlled request diffs vs official Claude Code that may still be worth a look as classification signals: tool count 10 vs 54 (toolNamesEqual=false), user-agent (external, cli) vs (external, sdk-cli), missing beta flags thinking-token-count-2026-05-13 and extended-cache-ttl-2025-04-11, an extra x-session-id header, and stainless package version 0.81.0 vs 0.94.0.
One important note: on my account, both official Claude Code and OpenCode consumed extra_usage during the validator run, so this result does not show a bridge-only classification difference anymore. The header diffs were real, though, and are now addressed in the PR.
The remaining diff is tool shape: official Claude Code currently advertises 30 tools, while OpenCode advertises its active executable tool set. I am not going to blindly mirror all 30 yet, because advertising tools OpenCode cannot execute can cause model/tool-call failures. That should be handled separately with deliberate translation/shim support where possible.
Activity
dotCipher commentedon Apr 23, 2026
@ajaypilaniyawynk I tested this locally on a Claude Max plan and could not reproduce the extra-usage classification after refreshing OAuth credentials.
What I verified:
extra_usagestayed disabled before and after both requestsseven_day_oauth_appsstayednullI did hit stale OAuth credentials before re-logging in, so the first thing I'd suggest is:
claude loginagainclaudeCLI on the same account also shows the same usage warningBecause I can't repro it now, I don't yet have evidence of a deterministic bridge bug. It may be account/session-specific or a server-side classification change.
If you can still reproduce it after a fresh
claude login, the most useful next step would be to run the validator and attach the artifacts:npm run build node scripts/validate-opencode-oauth.js --model claude-sonnet-4-6 --prompt "Reply with exactly VALIDATE."Please attach:
tmp/.../report.jsonThat will let us compare official Claude Code vs OpenCode on an affected account and see whether there's still a bridge-controlled request difference worth fixing.
ajaypilaniyawynk commentedon Apr 27, 2026
This is working now. Another issue I am facing is in plan mode where I get error - Model tried to call unavailable tool 'EnterPlanMode'
@dotCipher is it a known limitation?
dotCipher commentedon Apr 28, 2026
@ajaypilaniyawynk glad the original issue resolved! The plan mode error is a known bug I just fixed — the bridge was injecting
EnterPlanModeandExitPlanModeinto the Claude tool schema but had no translation entry mapping those names back to OpenCode's nativeplan_enter/plan_exitnames. So when the model calledEnterPlanMode, OpenCode rejected it with "Model tried to call unavailable tool" because it only knows the tool byplan_enter.Released in v1.10.8 — update your local install and restart OpenCode:
Then restart OpenCode and it will fetch 1.10.8 automatically. Plan mode should now work end-to-end.
dotCipher commentedon Apr 28, 2026
@ajaypilaniyawynk let me know if that worked for you?
olosegres commentedon May 10, 2026
If someone still has problems, probably you need to remove
opencode-anthropic-authplugin from allopencode.json(user level and project level).dotCipher commentedon May 11, 2026
@ajaypilaniyawynk going to close this within the next 48 hours if you are unable to confirm that this is still an issue
joyalkenus commentedon Jun 13, 2026
Thanks — you're right, I can't reproduce it deterministically either.
validator did flag bridge-controlled request diffs vs official Claude Code that may still be worth a look as classification signals: tool count 10 vs 54 (toolNamesEqual=false), user-agent (external, cli) vs (external, sdk-cli), missing beta flags thinking-token-count-2026-05-13 and extended-cache-ttl-2025-04-11, an extra x-session-id header, and stainless package version 0.81.0 vs 0.94.0.
dotCipher commentedon Jun 16, 2026
Thanks, this was useful. I re-ran the validator after refreshing Claude OAuth and could reproduce the bridge-controlled header diffs you called out.
I opened a PR for the safe request-parity fixes here: #23
What changed in that PR:
thinking-token-count-2026-05-13andextended-cache-ttl-2025-04-11x-stainless-package-versionfrom0.81.0to0.94.0x-session-idheader before forwarding to AnthropicPushNotificationandScheduleWakeupAfter the patch, the validator reports:
One important note: on my account, both official Claude Code and OpenCode consumed
extra_usageduring the validator run, so this result does not show a bridge-only classification difference anymore. The header diffs were real, though, and are now addressed in the PR.The remaining diff is tool shape: official Claude Code currently advertises 30 tools, while OpenCode advertises its active executable tool set. I am not going to blindly mirror all 30 yet, because advertising tools OpenCode cannot execute can cause model/tool-call failures. That should be handled separately with deliberate translation/shim support where possible.