OpenCode Plans and Pricing: The One With No Subscription

Two routes, neither of them a subscription

Everything about OpenCode pricing comes down to which of these two you pick, and you can switch between them per project or per session.

BYOK is the purest form: OpenCode is just a client. Point it at an Anthropic or OpenAI key you already have and the tokens are billed directly by that provider, exactly as if you had called their API yourself. OpenCode is not in the payment path at all and takes no cut.

Zen is a curated gateway. You add a balance, use whichever models you want at published per-token rates, and it auto-tops up when you run low. Zen works like any other provider inside OpenCode, so switching to it is a configuration change, not a migration.

What OpenCode Zen actually costs

Zen publishes per-million-token rates split into input, output, cached reads and cached writes. The spread across the catalogue is enormous, which is the single most useful thing to understand about it. As of August 2026:

Read that table again, because the range is the point: the top of the catalogue costs 150 times the budget tier on output. On a subscription CLI your model choice changes how fast you burn a fixed allowance. Here it changes your bill directly and by two orders of magnitude. Picking the right model for the task is not a micro-optimisation on Zen, it is the whole cost story.

Zen also carries genuinely free models. They are not a trial and they are not rate-limited into uselessness; they are real entries in the catalogue at $0 input and $0 output. For routine work, mechanical refactors and anything where you mostly need a competent editor rather than a deep reasoner, they can carry more of your day than you would expect.

Zen takes no markup on requests. What it does pass along, at cost, is card processing: 4.4% plus $0.30 per transaction. That is a payment fee rather than a service fee, and it is the argument for topping up in larger amounts less often rather than in small increments.

The auto-reload default, and why to change it

By default, when your Zen balance drops below $5, the system automatically recharges $20. This is convenient and it is also the mechanism by which a misbehaving agent quietly spends real money overnight.

The threshold and the amount are both adjustable, and auto-reload can be disabled entirely. Disabling it turns your balance into a hard spending cap, which is the closest thing OpenCode has to the safety of a subscription: the agent stops when the money runs out, exactly like hitting a weekly limit, except you chose the number.

This is the honest counterweight to "no quota wall". A subscription protects you from your own agents. Pay-as-you-go does not, unless you build the protection yourself.

Pay-as-you-go against a subscription: when each one wins

The comparison people usually make is total monthly spend, and that is only half of it. The real difference is what happens at the edges.

A subscription is a fixed cost with a hard ceiling on capacity. Light months are wasted money and heavy weeks are a wall you cannot pay your way past. Pay-as-you-go is a variable cost with no ceiling on capacity and no floor on spend: a week off costs nothing, and a week of heavy refactoring costs whatever it costs.

That maps cleanly onto how people actually work:

• Bursty or occasional work favours OpenCode. Two intense weeks a quarter on a subscription means paying for the ten quiet ones.
• Steady daily work favours a subscription. The predictable cost is worth more than the theoretical savings, and you stop thinking about it.
• Unattended automation favours pay-as-you-go, because a CI pipeline that dies on a personal quota is worse than one that costs a few dollars.
• Learning and evaluation favours OpenCode outright, thanks to the free models and BYOK.

The setup that works best in practice is not choosing at all. Keep a subscription for your daily driver and keep OpenCode on the side for overflow, for the weeks you hit a weekly cap, and for automation. Two providers on two separate meters means you are almost never fully stopped, which is the argument developed in the OpenCode agent swarm guide.

Is OpenCode free? Yes, genuinely

The CLI is free and open source, with no paid edition, no feature gate and no seat count. This is not the "free tier" framing the other vendors use, where the free thing is a limited version of the paid thing. There is no paid version of OpenCode.

What costs money is the model behind it, and even that has a genuinely free path through Zen's zero-cost models. You can run OpenCode indefinitely for $0 if you are content with the free catalogue.

The realistic budget framing: evaluating OpenCode costs $0, using it seriously costs whatever your token consumption costs, and there is no monthly floor. For most single-agent daily use on a mid-tier model, that lands well under a $20 subscription. For heavy parallel agent work on a frontier model, it lands well above one.

Keeping the bill honest while agents run

Without a quota wall, the only thing between you and a surprise is visibility. Three habits do most of the work:

• Match the model to the task. The 150x output spread across the Zen catalogue means routine work on a frontier model is the single most expensive mistake available to you.
• Set the balance as a cap. Turn auto-reload off before any unattended run, so an empty balance stops the agent instead of refilling itself.
• Watch what is actually running. Parallel agents multiply spend linearly, and an agent stuck in a loop looks exactly like an agent working hard.

That last one is where a workspace helps. CodeAgentSwarm, the desktop app for running several AI CLI agents in parallel, keeps every OpenCode session visible at once with its current status and activity, so a session that has been busy for forty minutes on a five-minute task is obvious rather than invisible.