Repository navigation
console: workspace Models-tab enablement not honored - disabled models still selectable and billed #54929
Description
Summary
A Console workspace has only one model enabled in the Models tab, but OpenCode
still exposes and uses the other (disabled) Console models, incurring
pay-as-you-go charges for models the user explicitly turned off.
Environment
- opencode version: 2.0.27
- OS: Darwin 25.6.0 (darwin arm64)
- Terminal: ghostty (TERM=xterm-256color, COLORTERM=truecolor)
- Shell: /bin/bash
- Install/channel: release/latest (v2.0.27)
- Active plugins: none
Reproduction
The following configuration exhibited the problem. It was not deliberately
reproduced, because re-running it incurs unexpected real charges.
- In the OpenCode Console workspace, open the Models tab and disable every
model except Claude Fable 5.1. - Connect OpenCode to the Console
opencodeprovider with a service-account
API key (/connect-> OpenCode Console -> API key), rather than signing in to
the workspace via the device flow. - In OpenCode, inspect the available model list / query the provider.
Expected Behavior
Only the enabled model(s) - opencode/claude-fable-5-1 - should be offered to
the client. Disabled models should not be selectable or usable.
Actual Behavior
All 43 Console models are exposed regardless of the workspace setting, e.g.
opencode/claude-haiku-5-5, opencode/deepseek-v4.1-flash,
opencode/kimi-k2.7-code, opencode/gpt-6-luna. Disabled models are
selectable and get used, producing unexpected pay-as-you-go usage.
Additional Context
- The provider is active via
GET /api/provider; the model listing returns 43
Console models while the workspace has a single model enabled. GET /api/provider/opencoderesponds without any models/enabled state, so the
client cannot tell which models the workspace permits.- Hypothesis: workspace model enablement is delivered via the workspace config
loaded on/connectwhen signing in to the workspace (device flow); a
service-account-key connection may bypass it. Confirming or ruling this out
would help. - Impact: silent billing for models a workspace owner explicitly disabled.
- Observed once in practice; not re-run deliberately due to the cost of the bug
itself.
Activity
opencode-agent commentedon Oct 12, 2026
Thanks for the detailed write-up, and for not re-running something that costs real money.
I think this is a duplicate of #41697: models turned off in the workspace Models tab are not blocked at the gateway, so requests for them still go through and are billed. Possible duplicates and related issues, ordered from most to least likely:
On your guess about service-account keys: as far as I can tell from the v2 client code, OpenCode doesn't fetch the workspace's per-model settings at all (with either the API key or the device flow). It only honours models turned off in your local config, so the gateway is the only place this could be enforced. If you have more details, especially anything showing that API-key connections behave differently from workspace sign-in, please add them to #41697. Until this is fixed, you can limit which models the client offers with
whitelist/blackliston theopencodeprovider in your config. That only changes what OpenCode itself offers, not what the gateway accepts.If you'd like the charges reviewed, email [email protected] and keep account details out of this public issue.
The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
opencode-agent commentedon Oct 13, 2026
We haven't heard back in the last day, so I'm closing this as a duplicate of #41697: models turned off in the workspace Models tab still work at the gateway and are still billed. The model picker listing models that are turned off is tracked in #40560.
If you have more details, such as signs that service-account-key connections behave differently from workspace sign-in, please add them to #41697. If this turns out to be a different problem, reply here and we can reopen it. For a review of the charges, email [email protected] and keep account details out of the public issue. Thanks again for the careful report.