Repository navigation
Free-tier Zen 403 for all third-party stacks despite valid session + key (only genuine client passes) #49621
Description
Free-tier Zen 403 FreeTierError for all third-party stacks despite valid session + key
Since ~2026-09-19/20, POST https://opencode.ai/zen/v1/responses with
muse-spark-1.3-contributor-free returns 403 FreeTierError: "OpenCode's free tier can only be used from within OpenCode" for every non-opencode-binary
client I can construct, while the genuine opencode 1.18.31 client on the
same machine/account/key succeeds. Setup had worked for days before that.
Elimination matrix (all same session/key/machine)
| Client stack | Session | Result |
|---|---|---|
opencode run / TUI (genuine binary) |
own fresh ses_… |
200 |
Local opencode serve API (POST /session/:id/message) |
own fresh ses_… |
200 (text; tools execute server-side as designed) |
node https, .NET Invoke-WebRequest, Python urllib, Bun 1.4.2, Bun 1.3.14 (exact embedded build), node raw TLS socket |
old pool ses_…, fresh API-minted ses_…, genuine client's own ses_… |
403 |
Byte-faithful replay of a captured genuine request (full header order, opencode/1.18.31 ai-sdk/provider-utils/4.0.40 runtime/bun/1.3.14 UA, x-opencode-client: desktop, x-opencode-project: global, genuine ses_… + msg_…, prompt_cache_key, include, reasoning, tools, stream:true) over HTTP/1.1 and HTTP/2 |
genuine | 403 |
Also ruled out: key rotation (env key == key in the working capture),
session expiry (fresh mints fail), session provenance/activity (replaying the
genuine session fails), x-opencode-client value (cli vs desktop),
session-affinity headers, body shape (minimal through full client-shaped),
system-prompt content, IP family (v6 unreachable here; all v4 same egress).
Interpretation
The discriminator is below the HTTP layer (TLS handshake fingerprint of the
official build is the remaining candidate — though even the exact Bun 1.3.14
runtime fails, so it may be build-specific) or an embedded request secret.
Notably the genuine binary's own BUN_CONFIG_VERBOSE_FETCH trace shows the
complete request, so there is nothing left to replicate at the HTTP layer.
Ask
Is third-party (OpenAI-compatible proxy) access to the free tier intentionally
removed, or is this gate overshooting? If intentional, a docs note would save
proxy authors (Empryo/pi custom providers, zen-proxy-likes) a lot of
forensics. If not, happy to provide captures: the failing case reproduces
with any HTTPS stack + any valid ses_….
Environment: Windows x64, opencode 1.18.31, OPENCODE_API_KEY key auth,
muse-spark-1.3-contributor-free, first failing ~2026-09-19/20 after days of
200s with identical requests.
Activity
github-actions commentedon Sep 17, 2026
This issue might be a duplicate of an existing issue. Please check:
FreeTierError: "OpenCode's free tier can only be used from within OpenCode"error, though from a different angle (official client vs third-party stacks)The root cause may be the same server-side enforcement change. It could be worth tracking this together with #49433.
release(v0.9.64): the versioned gate — Zen's free tier answers again ⚿
rekram1-node commentedon Sep 18, 2026
We've been tightening our logic to fight abuse You cannot use the free tier in other harnesses (this is only a limitation for the free tier nothing else).
joaomj commentedon Sep 18, 2026
@rekram1-node would be good to document this new policy.
release(v0.9.64): the versioned gate — Zen's free tier answers again ⚿
feat(models): drop the OpenCode Free tier and ask the user for a prov…
fix(ai): satisfy OpenCode Zen free-tier client gate
release: fork identity, installer, media safety, effort pickers, free…
Default to OpenRouter free models: Zen's free tier is API-gated