Repository navigation
Free-tier 403 is network-dependent in official 2.0.32 and 1.18.35 clients #56334
Description
Summary
Official OpenCode clients return HTTP 403 FreeTierError on my original home network. The same app, account, agent, model, and reasoning variant answered on another network, then failed again after returning to the original network.
The user reports the same symptom across projects and across OpenCode free models. Local records independently confirm the error for DeepSeek Free, GLM Free, and Big Pickle.
Error
OpenCode's free tier can only be used from within OpenCode. Download it at https://opencode.ai and keep building.
Environment and network comparison
- macOS, arm64; official OpenCode Desktop 2.0.32.
- Model used for controlled comparisons:
opencode/deepseek-v4.1-flash-free, Max. - October 17, 2026, America/Chicago:
- Original network: repeated HTTP 403.
- Other network at 1:47 a.m.: same chat/settings completed normally, with 75 output tokens.
- Back on original network at 1:49 a.m.: same chat/settings returned the identical HTTP 403.
Additional controls on the original network
The CONNECT tunnels forwarded encrypted traffic without TLS termination or disabled certificate verification. The forced-family tests used DeepSeek only.
Home DNS answers matched an independent Cloudflare DNS-over-HTTPS lookup. Basic verified HTTPS connections over both families returned HTTP 200. Both home routes reported Cloudflare colo ORD, location US, WARP off.
Request correlation
From the isolated official 1.18.35 request:
- Time: 2026-10-17 06:54:16 UTC (1:54:16 a.m. CDT)
- Endpoint:
https://opencode.ai/inference/openai/v1/chat/completions - Status: 403, error type
FreeTierError x-opencode-log-id: 3b18fb66-dc9f-4394-b897-b08e97c2a0b1cf-ray: a4bd6419d98fe12f-ORDcf-placement:remote-IAD
Question
Could you inspect this request and identify the acceptance check that rejects the original connection while the same official client works from another network? An IP/prefix/routing-dependent restriction or false positive seems possible, but the local evidence does not establish a permanent ban, quota exhaustion, or the exact server-side rule.
Related same-error reports: #50627 and #55737. The network comparison above is the strongest observed discriminator in this case.
This report omits credentials, client public IP addresses, account identifiers, private source, and machine-specific paths.
Activity
opencode-agent commentedon Oct 17, 2026
Thanks for the detailed write-up, @MarkJRogers92. The controls you ran make this much easier to look into.
The check that rejects this request happens in the hosted OpenCode Zen gateway, not in the OpenCode app. Your results already rule out the known client-side causes (agent tools, plugins, config, account state, IP family and client version). Since the same client works on another network, only the team can look this up in the server-side logs. That kind of service and account investigation isn't handled in GitHub issues. Please email help@anoma.ly with the details, including the
x-opencode-log-id(3b18fb66-dc9f-4394-b897-b08e97c2a0b1), thecf-ray(a4bd6419d98fe12f-ORD) and the UTC timestamp. If you've already emailed, the team will get to it, especially now that we've seen it here. Please keep your public IP, account identifiers and email address out of this public issue and put them only in the email.Related issues, for reference:
bashtool; a leftoverzen/v1provider in config), which your controls already excludeThe bot will close this issue in 1 day.
Mike-wu-junhao commentedon Oct 18, 2026
Same symptom here, with one detail that may narrow it down: I have no OpenCode account at all. I never created or logged into one, and my local credential file contains no opencode/Zen entry, so these free-tier requests carry no account identity. There is no account to look up or reset.
Three observations, the first two of which seem to complicate a "the whole network is blocked" reading:
It looks intermittent per request, not per session. On the same machine and in the same session, requests succeed and fail within the same minute - 2026-10-18T04:17:30Z was rejected while another session's requests were being answered at the same time. Earlier on 2026-10-18 a request succeeded at 01:45Z and another was rejected at 02:13:00Z, about 28 minutes later, on a different network.
Two egress addresses in the same /24 behaved differently. Moving from campus Wi-Fi to a phone hotspot changed the egress from 111.4.146.186 to 111.4.146.190 - same /24, same carrier (AS9808 China Mobile) - and I saw no further failures in the ~2 minutes after the switch. That is a small sample and I am not claiming the trigger is that narrow, but it does suggest "which network" may be too coarse a description.
It self-recovered once with no local change: 2026-10-03T04:43:01Z to 05:57:29Z, about 1h15m.
Log evidence on my side: 30 ERROR records, all
providerID=opencode modelID=space-bunny-free agent=build, each with its own timestamp. There is nox-opencode-log-idand nocf-rayin these records, so I have no per-request trace id to quote. I can supply a log excerpt if that is useful.I have emailed the full report to help@anoma.ly as the triage bot suggested.
Charles-X-Core commentedon Oct 18, 2026
I can confirm the same network-dependent issue on Ubuntu 24.04.5 LTS running under WSL2, using the official OpenCode CLI v2.0.32.
Environment
opencode/deepseek-v4.1-flash-freeReproduction results
Using the same machine, installation, account, model, and exact command:
opencode run --standalone \ --model opencode/deepseek-v4.1-flash-free \ 'Responde únicamente: OK'FreeTierErrormessage.OK.I also confirmed that
opencode.airesolves correctly and responds with HTTP 200 over HTTPS on my regular Wi-Fi connection. No proxy-related environment variables were detected.The same official CLI and Console account work consistently through the mobile hotspot but fail through my regular connection.
This strongly suggests a network-dependent issue in the hosted free-tier validation, although I cannot determine whether the cause is the public IP, ISP routing, regional eligibility, or another gateway-side condition.
Could the maintainers investigate this case and advise which request-tracing information would help identify why the regular connection is rejected?
I can provide timestamps in UTC and relevant logs privately if needed. I will send any public IP or account-specific details to support by email rather than posting them publicly.
Charles-X-Core commentedon Oct 18, 2026
Additional evidence from the OpenCode request logs
I found the corresponding request records in the OpenCode dashboard. The logs show both HTTP 403 rejections and HTTP 200 successes for
deepseek-v4.1-flash-free, using the same provider (opencode) and CLI user agent (opencode/latest/2.0.32/cli).The logs also show occasional HTTP 429 responses followed by successful retries. This confirms that the issue is reflected in the inference service's request records, rather than being limited to a local terminal error.
I would appreciate help identifying the reason for the HTTP 403 responses and whether the gateway applies any network-dependent eligibility or access checks.
opencode-agent commentedon Oct 18, 2026
Closing this as not planned, @MarkJRogers92. The free-tier rejection comes from the hosted Zen gateway, and only the team can investigate it through support, not in GitHub issues.
If it still happens on your home network, please email help@anoma.ly with the
x-opencode-log-id(3b18fb66-dc9f-4394-b897-b08e97c2a0b1), thecf-ray(a4bd6419d98fe12f-ORD) and the timestamp. Please keep your IP address and account details in that email only, not here. If you've already written in, the team will follow up there. Thanks again for the careful investigation!