OpenCode, the open-source terminal-and-IDE coding agent, has crossed 170,000 GitHub stars this year while doing something that goes against the current in a market dominated by vendor-locked coding assistants: it refuses to pick a model for you. It’s a client that talks to whatever LLM you point it at — Claude, GPT, Gemini, Qwen, a local model, doesn’t matter — and its monetization strategy is Zen, an inference gateway that charges close to zero markup and passes through only payment processing fees.

I run three different coding agents across client projects right now, on three different vendor plans, and the bill complexity has quietly become its own line item to manage. OpenCode’s bet is that model-agnosticism is the actual product, not a feature. I think that bet is right for a specific segment of teams, and wrong for another, and the split is worth being precise about.

What Zen actually is

Zen isn’t a new model. It’s a routing and billing layer with two tiers, per public reporting: a flat $10/month “Go” plan with usage caps ($12 per 5 hours, $30/week, $60/month) across roughly two dozen curated open-weight coding models, and a pay-as-you-go credit tier with zero markup that adds frontier closed models (Claude, GPT, Gemini, Grok) on top, charging card-processing fees only.

The zero-markup claim is the interesting part architecturally, because it means OpenCode’s business model isn’t “clip a percentage off every token you burn” — it’s closer to “get you using our client, and monetize the aggregate relationship with model providers, not the per-request margin.” That’s a fundamentally different incentive structure than a bundled subscription tool, where the vendor wants you spending exactly as much compute as your plan tier allows and no more.

Why the “no markup” number matters for procurement, not just cost

Here’s a rough cost model comparing a bundled-subscription coding agent versus a BYO-model setup through a zero-markup gateway, for a five-engineer team doing moderate-to-heavy agentic coding:

def monthly_cost(engineers, avg_tokens_per_engineer_millions, bundled_plan=True):
    if bundled_plan:
        # fixed seat price, usage capped, overage often blocked or throttled
        return engineers * 30  # illustrative: $30/seat/month flat
    else:
        # BYO model via zero-markup gateway: pay raw provider rates
        # blended rate across a mix of frontier + open-weight models
        blended_rate_per_million_tokens = 4.50
        return engineers * avg_tokens_per_engineer_millions * blended_rate_per_million_tokens

# Light usage (a few features a week): bundled often wins on predictability
print(monthly_cost(5, 2, bundled_plan=True))   # $150 flat
print(monthly_cost(5, 2, bundled_plan=False))  # $45 — BYO wins here

# Heavy usage (multi-agent pipelines, large refactors, CI-integrated agents):
print(monthly_cost(5, 20, bundled_plan=True))  # still $150, but likely throttled/capped
print(monthly_cost(5, 20, bundled_plan=False)) # $450 — bundled wins if the cap isn't hit

The numbers are illustrative, not sourced from a specific vendor’s rate card, but the shape is the real point: bundled subscriptions win when your usage is low-to-moderate and predictable, because you’re paying for a ceiling you rarely hit. BYO-model gateways win when usage is either very light (you pay only for what you use) or so heavy that a bundled plan’s cap becomes the actual constraint on your team’s throughput — at which point “we hit our agent quota on a Tuesday” becomes an engineering-velocity problem, not a billing one.

The part that doesn’t show up in the pricing page: model selection as an architecture decision

The underrated benefit of a model-agnostic client isn’t cost — it’s that model selection becomes a per-task decision instead of a company-wide procurement decision. In practice, that looks like:

# quick lint-fix pass on a large repo: cheap open-weight model, high volume
opencode run --model zen/qwen3.8-coder "fix all flagged lint errors in src/"

# architecture-sensitive refactor: frontier model, low volume, needs judgment
opencode run --model zen/claude-fable-5.1 "refactor the payment reconciliation module \
  to remove the race condition described in issue #4021"

# CI-integrated PR review bot: cheapest model that clears your accuracy bar
opencode run --model zen/gemini-3.8-flash --ci "review this diff for regressions"

That’s the actual architectural shift worth internalizing: agent cost optimization stops being a single annual vendor negotiation and starts being a routing problem you solve continuously, the same way you’d route traffic between compute tiers. Teams that are still on a single-vendor coding assistant plan are, functionally, always paying frontier-model prices for lint fixes.

Where I’d push back

Model-agnosticism has a real cost that the pricing comparisons don’t capture: every model behaves slightly differently inside the same agent harness, and a prompt or tool-calling pattern tuned against one model doesn’t transfer cleanly to another. Vendor-bundled agents (Copilot, Cursor, Claude Code) invest heavily in harness-level tuning for their specific model family — context management, tool-call formatting, error recovery — and that tuning is invisible until you swap the model underneath and your success rate quietly drops on a class of tasks you didn’t test. If your team adopts a BYO-model setup, budget real time for building your own eval suite per model-and-task combination; skipping that step is how “we saved 60% on inference” turns into “we spent it back in debugging agent mistakes.”

For teams with a dedicated platform engineer who can own that eval work, OpenCode’s model is a genuinely better long-term architecture. For teams without that capacity, a well-tuned single-vendor agent is still the safer default — you’re paying for tuning you’d otherwise have to build yourself.

Sources: Developers Digest: OpenCode Developer Guide, AI Product Scout: How OpenCode reached 173K stars, AgentPlans: opencode pricing comparison

Export for reading

Comments