# ⚡️OpenCode: Claude Code but Open Source, with Any Model, and frontier TUI - with Dax Reed (@thdxr)

Latent Space · 2025-08-05

<https://addtry.com/c62032c9-63cb-475f-9183-2595c7dfa202>

Dax Reed of OpenCode and SST explains why his open-source terminal-based agent is a serious alternative to Claude Code, emphasizing that the real battle is product experience, not squeezing 3% more from LLMs. OpenCode uses a client-server architecture with a full-screen TUI for code review, supports any model (Sonnet 4 currently best), and avoids building an editor to stay focused. Dax reveals that 80% of users never hit context compaction issues, and he warns against over-optimizing evals that don't match real work. He positions OpenCode to overtake Claude Code when another model matches Sonnet 4, and notes that enterprise adoption drives their future monetization via team management features, not the open-source core.

## Questions this episode answers

### How does OpenCode differ from Claude Code?

Dax Reed explains that OpenCode uses a full‑screen TUI (terminal user interface) rather than a CLI, enabling responsive layouts, modals, file explorers, and diff viewers built for code review. It is model‑agnostic, supports shareable session snapshots via URL, has configurable modes for different tasks, and uses a client‑server architecture with planned mobile and web clients.

[5:37](https://addtry.com/c62032c9-63cb-475f-9183-2595c7dfa202?t=337000)

### Is the $200/month Claude Max plan cost‑effective for AI coding?

Dax Reed shares that after using the $200/month Claude Max plan, he switched to pay‑per‑use via OpenRouter and found he spends less. He believes he wasn’t getting full value from the subscription, though he notes a colleague who uses Opus heavily likely does. He suspects the Max plan is a growth strategy, not a sustainable long‑term price.

[24:26](https://addtry.com/c62032c9-63cb-475f-9183-2595c7dfa202?t=1466000)

### What should I know before contributing a pull request to OpenCode?

Dax Reed asks contributors to open an issue and discuss before submitting pull requests, because OpenCode is a ‘producty product’ where unsolicited features can degrade design. He views open source as best for long‑tail integrations (models, languages) while core features need careful curation to avoid a committee‑driven outcome.

[25:39](https://addtry.com/c62032c9-63cb-475f-9183-2595c7dfa202?t=1539000)

## Key moments

- **[0:00] Intro**
  - [0:56] Dax Reed created an SSH-only coffee company, proving terminals can offer great e-commerce UX.
  - [2:04] OpenCode originated from Neovim users Dax and Adam seeking a terminal-based AI agent inspired by Claude Code.
- **[3:12] TUI Demo**
  - [3:28] Being a customer of your own tool makes product decisions easy; Dax integrated LSP for immediate error feedback based on his own workflow pain.
  - [4:01] OpenCode favors product experience over chasing small LLM efficiency gains, which plateau quickly.
  - [5:31] OpenCode uses a full-screen TUI with modals and responsive design, going beyond Claude Code's simple CLI output.
  - [6:45] OpenCode's share feature snapshots a session into a shareable URL with diffs, built for enterprise engineers to learn from AI interactions.
  - [8:20] Dax Reed sees code review as the core task with coding agents, so OpenCode builds diffs, revert, and rollback features.
  - [9:12] Adding an in-agent code editor is a trap, warns Dax, citing Warp's struggles with formatting and syntax highlighting.
- **[10:15] Architecture**
  - [10:46] The OpenCode agent loop exactly replicates Claude Code's implementation when using Anthropic models, re-using their prompts and tools.
  - [11:40] OpenCode will ship modes this week, letting users cycle through custom prompts, models, and tools, replacing a separate plan mode.
  - [14:29] OpenCode's server is a bun single-file executable written in TypeScript, requiring no Node.js and dynamically downloading provider adapters.
- **[16:40] LLM Strategy**
  - [17:38] Dax Reed avoids fancy LLM optimizations because base model improvements quickly render them unnecessary, so OpenCode focuses on permanent product work.
  - [19:58] Dax Reed on coding benchmarks: 'Most of these evals are like, you know, solve this maze, and I'm just like, I'm never solving a maze.'
  - [21:21] Dax ported Gemini CLI's edit fallback strategies into OpenCode, resulting in loop bugs and corrupted files; he reverted them after weeks.
- **[22:31] Model Economics**
  - [23:50] OpenCode is conservative with telemetry because enterprise companies reject tools that collect code data, even for usage stats.
  - [24:26] Dax Reed switched from Claude Max to OpenRouter and found he spends less than $200 per month, questioning the plan's value.
- **[25:26] Competition**
  - [25:39] Dax Reed pleads: 'Stop submitting PRs without talking to us. Please open an issue first.'
  - [26:21] Open source often makes products worse by design-by-committee; OpenCode uses it for the long tail of integrations, not core features.
  - [27:48] OpenCode is number two to Claude Code today but will overtake it the day a non-Anthropic model matches Sonnet on coding.
  - [30:00] Dax Reed on Cursor's hiring of Claude Code creators: 'I'm a little confused... they made them head of product and head of engineering, which is a very large scope.'
  - [32:57] Dax criticizes AI coding's obsession with 3% LLM efficiency gains while ignoring basics like running formatters after file edits.
- **[33:59] Monetization**
  - [34:25] OpenCode's core will never be monetized; a commercial layer will sell enterprise auth, metrics, and oversight.
  - [35:50] Dax Reed: 'We were looking at the problem and we're like, we're gonna feel really stupid if we don't work on this.'

## Speakers

- **Alessio** (host)
- **Swyx** (host)
- **Dax Reed** (guest)

## Topics

Agent Platforms

## Mentioned

Anthropic (company), OpenAI (company), SST (company), Claude Code (product), Cursor (product), Gemini (product), OpenCode (product), Opus (product), Sonnet (product), Warp (product)

## Transcript

### Intro

**Alessio** [0:03]
Hey everyone, welcome back to another Latent Space Lightning Pod. This is Alessio, partner and CTO at Decibel, and I'm joined by Swyx, founder of Small AI.

**Swyx** [0:12]
Hello, hello, and we have a lightning pod today f- with, uh, Dax Reed of OpenCode. Welcome.

**Dax Reed** [0:17]
Hi, nice to meet you guys.

**Swyx** [0:20]
Dax, actually you wear a number of hats, SST and like Meme Lord, poster extraordinaire on Twitter. How do you introduce yourself?

**Dax Reed** [0:27]
Yeah, I guess m- my most recent stint has been building stuff for developers for the past five or six years, for I guess five years. Uh, every-- all my work has been open source, building tools to help developers build things.

But that's when I started becoming a little bit more public about my work, 'cause, you know, it makes sense to, in that case. Uh, and then that's kind of spiraled into quite a few different things at this point.

**Swyx** [0:51]
Yeah, uh, including most notably, like a coffee terminal?

**Dax Reed** [0:56]
Yes. Uh, yeah, so we're gonna be talking about the terminal a lot today. But uh, yeah, so about a year ago, we launched a coffee company, uh, me and a few other, uh, people. And the, the trick was you can't buy it off a website, you have to SSH into a server.

And you actually get a really good experience. Like it's actually good UX and it's a pretty good, uh, e-commerce experience, but it's all done through the terminal. And yeah, that's like a thriving business that's continuing to go to this day.

Originally started as a joke. Yeah, it's a coffee company that you can only buy through SSH. Um, but yeah, we, we focus on developers. That was like kind of my initial... That was around that time was my initial shift of like really understanding the terminal, what can be done with the terminal, how far you can push it.

Uh, so yeah.

**Swyx** [1:45]
Yeah, so from, from terminal into cloud code competitor. Um, yeah, like, you know, let, let's, let's open the door wide. You work on OpenCode. I just call it open source cloud code, but like at this point, it's actually you're adding features that are not in cloud code.

So yeah, maybe let's talk about the origin story.

**Dax Reed** [2:04]
Yeah. So me and, so the other person I work on with is Adam. I mean, like the whole SST team is working on it now as well, but me and Adam were working on it initially together. We both are Neovim users.

**Swyx** [2:13]
Yeah.

**Dax Reed** [2:13]
We love Neovim. We have a great time using it. And with all these new AI tools that came out, like Cursor started to get popular, we were starting to feel like, are we gonna get kind of left behind?

Like, do we have to move off of this thing that we enjoy using? So we're kind of in limbo, and we'd always talk about how no tool really served us well. And then Cloud Code came out, and it was kind of like, oh, duh, this is a really good way to solve this problem, just have a separate terminal app that can run anywhere, whether it's, you know, on your computer, on a server, in GitHub Actions, whatever it is, it's really flexible.

So we liked that, but uh, you know, us having done so much stuff with terminal-related software, we had a lot of ideas that we wanted to implement, both on the terminal UX side, but also on the functionality side.

Um, and we didn't wanna like wait for Cloud Code to try to do that. And also we wanted to experiment with other models. So definitely deeply inspired by that form factor that they put out, but at this point, we're kind of driving in a, a different direction, I would say.

### TUI Demo

**Alessio** [3:12]
And how-- I think this is something that a lot of people run through. How do you figure out what you think you should spend time building, even though it's not in Cloud Code yet? You know, you can kind of see where the puck is going-

**Dax Reed** [3:22]
Yeah

**Alessio** [3:22]
... versus just saying, "Hey, look, even if they'll build it or maybe it'll kind of divert, we'll just go our own path anyway."

**Dax Reed** [3:28]
Yeah. I mean, the thing I always say is it's really easy to be a founder when you are the customer also. We just build stuff that we need and we'd like to see in, in, in our workflows. Like very early on, we integrated LSP stuff so that the LMS could get errors that, uh, like if it wrote a file and it, and it like created an error, it would get that feedback right away.

We just kind of run up on that ourselves, and then we implement it. Uh, and o- obviously, with open source, you have a pretty engaged community that like really talks to you and works through kind of product features and, and things like that.

So it's been really easy to figure out what to do, what to work on. I think the clarity we have is we're not trying to get the next three percent of efficiency out of the LLM. Um, I think that's kind of like an infinite rabbit hole you can dive down that has like plateauing results.

So for us, we're more focused on product experience and like how to package it and what stuff needs to go around it. So we don't spend too much time on trying to like quote unquote "innovate" on getting the LLMs to do what we tell them to.

**Swyx** [4:34]
Yeah. I, I think, uh, we had some screen sharing-

**Dax Reed** [4:37]
I think you're muted

**Swyx** [4:37]
... so we might wanna bring that up. Mostly for YouTube, you know? Like people wanna have something to look at apart from our pretty faces.

**Dax Reed** [4:44]
Still muted.

**Swyx** [4:47]
Am I muted? You can't hear us? Hi.

**Alessio** [4:49]
Yeah, you're muted.

**Swyx** [4:51]
Okay, well keep going then.

**Alessio** [4:53]
Still cannot hear you. We'll, we'll, we'll cut this part out.

**Dax Reed** [4:56]
Yeah.

**Alessio** [4:58]
I think maybe we can screen share just to like go through the high level of the product, give people a sense for like the, the shape of it. I think everybody's familiar with Cloud Code at this point if they're listening to this.

But maybe highlight the things that are like most surprising or like, you know, you think you have like some different take than what people are expecting.

**Dax Reed** [5:16]
Yeah, sure. You guys can, uh, can see? Uh, okay, so I'm just gonna run it up in the, uh, like in our OpenCode code base itself. Um, I'm zoomed in a little bit too much. Just updated. Hang on.

So like off the bat, the main thing-

**Swyx** [5:33]
I like that you haven't figured out the update

**Dax Reed** [5:34]
...

the main thing is we are TUI, terminal user interface, which means we go full screen, and we try to like take over your whole screen and render. It kind of allows for more complex rendering possibilities. If you look at something like Cloud Code, it's a more minimal approach where it's just a typical CLI output, but then there's like a footer that's a little bit dynamic.

And you can do quite a lot with that. Like you can see with Cloud Code, they've implemented, uh, like a lot of features that way. But you know, it can only go so far. So for us, we are like a full-screen experience.

The main loop is very similar to Claude Code, right? So you just, you know, type in a prompt, you know, analyze my code base, uh, and it'll, you know, do, do the work. I guess the key difference here is this is not specific to any model.

We happen to be using Sonnet 04 'cause practically today it's the best one for this type of thing. But at some point in the future, that'll change, and this'll still be a good tool to use with whatever kind of shifts in the model, uh, space.

**Alessio** [6:41]
Yeah. The-- I noticed the share thing at the top.

**Dax Reed** [6:45]
Yeah.

**Alessio** [6:46]
I don't think Claude Code has that. How does that work? Where do you-

**Dax Reed** [6:50]
Yeah.

**Alessio** [6:50]
Yeah.

**Dax Reed** [6:50]
Yeah, so we have this feature. Uh, we actually, we actually just broke it, so let me-

**Alessio** [6:56]
Let me see.

**Dax Reed** [6:57]
I'll show you an example that I already had up. This isn't a great example, but basically this snapshots, uh, your session, and it gives you a URL that you can share with other people. This seems like a random feature, but the reason we built it is a bunch of bigger companies are really interested in having engineers learn from each other in terms of how to use these tools, so they wanted to be able to include with every PR, like a snapshot of the conversation.

Um, so link will give you, uh, a full, um, like history of the conversation, all the tools called. You'll see like file diffs, you'll see everything that changed. Um, so it's like a way that other... When you're reviewing a PR, you can be like, "Here's how it was generated."

It's great for debugging, great for collaborating. So it's a basis of something bigger. We'll probably end up fleshing this out, but right now it's like a simple single URL.

**Alessio** [7:51]
Yeah.

**Dax Reed** [7:52]
Um, so if you-- Again, going back to like the, the TUI thing. So you see we can do things like modals. We can even, we even have this, uh, you know, you can zoom out a little bit. It's responsive for one.

You saw like, you know, like just like a web app. Uh, there's like a file explorer, you can look through files, you can see, uh, diffs. This is all like pretty early, but the idea here is, um,

code review tools, effectively. Like when you're talking to these LLMs, the work you're doing is not writing code, it's reviewing code. So we're trying to build features that are good for someone that needs to, to review code. So being able to see diffs, being able to see what changed, being able to revert, roll back, things like that are all, all, all on our roadmap.

**Swyx** [8:37]
Yeah. This, this reminds me a lot of a similar episode that we did with Warp, where they started from the terminal, but then they, they're adding in code review UI that is, that is approaching an IDE, but not quite, you know?

**Dax Reed** [8:51]
Yeah.

**Swyx** [8:51]
It's, it's weird, like either, either you form... Either you, you know, fork VS Code or you build VS Code.

**Dax Reed** [8:57]
Yeah. It's-- So the, the... I see-- I think one of the traps here is almost immediately we're like, "Oh, we should build edit functionality. Like, we should let you edit files in here." But that's a trap because that is like an infinite rabbit hole of work.

And I've seen this with Warp already, where I think they have an editor in there, and people are asking like, "Oh, like this needs to work with my formatter," or like, "The syntax highlighting isn't working," or, "I wanna see my errors in there."

So the whole edit thing is a super deep hole to go down. So we're staying away from the editor, like you're gonna use this alongside whatever editor you choose to use. But we think we can do some stuff for the review part.

**Swyx** [9:33]
So the, the i- the idea is that you only interact with prompts, right? You never di- do direct code manipulation yourself. Or is that something different?

**Dax Reed** [9:43]
I think for me, I do not really use it that way. Some people do, but I use it alongside my editor. So some people run this inside VS Code-

**Swyx** [9:51]
Separately

**Dax Reed** [9:52]
... but, uh, I- I'm flipping back and forth. But yeah, yeah, you're right. Like, in this tool, you're not editing the code at all. You use whatever editor you prefer.

**Swyx** [9:59]
Yeah, amazing. And then like, so, you know, I think there's, there's a lot of questions about the core agent harness, agent loop. Um, yeah, let's just like talk about the technical lesson on the, the journey that you went through.

### Architecture

**Swyx** [10:15]
Where did you start and where, where have you ended up?

**Dax Reed** [10:18]
Yeah. So I, I obviously didn't know about any of, how any of this stuff worked until we're like, maybe like about two months into dev- into development, so roughly two months ago. I knew that all an agent was, was a loop running somewhere.

And in that process of doing this, I've like learned some of the details about that. Like I said, we don't try to innovate on how that works. We look at Claude Code, we dump all their system prompts, we dump all their tool descriptions, we dump all their tool schemas, we re-implement the tools.

And when you're using an Anthropic model, we basically have the exact same implementation. Some of the details of how to figure, like some of the prompt caching stuff was tricky to understand how that worked. But at the end of the day, like it's just a loop where you send the prompt with a bunch of tool descriptions.

It tells you what tools to call. You call the tools, send the results back. And there's really not too much magic there.

**Alessio** [11:11]
Yeah, let's run through maybe outside of... I, I think the, this is the prompt to code kind of thing, and then, uh, I think what people like about Claude Code is, uh, the plan mode, kinda like the think mode.

There's kinda like all these different ways to use it. What, what does this look like here?

**Dax Reed** [11:27]
Yeah. So we're still exploring exactly how that's gonna look. Uh, so plan mode is one of the most requested features. We're probably gonna ship it this week. But we're not implementing it as an explicit plan mode. We're implementing the concept of modes.

So you'll be able to hit Tab and cycle through different modes. Uh, we'll have a built-in like plan mode and implement mode, but you'll be able to extend this with your own types of modes. And all a mode is, is a combination of a custom system prompt, optionally a different model, and optionally a different set of tools.

So you can make a mode where you're like, "I wa- I like talking to Gemini when I'm doing, like, larger code-based things." So you can have like a Gemini mode that you can tab into. It'll switch to using Gemini.

It'll take advantage of the larger context. It'll maybe only pass it read-only tools. Um, and then once you have a plan there, you can, you can tab back and get to implement mode, which might be done with Sonnet and actually do the implementation.

So yeah, we're still exploring exactly what that is, but I think we've-- we can solve both the desire for a plan mode and also the desire for talking to different models in, in different cases.

**Alessio** [12:30]
I, I think, you know, when we did the Claude Code episode, uh, with Boris and Cat, uh, Boris called it like a Unix utility.

**Dax Reed** [12:38]
Yeah.

**Alessio** [12:39]
I think to me it seems like they're moving more and more towards having some of these product things in Claude Code, like the plan thing. It almost feels to me like, you know, you should plan in an LLM that can then use Claude Code.

It's like-- or, you know, OpenCode as the tool to implement. But it seems like the two things are kind of merging, and I'm trying to figure out if you think that's the same direction you think it'll go, or it'll be more and more separated.

**Dax Reed** [13:02]
Yeah, this is one of those things where I don't think there's a trade-off with doing both. So OpenCode also can be used like a Unix utility. You can run a command in your CLI, pipe it into OpenCode, pipe the results, send it somewhere else.

Like it, it works the same way you'd expect like a very minimal utility would. Uh, but then the TUI experience, I think so the one other difference between us and Claude Code is under the hood, there's a client and server architecture here.

So OpenCode is a server that has a built-in TUI client. We can have, we can have other clients in the future. We're starting work on a mobile client. We're gonna start work on a web client. Uh, we're gonna have a desktop app.

So the server is the utility part. This TUI experience you're seeing is our, like, opinionated version of what a product around OpenCode could look like. But you know, that's gonna look different based on how we choose to package it in different places.

Or people might end up implementing their own that's better than ours in, in certain cases.

**Swyx** [13:58]
Yeah. Um, you, I mean, you have-- I'm, I'm on your GitHub, and actually, you, you've done a nice job of, uh, documenting your sort of modular choices. Any other sort of like technical decisions that might be interesting?

**Dax Reed** [14:11]
Yeah.

**Swyx** [14:11]
A lot of people have, have to deal with like Claude Code's, like compacting. That's like a big one. You have a SQLite persistence thing. I, I don't know if that's different from Claude Code. Uh, anything, anything that you're, you're, that you're particularly proud of.

**Dax Reed** [14:24]
You, you, you might be on the, you might be on the wrong GitHub. So we don't use SQLite, but just kind of going into some of that.

**Swyx** [14:29]
Yeah.

**Dax Reed** [14:29]
So, uh-

**Swyx** [14:30]
Yeah

**Dax Reed** [14:30]
... the, uh... So yeah, the underlying architecture is a little weird, but I've actually now started seeing a bunch of these tools move towards it. This is-- the Claude server is written in TypeScript, and it is a bun single file executable.

So we compile that into a native executable across, uh, you know, Mac, Windows, Linux. It just works. There's no dependency. You don't need to install Node.js or anything, so it kinda runs anywhere. And the nice thing is we can also take advantage of any bun internal functionality.

So for example, we don't ship with adapters for all the different like LLM providers. They get downloaded dynamically as you use them. So if you configure, uh, Anthropic or OpenAI, it'll dynamically download the provider for that. That's all done through, you know, bun install.

And bun can also run JavaScript code, so our config can have custom tools that you implement in JavaScript that we can just kinda import and, and run dynamically. There's nothing to like... There's no complexity in doing that. So building on bun and this kind of full TypeScript stack allows for some of these interesting things.

And because it's a server, the front ends can be in other languages if it, if it makes sense. We honestly would've built the front end in JavaScript also, but for a high-performance terminal interface, there just aren't good libraries in JavaScript.

We probably will end up building one at some point, given like how deep we've gone into this world. So that's like on the packaging side. Uh, I've seen now Claude Code in their job posting, they actually mention specifically they're hiring someone that has experience in bun executables.

I think I saw Amped is also doing something similar now. So it just kinda makes sense. I think bun really unlocks building something in JavaScript and TypeScript with, you have these great libraries without the trade-offs of it being like annoying to run.

Um, so that's like the key packaging stuff. In terms of some of the LLM tech, like you're saying, the compaction thing, we implement compaction probably in the same way as Claude Code. We, I haven't really looked too deeply into it.

When you approach a context window, we run a compaction process. To be honest, most people haven't complained about this. Like, it comes up occasionally, but people tend to start new sessions pretty frequently. They tend to not have super long-running things that often.

### LLM Strategy

**Dax Reed** [16:56]
So it is a problem that needs to be solved, but it's one of those 80% of the times you don't hit it type of thing.

**Swyx** [17:03]
Oh, okay. Uh, I, I think I just see a lot of tweets about, um, "Oh, you know, I'm running out of the context window, so I, so I'm in trouble."

**Dax Reed** [17:10]
Yeah.

**Swyx** [17:11]
But yeah, I, I've actually thought about instead of doing compaction as such a sort of destructive process, what if it was non-destructive and you sort of do rag on it, you know, rag on your own conversation history? I, I feel like, uh, you know, c- base-based on what you say, no, people don't even get there, but, like, I, I think people k- like, the power users seem to all run into compaction issues, so I don't know.

**Dax Reed** [17:38]
Yeah. So this is one of those areas where, uh, I'm kinda glad I am working on this not early in my career because there's just so many things you could be working on. There's so many degrees and directions you can go in, and I think I-- the experience we have kinda guides us a little bit.

So yeah, so the example you gave, like the compaction problem, right? There-- If you look at a lot of the other tools, they talk about this a lot. They have all these tricks. People are trying all these different things.

We basically never try to get fancy with, with those. Because it's one of these things where we've seen this a few times where any kind of fancy optimization you're doing on top of the LLM eventually gets, like, you kinda lose the need to do it given how fast things are moving.

It doesn't mean every problem is automatically gonna be solved, but an example of this is like the, uh, fast edit models that came out for a while, where, uh, LLMs were bad at editing or describing the edit they wanted done to a file.

But these specialized models came out, and you would like take the source LLM and have it output something and give it to that LLM, and that would do like a fast apply. It's like a really fast model that can, like, rewrite the whole file, and that was, like, improving performance by X percent.

And like their entire businesses were founded on providing that model. Uh, and then, you know, Sonnet 4 came out, and it's pretty good. It's pretty good at doing that, and we do like a little bit of fuzzy stuff on top, but we don't need to like kick out to like some kinda crazy, crazy model.

So we-- Given how fast things are moving, we try to spend our time on product things that are, like, somewhat permanent versus anything where you kinda need to be really clever in knowing what optimization is not just gonna go away in a, in a couple weeks.

**Swyx** [19:29]
Yeah, so simplicity, uh, works here. Um-

**Dax Reed** [19:32]
Yeah, simplicity work. Yeah, exactly.

**Swyx** [19:34]
Uh, I mean, there's, there's a, there's a lot... Like, do you, um, do you write evals, um, you know, in a, in a way that Aider does?

**Dax Reed** [19:43]
Yeah. So we looked at all the different benchmarks we could find, and it's almost comical how none of them look like my day-to-day work. Most of these evals are like, you know, solve this maze, and I'm just like, "I'm never solving a maze."

Like it's never anything that I'm ever asking an LLM to do. I'm usually asking it just to do something like, "Hey, I'm implementing this feature. The backend's pretty easy. I just need you to go, like, implement a new data model in the database, create a migration, expose an API, and I'll work on the front end while you do that."

Almost no benchmarks have anything that resemble anything close to that. So one of the p- people on our team, Frank, he's working right now on developing our own set of benchmarks. We don't really... I don't really care too much about being like, "Hey, OpenCode's like the best on this benchmark."

I more care about I made a change to how our editor tool works. Did I make things worse? Did I make things better? Um, this is another funny thing you see right now because nobody really has a great way to do this, so every new feature is positioned as, "We made things better."

But I've seen myself make changes where I make it better in one dimension, and it's just like horrible. I realize it's actually horrible in like the dimensions that matter two weeks down the road. So I just feel lost trying to improve this stuff.

So at first, we're trying to at least like develop some kinda benchmarks that look like what my day-to-day work actually looks like.

**Swyx** [21:05]
Yeah. I mean, uh, I think Aider is like up there. But also like I, I just was curious, like since you're building public, probably this is public, but like what, what's an example of a thing that, you know, locally, temporarily improved things, but actually you regretted it two weeks later?

**Dax Reed** [21:21]
Yeah. So I did this thing. So the edit tool, the way edit tools work on most of these tools now is you ask the LLM for the file you wanna change, the old string to look for, and the new string to replace.

And now there's some percentage of the time where it nails it. You, it, you search the old string, you find it, you replace it. Sometimes it kinda messes up what the old string looks like, and you search for it, and it's not there.

But it's usually, a lot of times it's a very simple mistake, like it used tab spacing when you used spaces. Um, so you can have a series of fallback strategies. Uh, and the client team published all of their fallback strategies, which I then ported to OpenCode.

And then I was like, "That was easy. I just had OpenCode port it. Let me go crazy." I went to Gemini's CLI, and I was like, "Let me take all their strategies too." And the Gemini ones were not good.

It was, uh, initially it looked good, but then I noticed it was getting caught in these crazy loops, and it was like editing my files in this, these totally messed up ways. And I should've known 'cause you can tell when you're looking through the Gemini code base, it's like really rushed.

So I ended up dropping those strategies, but there was at least like two or three weeks where that was definitely a regression, and I only knew 'cause I was using the tool.

### Model Economics

**Swyx** [22:31]
Nice. I mean, that, that's how you find out. But like also I, I know you have like an issue of just Gemini code in general. So you like, you know, you're able to use like Claude Code's Max and Pro Plans, and I think you tried to do that with Gemini Code, and they asked you to not do it, right?

Something like that.

**Dax Reed** [22:47]
That was a... So we actually never... That was a, I think the client team did that-

**Swyx** [22:52]
Oh, okay

**Dax Reed** [22:53]
... and they rolled it back. We, we have a PR for it. I decided not to merge it given I expected that. OpenCode's gonna have a, gonna have a plugin system in the next couple weeks, so we'll probably move all of those like TOS questionable integrations into community-maintained plugins, and people can do whatever they want there.

**Alessio** [23:13]
Talking about, yeah, model usage, do you have any high-level stats on people's usage, like what models they use, how many models, how many tokens they run through? We, we're having this discussion on, on our Discord, uh, because there's some people that use like hundreds of millions of tokens a month, and they're like, "Anthropic must be losing a lot of money."

But it seems... I don't believe there's that many people that use it at that rate, so I'm curious if you have more numbers.

**Dax Reed** [23:39]
Yeah. So we actually have been really conservative with tele- telemetry. I us- I generally don't care that much about telemetry. I'm not like some extremist when it comes to that stuff. But

OpenCode fits in a weird space where there's a lot of very boring enterprise companies that haven't used any of these tools yet because they have certain restrictions in their corporate laptop where they can't even install them. OpenCode tends to fit nicer in there, but the moment people hear about anything with telemetry and their code, it's like an immediate no-go.

So we've been really conservative about that. But anecdotally, in terms of, uh, you know, us talking to people, like us using it ourselves It's a, it's a really confusing question 'cause I've been using the Claude Max plan for the whole time I've been working at OpenCode.

And I was like, "I actually can't tell. Like, am I getting the value out of this?" So I switched in the past two weeks to just using OpenRouter and just paying per use. And despite, you know, being someone working on this tool, I actually don't use that many tokens.

I actually think if I'm paying for the $200 a month Claude Max plan, I don't think I'm using the full value out of it. I think I'd actually be spending less if I just went usage-based. But, you know, Adam uses Opus on everything and goes insane.

He probably spends-- like gets a value out of it there. So yeah, I wanna understand this a little bit more. Obviously, the economics of all this are a big question right now. I think it's pretty easy to like use more than $200 worth even by accident, so I would also lean towards that the Claude Max plans are a growth strategy, not like any long-term pricing thing that, that can work, at least at the current-- given the current state of things.

**Swyx** [25:23]
The mystery continues. Um.

**Dax Reed** [25:25]
Yeah.

**Swyx** [25:26]
I'll be, I'll be trying figuring that out. Anything you wanna ask people? Feedback that you want on specific pieces of the product? Any contributions you want in OpenSource?

### Competition

**Dax Reed** [25:39]
Yeah, it's a plan. The, the ask I would actually have is stop submitting PRs without talking to us. Um, we get some pretty awesome contributions, but, you know, this is a very... It's like a very producty product where just adding every feature, the first version of every feature is like not gonna result to a good place.

So I have it clear in the readme, like, "Please open an issue. Let's discuss it before you implement it." But I think we get these giant PRs oftentimes implemented with OpenCode. So we're like trying to figure out how to like juggle all of that and, you know, we've done OpenSource for a while, so this is not a new problem.

But I think it's definitely happening at a bigger scale than we normally expect. But our general strategy with OpenSource is

we don't think a product is good because it's OpenSource. Usually, a product is bad 'cause it's OpenSource. It tends to be like designed by committee and like just a smash of like a bunch of different competing priorities. The reason we OpenSource some of these things is because there is a part of it that has a long tail.

So getting OpenCode to work great with Gemini, getting it to work great with OpenAI, whatever model they, they release, we don't have the time to figure out all those details, so that's what the community's great at. They can kind of last mile, figure those things out, make the LSPs work for all the different languages, make the formatters work for all the different languages.

The stuff that has like there's a core, and once you build the core, there's like 100 integrations to do, that's where OpenSource really shines, and there's a lot of that in OpenCode. That's why we made it OpenSource. But core features, you know, it's, it's hard to really run it like a true OpenSource project.

**Swyx** [27:13]
Yeah, and I mean, this is why the Claude Code team didn't want to OpenSource, right? They, they, they wanted to retain ownership of the roadmap and, and not piss people off by like rejecting their PRs that they worked so hard on or, or may not.

Yeah, I, you know, I, I think that's uh, like is there a world in which like, you know, you are basically a clean superset of Claude Code, um, but you can use all the other models, so it's OpenSource, it's all pluggable, whatever.

Is there a world basically that you overtake Claude Code or like, you know, what, what's the, what's the-- where are we at one year from now?

**Dax Reed** [27:48]
Yeah, so the reality is right now, if you look at how things like the state of the ecosystem, we're always gonna be number two to Claude Code. That's, again, that's gonna be the case. We're gonna be... Our shot right now is be good enough to be number two, and I think we're fast approaching that.

What's gonna-- what we're hoping-

**Swyx** [28:07]
I, I actually think you're number two. I don't know.

**Dax Reed** [28:09]
Yeah, I, I mean, yeah, I think, I think we're basically there. But I think the point there is that was actually a pretty low bar. Um, Claude Code is like growing like insane, and it's unrealistic. Given the current state of things, we would eclipse them.

I think people are excited about OpenCode. I think we do a lot of stuff better, but there's just a momentum they have. What would change things is if there's a day where either another LLM lab or like, you know, an OpenSource model drops that is competitive with Sonnet, maybe even better than Sonnet, on that day, OpenCode's gonna be the only way to do this kind of thing, um, 'cause, you know, Claude isn't gonna do first-class support for a different, a different, uh, provider.

Um, so we're really oriented around that day happening. We think it'll happen. There's no reason to think that it won't happen or the gaps won't be closed. When that happens, I think then we have a shot of overtaking Claude Code.

But the reality is right now, Sonnet 4 is really the only model that works really well inside this kind of product, and as long as that's the case, I think Claude Code is gonna be number one.

**Swyx** [29:17]
Purely because the Anthropic brand recognition, right? But like in all the, all other respects, like, you know, I can plug in OpenRouter and that's, to me, that's a win. But maybe not to other people, I don't know. Um, yeah, but that-- I mean, that's cool.

Uh, you know, like I would s- I was gonna say like the only other people are Gemini and, and OpenAI who's, who are most likely to, you know, compete with Anthropic on, on frontier coding model. But they both have their own CLI now, so they're, they're, they're even not likely to, to jump on the Open, OpenCode train.

So like I almost think you should work with like Magic.dev.

**Dax Reed** [29:51]
Yeah.

**Swyx** [29:51]
Like even Cursor's out 'cause Cur- Cursor hired Boris and Kat, so now like-

**Dax Reed** [29:54]
Yeah.

**Swyx** [29:54]
Like f- presumably, they're gonna do Cursor code, right? I don't-

**Dax Reed** [29:57]
Yeah.

**Swyx** [29:57]
Do you have a take on that, by the way? Do you have any like-

**Dax Reed** [30:00]
Uh, I'm, I'm really-- Oh, it's funny. Their, their CEO just messaged me a couple of days ago. But, uh, like we on the terminal side-

**Swyx** [30:06]
He's collecting... Yeah.

**Dax Reed** [30:09]
On the terminal side, on the coffee side, we, uh, we have done a bunch of marketing for Cursor. We did like a crazy week-long event where we locked ourselves in a tower and tried to vibe code a game.

Um, so we're pretty friendly with the Cursor team. My-- I'm a little confused about that move, mostly because they They made the t- the team they acquired, they made them head of product and head of engineering, which is like a very large scope

**Swyx** [30:37]
Much bigger than just the, just do Cursor C- CLI, you know?

**Dax Reed** [30:41]
Yeah, exactly. So I'm like-

**Swyx** [30:43]
But like-

**Dax Reed** [30:43]
... are they gonna build a new product? Like, I'm not really... I don't fully understand that, to be honest.

**Swyx** [30:49]
Okay. To, to, to engage a little, like... And, and obviously I, I don't wanna get you in trouble. Uh, if there's a f- future version of this where you j- you, like OpenCode joins Cursor, like-

**Dax Reed** [30:58]
Mm-hmm

**Swyx** [30:58]
... you know, get that bag, right? But, like, to me, like, Claude Code, like, Boris and Cat basically made the number one most serious competitor to Cursor since Cursor.

**Dax Reed** [31:09]
Yeah, that's true. Yep.

**Swyx** [31:11]
So they bit the, they bit off their competition, like, and this is what they had to do, and they, like, they had the ability to do it with, like, presumably a much smaller team than Cursor. So, like, why not?

**Dax Reed** [31:23]
Yeah. I mean, when I saw the acquisition, I was like, "Oh, this is actually more intense now because the Cursor team is gonna move faster than the Claude Code team." I think. That's my, that's my feeling, given they have to.

There's gonna be more pressure on them, and they're smaller.

**Swyx** [31:39]
Like, to Anthropic-

**Dax Reed** [31:40]
Yeah

**Swyx** [31:40]
... it's like a side project. To-

**Dax Reed** [31:42]
Yeah, exactly

**Swyx** [31:42]
... to Cursor, it's exis- existential.

**Dax Reed** [31:43]
Yeah.

**Swyx** [31:44]
Yeah, yeah.

**Dax Reed** [31:44]
Yeah, yeah. Exactly. So, um, yeah, so we'll see. Uh, at this point, i- it's very early, so it's hard for me to, hard for me to say how this stuff shakes out. But the, the model we have in our head is we are building a tool that's really good for reviewing code.

We're starting the terminal today. There's gonna be a desktop hub, there's gonna be all that stuff as well. Uh, it comes down to whether it makes sense to have that as a separate app or people still prefer inside the editor, like, like Cursor is overwhelmingly.

So I think that's probably what it ends up coming down to.

**Swyx** [32:15]
Awesome. Um, any other commentary? Like, I think you... I love the podcast. I, I'm gonna plug Tomorrow FM. So, so you're, you're, you're a very skilled yapper.

But, like, just any other commentary on, like, other projects, other, other, other things around the code, uh, AI system that you're keeping an eye on, you're impressed by? Yeah.

**Dax Reed** [32:37]
Yeah. I think right now what it feels like is, uh, working at OpenCode has been really easy, uh, easier than anything else I've ever worked on, because there's such a low bar in terms of product. I think everyone is so obsessed with, "Here's this trick I came up with where if you, like, mix two LMS together, you get, like, a 3% better result."

That's been, like, almost all the energy, really smart people spending time on that, and I just think it's, like, a wasted place to spend time on when there's really basic stuff. Like, when the LM makes an edit to my file, it doesn't run my formatter.

There's like 100 simple things like that to fix, and we're gonna continue to fix those. Um, and we think if you add all those up, it results in a really good product. So in the product realm, as much energy there is and much money there is going to AI, I just feel like people haven't done the simple product stuff that I think anyone can do.

So we're focused there. I think we'll probably end up seeing more teams that, that kind of focus there, given that's where the battle is going. The LM companies are building their own products. Cursor is successful because of the product stuff, less so the LM...

Well, minus the tab. The Cursor tab stuff is pretty good. But, uh, yeah, so I think I, I think I just see a shift to very boring, straightforward, who can package the right product, and that's kind of where the battle is going.

### Monetization

**Swyx** [33:59]
Yeah, yeah. Uh, um, do you have plans to monetize somehow then? I, I, I don't know.

**Dax Reed** [34:07]
Yeah. So given like, uh, given our time building stuff in open source, we've tried a few different things and have a sense of how we think open source products should be monetized. OpenCode itself will never be un-monetized. The day you monetize your open source project is the day it starts to die.

There's kind of a natural fit for OpenCode in terms of monetization. When we talk to bigger enterprise-y, boring companies that, uh, wanna roll this out to their whole team, there's like all these basic, "I don't want them having to sign up for an API key.

I need to, like, have this work with our internal auth. I need to have metrics on how much each of my team is using this thing. I wanna have oversight on that." So kind of the boring, rolling this out to a big team, what kind of support software needs to exist for that, that's probably where we'll build some kind of commercial offering, but not really thinking about that super hard right now.

The focus really is how do we make this a tool that every developer can use.

**Swyx** [35:08]
Yeah, amazing. Well, congrats on your success. Uh, like I would not have... I, I think like someone would, should have come along and done it, uh, again, 'cause I'm sorry, I apologize for getting you mixed up with the other OpenCode.

Um, like, uh, I, I think some... I think like this does need to exist. We need to sort of, to have like an open s- uh, sort of standard terminal agents. Uh, I think there's a lot, there's a lot here.

I think you're like al- almost like weirdly like the right guy to do this. So I'm glad that you like decided to do it, you know, because like, um, it, there's, there's a lot of, uh, people who, who would, you know, turn this as like the next YC project and then, then it would just die after like a year or two, you know?

**Dax Reed** [35:49]
Yeah.

**Swyx** [35:50]
So.

**Dax Reed** [35:50]
Yeah. I mean, we, we almost phrased it exactly that internally. We were like looking at the problem, and we were looking at what our advantages were, and we're like, "We're gonna feel really stupid if we don't work on this."

Definitely gonna be a regretted thing. Um, but yeah, given that we're like a pr- we're a profitable company, we can kind of just focus on, on making this as big as it, as it should get. So yeah, we're positioned well.

We have the reach in the developer community. Yeah, pretty excited about-

**Swyx** [36:16]
Yeah, you do

**Dax Reed** [36:16]
... where it's going.

**Swyx** [36:17]
Yeah, I'm, I'm pretty big fan of like the whole building public thing as well. But like-

**Dax Reed** [36:21]
Mm-hmm

**Swyx** [36:21]
... you know, you, you got, you got a way with, with, uh, with communicating. Uh, okay, cool. Any, uh, shout-outs, uh, anything, call to action, anything like that?

**Dax Reed** [36:30]
Not really. Oh, I think nothing comes to mind.

**Swyx** [36:33]
Just use OpenCode.

**Dax Reed** [36:34]
Yeah, opencode.ai. Go, go check it out.

**Swyx** [36:37]
And talk before, talk before you send in a PR.

**Dax Reed** [36:40]
Yes. Open an issue before the PR.

**Swyx** [36:43]
All right.

**Dax Reed** [36:43]
Yep.

**Swyx** [36:44]
If we, if we do one thing right, we'll, we'll get that message out. So yeah, thanks so much, Dax.

**Dax Reed** [36:48]
Yeah, appreciate it. Good chatting.

---

This library is powered by PodHood (https://podhood.com), the podcast website platform.
