Question

PawWork is a public fork of opencode (credited clearly in our README and site). One piece of context first: we shipped an in-app "Subscribe to OpenCode Go" CTA recently. When PawWork users hit our free quota, the app routes them straight to opencode.ai for subscription. Users are actively trying to convert. We're trying to drive paying users upstream, not run a parallel free tier.

On the technical side, we've traced the behavior we're seeing back to commit 0b8050d453 (2026-05-17, by @fwang), which introduced a checkHeaders + dailyRequestsFallback mechanism in packages/console/app/src/routes/zen/util/ipRateLimiter.ts. Clients whose request headers don't match Subscription.getFreeLimits().checkHeaders get routed to dailyRequestsFallback instead of the standard dailyRequests pool. PawWork sends x-opencode-client: pawwork rather than opencode, so we land in the fallback pool and our users hit "free pool unavailable" almost immediately.

We understand the intent. Capping the high-throughput free pool to the canonical client distribution makes sense as a business decision, and we're not asking you to change that gate. We want to use Zen via the policy you actually want forks to use, not by spoofing the canonical client identifier.

What is the official path? For example:

• can a fork identifier like pawwork be allowlisted in checkHeaders?
• should forks use paid-only / BYO-key / Go account flows instead?
• is there a registration or contact path for forks?

We will identify ourselves clearly in every request and follow whatever policy you prefer forks to use.