Open Source Coding Agent: OpenCode's Playbook
Cicero Campelo, CISSP
August 30, 2026 · 17 min read
Part of our guide to AI for startups.

Table of contents
- What an open source coding agent actually is
- The open slot is a position, and positions are winnable
- The unlock was the models, not the agent
- The block was the growth event
- Tokens are the new customer acquisition cost
- What enterprises actually buy from an open source coding agent
- The 16 year overnight success
- Five tests before you build the open alternative
- What to do this week
- Sources
- Frequently asked questions
An open source coding agent is a coding agent whose client and agent loop are open source, so you can read the code, run it yourself, and point it at whatever model you want. A closed coding agent ships with a model attached. An open one treats the model as a slot.
For most of the last two years that difference was academic, because there was nothing worth putting in the slot outside the frontier labs. That changed, and the clearest evidence is OpenCode, an open source alternative to Claude Code that works with any model.
On Y Combinator's Lightcone Podcast, founder and CEO Jay V said OpenCode went from around 650,000 monthly active users at the start of the year to about 13 million at the end of June, roughly a 20x increase, and that it now processes around 7 trillion tokens a day, up from around 300 billion at the start of the year. For context, he put OpenRouter's total at around 6 trillion. The hosts put weekly actives at 4.6 million.
Growth like that usually gets written up afterward as lightning in a bottle. This one has a structure under it, and most of the structure is copyable by any founder building against a dominant closed product.
What an open source coding agent actually is
Three parts, and it helps to separate them, because most comparisons blur them together.
The client. What you type into. For this category it is usually a terminal interface rather than an editor, which is a deliberate audience choice, not a limitation.
The agent loop. The part that actually does the work: calls the model, runs tools, reads and writes files, retries when something fails. Jay V describes OpenCode as "a two-part product. There is the UI and the application part that you sort of see and that you interact with, but then there is the agent loop, the thing that's actually doing work while calling the LLM".
The model slot. Which model the loop calls. In a closed agent this is fixed or nearly so. In an open one it is a picker.
That third part is the whole category. Everything else in the comparison, terminal polish, tool support, memory, is table stakes that both sides copy from each other within a quarter. Where the two designs genuinely diverge is what happens when a better model ships from a lab that is not the one who wrote your agent. For a wider map of the tool categories around this one, from autocomplete to agentic, see AI developer tools and the 3x productivity gap.
The split between the interface and the loop matters commercially too, and not in an obvious way. Because the loop can run separately from the interface, other people can embed it. Jay V described Ramp building an internal Slack bot that ran OpenCode behind the scenes, and published a post about it, before OpenCode had built anything like that itself. That is a distribution surface a closed agent does not have.
The open slot is a position, and positions are winnable
The most transferable thing in the interview is not a growth tactic. It is how the position was chosen, on purpose, before the growth.
The team had done this once before with a project called OpenNext. Jay V's summary: "when you've got a dominant or in this case two dominant players in the market, the rest of the market coalesces around an open alternative." And then the part founders skip: "if you pick it, it's very hard for somebody else to displace you. And if it's open, you should try and become the default as quickly as possible."
The name was part of that. So was a decision most teams would have called scope creep. To claim support for 70 plus models and providers at launch, they needed a database of models and providers that did not exist, so they built and open sourced one as a separate project, models.dev. That is what occupying a position looks like in practice: you build the missing infrastructure the position requires, and you give it away, because the position is worth more than the artifact.
Being open is not the product, though, and this is where most open alternatives die. The open source community is a demanding customer base. Thomas Wolf, co-founder and chief science officer of Hugging Face, put it plainly on YC's Root Access: "your clients is basically the open source community and they're very difficult to please as clients because everything is free so they want actually the best."
OpenCode's answer was taste in a specific direction. The founders were Neovim users who looked at the first wave of terminal coding agents and thought the terminal experience itself was below the standard set by the tools they already lived in. Jay V says they held the bar at something "that everybody uses every single day". If you are building the open alternative and your pitch is only that you are open, you have a license, not a product.
The unlock was the models, not the agent
OpenCode launched in the middle of last year, and at launch the pitch was narrow: bring your existing Claude Code subscription and use it here instead. Two separate things changed after that, and it is worth keeping them apart because founders routinely collapse them.
First, open weight models got good enough. Jay V puts the first credible crop around August and September of last year, roughly six months behind the frontier at the time, and says that each time the open model market took a step up, OpenCode saw a corresponding step up in users. The threshold he names is not benchmark parity. It is that the models became "good enough for real work", which is when running the agent on them stopped being an experiment.
Second, and separately, model preference turned out to be genuinely contestable. For a four week span in February, OpenCode's data showed users reaching for Gemini more than for Anthropic's models, which had never happened before in their data. That is not an open versus closed result, and Jay V does not present it as one. It is a signal that the model layer was no longer a single default, which is exactly the condition under which a product built around a model picker becomes valuable. It is also what convinced them to launch a paid subscription.
The same pattern shows up well outside coding. Decagon told a16z that once a use case is solidified and running in production at scale, "it's strictly better to use open source models", and that around 90 percent of its workflow now runs on them. We wrote a full decision guide on that split in Open Source LLM: Where It Actually Belongs, including what switching actually costs.
OpenCode publishes its own usage data at opencode.ai/data, which is unusual and worth reading if you sell to developers. The page moves, so treat any figure from it as a snapshot. In the walkthrough Jay V gave in July, the top of the chart by token volume was two DeepSeek models plus GLM, and the single most used model was DeepSeek Flash. It was used heavily for two boring reasons. It is cheap enough that users switch to it as they approach a daily or weekly limit so they can keep working. And it was hosted at a high enough tokens per second that, in Jay V's description, it felt like working almost in real time. Cost and latency, not capability, decide a lot of real usage.
There is a smaller signal in there too: GLM 5.2 drew usage because people believed it was better at front-end design specifically. Model choice is already fragmenting by task, not just by price.
The block was the growth event
In the first week of January, OpenCode started hearing that Anthropic was clamping down on people using Claude Code subscriptions inside OpenCode. Jay V's read on the mechanism was that if the system prompt literally mentioned the words open code, the request got rejected. He hedges that read, and the hedge is worth keeping: it is his account of a block he was on the receiving end of, not a documented change.
His read on it is unusually fair. Anthropic was subsidizing that usage, so of course it wanted the subsidy spent in its own product. But the second-order effect went the other way: "what it inadvertently did was it put open code and Claude code on the same sort of pedestal." Developers who had never tried OpenCode concluded it was not just one of the other dozen or so coding agents, because you do not block something irrelevant.
One of the hosts compared it to Amazon buying Whole Foods, which was widely called the death of Instacart and instead sent every grocer in America to go find out what Instacart was.
Not long after, the other direction happened: Codex officially supported using a Codex subscription inside OpenCode, and one of the hosts cited a tweet from a Codex engineer putting roughly 5 percent of Codex subscribers on OpenCode as their main harness.
The founder lesson is not that you should go get yourself blocked. It is that in a category with two dominant players, the open alternative is the only competitor whose position is legible to everyone at once. Attacks on it read as validation, and cooperation with it reads as validation. Both directions convert.
Tokens are the new customer acquisition cost
The economics here are the part most worth stealing, because they are not the standard open source business model.
Old-world consumer and B2B companies bought users with ad spend. OpenCode buys them with tokens. That comparison is the hosts', and Jay V confirmed it is exactly what the free tier is: it exists so a new user has the first coding agent experience at all, and the whole product line is built around moving people up from there.
The chasm he describes is real and expensive. To use a coding agent well you have to understand it, and getting there burns a lot of tokens. In his words, "that is a chasm that is very hard for a lot of people, a lot of companies, to cross." Frontier labs subsidize that crossing, and a fraction of the people who cross it turn into heavy users whose spend justifies the whole funnel.
OpenCode's version has one structural difference. Because it buys inference in enormous volume, it gets volume discounts, and when a user pays per token, that discount is the margin. In Jay V's framing, subsidized usage is a cost you eat, and pay-per-token usage feeds margin directly. Between a free tier, a subscription plan at 10 dollars for open source models, and pay-per-token inference, the ladder is designed so that heavy users are the profitable ones rather than the expensive ones. That is the inverse of most seat-based SaaS, and it is worth reading alongside how to price an AI product when your cost of goods is tokens.
There is a second margin lever that only exists because the user base is global. Because usage is spread across Asia, the Americas and Europe, GPU utilization does not have the deep overnight trough a single-region product has. Jay V calls it a reasonably stable 24 hour GPU cycle, which makes rented inference capacity cheaper per unit of work than it is for a competitor serving one part of the world. Global distribution is usually filed under growth. Here it is an infrastructure margin.
That global base is not a rounding error. On the data he walked through, China was the largest country at 17 percent, Brazil 5 percent, and Indonesia 4 percent, with meaningful usage in places like Vietnam. The reason is arithmetic: a 200 dollar per month subscription is out of reach in most of the world, and a 10 dollar plan on cheap open weight models is not. The surprise, per Jay V, was that the plan then grew well in the United States too. That exclusion is the same constraint founders describe from the other side, where a frontier-tier token budget has quietly become the access problem for AI startups in India and everywhere priced like it.
What enterprises actually buy from an open source coding agent
Not cheap tokens. Large companies with effectively unlimited token budgets adopted OpenCode anyway, and the reason Jay V gives is optionality: they did not want to be locked into a specific model or a specific harness, and an open agent was the neutral option that kept the future switchable.
The adoption path inverts normal enterprise sales. Instead of a procurement dance, the inbound arrives as a security questionnaire from a company that has already deployed you. As one of the hosts put it: "You really know you have product market fit when like enterprises are bugging you to sign the security agreement so they can use your product."
What they ask for next is more interesting than the adoption itself:
- Official sanction for what developers already installed. The first ask is usually just to make existing usage legitimate.
- Non-technical users. Once a company sees the agent loop working, it wants people outside engineering on it.
- Embedding the loop in their own product. Some want a coding agent inside their product's core loop, which is the Ramp Slack bot pattern generalized.
- Token budget controls. Not every team needs a frontier model, so companies want to cap access and manage spend by org.
- Visibility into what everyone is doing. Jay V flagged this last one as a request they had to think about, rather than a feature they were happy to ship.
He is right to hesitate, and this is where an open source coding agent changes your security posture in both directions. On the good side, you can read the loop, pin a version, run it against a model you host, and keep your source out of a vendor whose subprocessors you have not reviewed. If that is the direction you are headed, the practical tradeoffs are in self-hosted AI agents.
On the other side, the agent loop runs on a developer's machine with that developer's credentials and the ability to execute commands, which makes the blast radius every secret on that machine, open source or not. And the monitoring request deserves its real name: the same telemetry that gives an engineering leader useful visibility is employee surveillance if you do not scope it. Decide what you log, who can query it, and how long you keep it before you roll the agent out, not after your first incident review.
The 16 year overnight success
The company behind OpenCode is old. Jay V started it in his second year at university, around 2006 to 2007, after a co-op term convinced him he did not want a job. He recruited the smartest person he could reach, his college roommate Frank, and named the company Anomaly, which he now describes with the appropriate amount of embarrassment about being 21. The legal entity was incorporated in 2010 and still exists.
Between 2016 and 2021 they applied to Y Combinator nine times, according to the hosts, and got four interviews. They were finally accepted in 2021, with a serverless platform best described as Heroku for AWS, which became their first large open source project. The third co-founder joined after that.
Two things from that stretch actually compounded.
The first is building in public, which started as a nudge from YC and then became identity when a co-founder made the obvious argument: all your code is public and you work in public, so not talking about it publicly is a disservice to the product. The metrics in this interview are a direct output of that decision, and so is a community that follows the company the way people follow a show.
The second is eccentric taste. Before OpenCode, one of the founders built a terminal storefront where you buy coffee over SSH, on the theory that a hardcore developer in the terminal all day should not have to open a browser. It is a joke of a business and it was a real demonstration of what the team could build in a terminal, for exactly the audience that would later judge a terminal coding agent. Jay V's own summary is that it "generalizes to like having eccentric tastes", which is how you end up at outlying ideas.
The honest framing of the whole arc came from one of the hosts: catching lightning in a bottle requires positioning the bottle correctly and knowing what to do when it strikes. Ten years of dead ends taught this team consumer acquisition, open source distribution, and enterprise product, and OpenCode is the first product where all three are needed at once.
Five tests before you build the open alternative
The play is available in more categories than coding agents, but not in all of them. Run these before you commit:
- Are there one or two dominant closed players? The open slot is a position relative to incumbents. Without them, you are not the open alternative, you are just an unknown product with a public repo.
- Is the incumbent's pricing excluding most of the market? OpenCode's global base exists because 200 dollars a month is impossible in most countries. If the incumbent is already cheap enough for everyone, there is no wedge.
- Can you become the default quickly? Name, docs, and the missing infrastructure the position requires. If claiming the position takes you two years, someone else claims it in one.
- Does money arrive without a sales team? Margin on inference bought at volume, or a subscription. If the only model you can name is support contracts, the position is not monetizable at your stage.
- Can you hold a daily-use product bar? The community judges you against the best tool they have, and everything they use is free, so open is the entry ticket and not the differentiator.
If four of five are yes, the position is probably real. If the only yes is the first one, you are building a fork with a marketing plan.
What to do this week
- Install an open source coding agent alongside whatever you use now and run it against your actual codebase, not a toy repo. You are testing the model slot, so run the same task through two different models in it.
- Price the paid path before you standardize. Work out what your team costs per month on pay-per-token inference at your real usage, not on the free tier.
- Write down the blast radius. List the credentials on a developer machine your agent can reach, and decide what you would rotate if that machine were compromised tomorrow.
- Decide your logging policy before rollout: what the agent logs, who can query it, how long it is kept. Do it now, while it is a design choice rather than a personnel issue.
- If you are building an open alternative to something, run the five tests above and be honest about how many are actually yes.
- If your product is global, check whether your infrastructure utilization curve is already flatter than your competitors'. That is a margin advantage most teams never notice they have.
The broader pattern here, that the model layer is becoming a slot you choose rather than a vendor you marry, is the same one running through every layer of the stack. We map it out in AI for startups, and it is the operating model the course is built around: AI Operating System for Startups.
Sources
- He Built the World's #1 Open-Source Coding Agent on Y Combinator's Lightcone Podcast, the interview with Jay V that this article distills: growth numbers, unit economics, the Anthropic block, enterprise pull, and the company backstory.
- OpenCode and its public usage data at opencode.ai/data, plus the models.dev model and provider database the team open sourced.
- Jay V's profile: LinkedIn. Company profile: OpenCode on Y Combinator.
- Lessons from Building Open Source Libraries on YC's Root Access, with Thomas Wolf of Hugging Face, for the point about the open source community as a demanding customer base.
- How Decagon Runs 90% of Its Agents on Open-Source Models on a16z, for the independent read on when open weight models beat frontier models in production.
Frequently asked questions
What is the best open-source CLI coding agent?
There is no single answer, because the choice is really a choice about the model slot. If you want to run the newest open weight model the week it lands, pick the agent with the widest provider support and a model picker you can change without editing config. If you want to run inside your own network against a model you host, pick the one whose agent loop can be embedded and run separately from its interface. If you mostly want the best single model and do not care whose, a closed agent from that lab will usually be tuned harder for it. By usage, OpenCode is currently the largest open source coding agent: its founder said on Y Combinator's Lightcone podcast that it reached about 13 million monthly active users at the end of June and was processing around 7 trillion tokens a day. Size is a reasonable proxy for how quickly a new model shows up in the picker, which is the thing you are actually buying.
Is there a free AI coding agent available?
Yes. Open source coding agents are free to download and run, and several offer a free hosted tier on top. What is not free is inference, so the real question is who pays for the tokens. When an agent is free to use with models included, someone is subsidizing the tokens on purpose. OpenCode's founder Jay V confirms that the free tier is the acquisition cost: it is how a user gets the first coding agent experience at all. In the same interview the hosts put the general version of it, that tokens now buy users where ad spend used to. That subsidy is real and it is temporary by design. If you are adopting one at work, price the paid path before you standardize on it, because the free tier is the top of a funnel, not the product you will end up on.
Which model should you run in an open source coding agent?
Run more than one and switch by task and by budget, because the point of an open agent is that the model is a setting rather than a commitment. The rule that holds across the industry: keep a frontier model for work that is new or still being figured out, and move solidified, repeated work to an open weight model. Decagon told a16z that once a use case is solidified and running in production at scale, it is strictly better to use open source models, and that around 90 percent of its workflow now runs on them. For coding specifically, OpenCode's Jay V dates the first credible crop of open weight coding models to around August and September of last year, roughly six months behind the frontier at the time, and says the threshold that mattered was them becoming good enough for real work. Real usage then gets decided by cost and speed as much as by capability: the most used model on OpenCode's public data was a cheap fast one, because users switch to it as they approach a plan limit so they can keep working.
Should my startup build an open source alternative to a closed product?
Only when the category already has one or two dominant closed players, because that is what makes the open slot a real position rather than an empty one. Jay V's argument is that when a market has dominant players, the rest of the market coalesces around an open alternative, and that once you occupy that position it is very hard for someone else to displace you, so the job is to become the default as quickly as possible. Three things have to be true for it to work: the incumbent's pricing or lock-in has to be excluding a large part of the market, you need a business model that is not support contracts (OpenCode's is margin on inference it buys at volume), and you have to hold a product bar high enough that people use it daily. Being open is the position. It is not the product.
Build your AI Operating System
A practical course to grow with AI, build internal tools, and operate safely. Join the waitlist and you'll be first in when the course opens.