Repository navigation
Windows CLI 2.0.32: free-tier 403 after Console login with empty config and built-in build agent #56425
Description
Official Windows CLI 2.0.32 receives free-tier 403 after Console device authentication, including with an empty global config and the built-in build agent.
Environment
- Windows NT 10.0.26200.0, x64
- Official OpenCode CLI v2.0.32
- OpenCode Console device authorization completed successfully;
opencode auth listreports the Personal workspace as stored. - Background service restarted after updating and again after authentication.
Reproduction
opencode run --standalone --agent build --model opencode/glm-5.3-flash-free 'Reply only OK. Do not call tools.'
opencode run --standalone --agent build --model opencode/big-pickle 'Reply only OK. Do not call tools.'Both exit with the message:
OpenCode's free tier can only be used from within OpenCode. Download it at https://opencode.ai and keep building.
Expected: a model response from the official CLI, or an actionable explanation of the eligibility requirement that failed.
Isolation performed
- Temporarily moved the complete global config directory aside and created a replacement containing only
opencode.jsonwith{}. - Ran both commands from an empty scratch directory with
--standalone, so they did not use the existing background service. - No custom agents, plugins, MCP servers, legacy provider endpoints, or custom permission rules in the temporary global config.
- Console authentication remained stored in the existing data directory.
- Both commands still failed. Original configuration was restored afterward.
- The normally loaded configuration also contains no
https://opencode.ai/zen/v1provider override. - Also reproduced using beam-free in the interactive CLI.
Console request evidence
The following request IDs are from October 17, 2026 (times UTC+05:00):
e291551b-b4b3-4bf1-8cff-539216bf5cd8— glm-5.3-flash-free, 20:26:20, HTTP 403.6b8648e6-ea0a-4843-bcb3-d8e07f90f581— beam-free, 20:28:32, HTTP 403.
Console shows for the second request:
- Endpoint:
/inference/openai/v1/chat/completions - Method: POST; streaming: yes; protocol: openai-chat
- App: cli
- User-Agent:
opencode/latest/2.0.32/cli x-opencode-client: clix-opencode-sessionis present with an OpenCode-generated session ID.- Account identity is recognized.
These request IDs precede the separate empty-config tests; they document the interactive failure, not the isolated runs.
Question
Could maintainers inspect these request IDs and identify the exact free-tier validation or eligibility condition rejecting the official client? Is there a supported client-side fix, or is this a gateway regression?
Related: #55435, #55443, #50627. Unlike the tool-denial reproductions, this persists with the built-in build agent and an empty global configuration.
Activity
opencode-agent commentedon Oct 17, 2026
Thanks for the careful isolation and the request IDs, @grey021. I think this is a duplicate of #56324. It reports the same 403 on free
opencode/*models in the official v2.0.32 client on Windows. It happens with the built-in Build agent, with--standalone, and with a valid Console login (and also signed out), and it started on the same day.The rejection happens in the hosted OpenCode Zen gateway, not in the CLI. Your empty-config test already rules out the known client-side causes, such as an agent that lacks the
bash/readtools (#50627) or a legacyhttps://opencode.ai/zen/v1provider override. Only the team can look up your request IDs in the server-side logs. Please add them to #56324, together with your Windows/2.0.32 details. If you can, also try once from a different network, like a phone hotspot. Several people found that the same client and account work from another network.Possible duplicates and related issues, ordered from most to least likely:
--standalone, signed in or out. This is where it's being tracked.bash/readtools). Your empty-config test rules it out.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
grey021 commentedon Oct 17, 2026
Update: the same installed CLI and stored Console account now work through the currently active Happ network route.
Verified with actual inference responses, not just endpoint reachability:
glm-5.3-flash-free, built-inbuild,--standalone, current default route: returnedOK.glm-5.3-flash-free,--standalone, with an explicit local Happ HTTP proxy via process-scoped HTTP_PROXY/HTTPS_PROXY: returnedOK.beam-free, normal background-service session with the customorchestratoragent: returnedOK.No reinstall or additional login was performed between the failed clean-config tests and these successful tests. Original user configuration was restored before the successful tests.
Important limitation: the user/network route had changed by the time these tests ran; we did not capture a controlled before/after egress-IP pair for the inference endpoint itself. IP-check requests also showed differing egress addresses. These results are consistent with the network/egress-dependent reports mentioned above, but do not identify the exact gateway rule.
The immediate problem is currently resolved on this connection. Please retain the earlier request IDs if useful for investigating the misleading 403 message and the underlying rejection condition.
opencode-agent commentedon Oct 18, 2026
Closing this as a duplicate of #56324, since there's been no reply saying how it's different. #56324 is where the free-tier 403 on official v2.0.32 is being tracked.
The rejection comes from the hosted Zen gateway, so only the team can look up your Console request IDs (
e291551b-b4b3-4bf1-8cff-539216bf5cd8,6b8648e6-ea0a-4843-bcb3-d8e07f90f581) in the server-side logs. Please post them on #56324 along with your Windows/2.0.32 details and the result of the empty-config test. If you try from another network, please add that result there too.If this turns out to be a different problem, reply here and it can be reopened. Thanks again for the careful report.