Opencode-Zen Plugin update

[mr-addams]

Opencode Zen start blocking Omniroute since yesterday

Could you, please, fix this issue in plugin?
For example, give us a possibility to define custom opencode headers in it ..

[geekyNads]

This looks related to the recent OpenCode Zen changes around client identity/headers. OmniRoute already has logic for synthesizing the OpenCode CLI headers (User-Agent, x-opencode-client, x-opencode-project, request/session IDs), and recent fixes were specifically made for Zen/Go requests being rejected upstream.

I'd be careful about adding completely arbitrary custom headers, though. A better approach might be exposing the relevant OpenCode identity headers as configurable values while keeping auth headers protected.

If you can share the exact response/status you're getting from Zen and the OmniRoute version, we can probably determine whether this is another header/identity mismatch or a new upstream blocking rule.

[mr-addams]

it's a latest container version from ghcr.io

[geekyNads]

I think the screenshot clarifies what’s happening here. This doesn't look like a missing/custom header issue anymore Zen is explicitly returning:

OpenCode's free tier can only be used in OpenCode

So the rejection is happening upstream based on the client/request origin, rather than OmniRoute failing to format the request correctly.

I'd be cautious about solving this by spoofing OpenCode headers. If Zen intentionally restricts the free tier to the official client, arbitrary header configuration probably isn't the right fix and could break again whenever their validation changes.

The useful next step would be to confirm whether OmniRoute is expected to support Zen's free tier at all, or whether the plugin should only support models/accounts that Zen allows through third-party clients. If the latter is the case, this is more of a compatibility/policy change than a header bug.

[mr-addams]

I'm using Opencode as client.. Omniroute just sitting between to provide more providers to it..

[geekyNads]

@mr-addams I don't think "I'm using OpenCode as the client" changes things, though — Zen isn't seeing your client, it's seeing OmniRoute's own outbound request on the next hop. Whatever headers OmniRoute sends is the request Zen evaluates, regardless of what called OmniRoute.

So the real question is whether Zen's free tier is meant to work through any proxy at all, or if it's deliberately locked to the official binary. If it's the latter, no amount of header configuration fixes it — that's a policy wall, not a bug.

Could you share the full response from Zen (headers included, not just the body message) for a request OmniRoute proxied? That'll tell us if there's still a header gap worth closing, or if this is a hard restriction we can't engineer around.

[diegosouzapw]

Hey @mr-addams! @geekyNads has the mechanism right - Zen sees OmniRoute's outbound request, not your OpenCode client. The good news is that the custom headers you are asking for already exist, they are just env-configurable rather than a UI field.

What OmniRoute already sends

The opencode executor synthesizes OpenCode CLI identity headers by default, specifically so Cloudflare in front of opencode.ai/zen does not 429 requests coming from a VPS (open-sse/executors/opencode.ts:810-831). Three values are overridable:

Env var	Default	Header
OPENCODE_USER_AGENT	opencode	User-Agent
OPENCODE_CLIENT	desktop	x-opencode-client
OPENCODE_PROJECT	global	x-opencode-project

There is also a per-provider form, <PROVIDER_ID>_USER_AGENT, and OPENCODE_SYNTHESIZE_CLI_HEADERS=false disables the synthesis entirely.

Client headers are forwarded too

Headers your client sends win over the synthesized defaults. The forwarded set is x-opencode-session, x-opencode-request, x-opencode-project, x-opencode-client, plus x-session-id and x-title (open-sse/utils/opencodeHeaders.ts:9-23). User-Agent is the one exception: a generic UA such as curl/8.5.0 is replaced with the CLI UA, because Zen's free tier rejects generic UAs from datacenter IPs.

What to try, in order

1. Set OPENCODE_USER_AGENT to the exact UA your working OpenCode CLI sends. Read it from the CLI's own outbound request rather than guessing.
2. If you are on a VPS or a datacenter IP, the block may be IP-level rather than header-level. Try the same key from a residential connection. If that works, no header will fix it.
3. If the block started for everyone at once, Zen changed something upstream and we need to match it. Post the exact response Zen returns (status plus body) and we can compare against the current CLI's request shape.

Which of the three is it? The response body from Zen will tell us, and it decides whether this is a config fix on your side or a code change on ours.

[diegosouzapw]

@mr-addams -- still happening on the latest version (3.8.52)? Otherwise I'll close this in 7 days for inactivity.

[geekyNads]

@diegosouzapw I think the issue has been resolved, which would explain the recent inactivity.

[diegosouzapw]

Closing: the block was Zen refusing its free tier outside the OpenCode app, and the OpenCode Free provider was removed in 3.8.52 (#16310). Zen and Go with your own key still work through OmniRoute. If a paid Zen request fails, open a new thread with the error body.

---