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

Watch the full show on YouTube: https://www.youtube.com/watch?v=Y0Hlizumgpw

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:03Alessio Fanelli?

  Hey everyone, welcome back to another latent space lightning pod. This is Alessio, partner and CTO at Decibum, and I'm joined by Squicks, founder of Smiley AI.

• 0:11Speaker 01

  Hello, hello, and we have a lightning pod today with Dax Read of open code. Welcome.

• 0:17Speaker 02

  Hi, nice to meet you guys.

• 0:19Speaker 01

  Dax, actually, you wear a number of hats, SST and like meme lord, poster extraordinaire on Twitter. How do you introduce yourself?

• 0:26Speaker 02

  Yeah, I guess my most recent stint has been building stuff for developers over the past five or six years, for I guess five years. All my work has been open source, building tools to help developers build things. That's when I started to become a little bit more public about my work, because it makes sense to in that case. And then that's kind of spiraled into quite a few different things at this point.

• 0:50Speaker 01

  Yeah, including, most notably, like a coffee terminal?

• 0:55Speaker 02

  Yes, yeah, so we're going to talk about a terminal a lot today, but yeah, so about a year ago, we launched a coffee company, me and a few other people. And 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 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, it started as a joke. Yeah, it's a coffee company that you can only buy through SSH. But yeah, we focused on developers. That was like kind of my initial, that was around that time, my initial shift of like really understanding the terminal.

• 1:39Speaker 02

  What can be done with the terminal? How far you can push it?

• 1:43Speaker 02

  So yeah.

• 1:44Speaker 01

  Yeah, so from terminal into cloud code competitor. Yeah, like, you know, let's, let's open the door wide. You work on open code. 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.

• 2:03Speaker 02

  Yeah, so me and so the other person I work on with is Adam. I mean, like the whole ST team is working out now as well, but me and Adam were working out initially together. We both are NeoVim users. 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're starting to feel like, are we going to 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 always talk about how no tool really served us well. And then Claude 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 and GitHub Actions, whatever it is, it's really flexible.

• 2:46Speaker 02

  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 in the terminal UX side, but also on the functionality side. And we don't want to like wait for Claude 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 different direction, I would say.

• 3:12Alessio Fanelli?

  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 Claude Code yet, you know, you can kind of see where the pockets going. 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.

• 3:28Speaker 02

  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 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 created an error, it would get that feedback right away. We just kind of run up on that ourselves and then we implement it. And obviously with open source, you have a pretty engaged community that like really talks to you and works through kind of product features and things like that. So it's been really easy to figure out what to do, what to work on.

• 4:05Speaker 02

  I think the clarity we have is we're not trying to get the next 3% of efficiency out of the LLM. 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 LMS to do what we tell them to.

• 4:34Alessio Fanelli?

  Yeah, I think we had some screen sharing. So we might want to bring that up, mostly for YouTube, you know? Like people want to have something to look at apart from our pretty faces.

• 4:46Speaker 01

  Am I muted? You can't hear us? Hi.

• 4:48Alessio Fanelli?

  Yeah, you're muted.

• 4:50Speaker 01

  Okay, well, keep going then.

• 4:52Alessio Fanelli?

  Still cannot hear you. We'll, we'll, we'll cut this part out.

• 4:55Speaker 01

  Yeah.

• 4:57Alessio Fanelli?

  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 Claude 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.

• 5:16Speaker 02

  Yeah, sure. You guys can, uh, can see. Uh, okay. So I'm just gonna run it up in the, uh, like in our open code codebase itself. I zoomed in a little bit too much. Just updated. Yeah. So like off the bat.

• 5:32Speaker 01

  I like that you haven't figured out the update.

• 5:37Speaker 02

  The main thing is we are TUI, Terminal User Interface, which means we go fullscreen and we try to like take over your whole screen and render.

• 5:48Speaker 02

  It kind of allows for more complex rendering possibilities. If you look at something like Claude 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 Claude 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 fullscreen experience. The main loop is very similar to Claude Code, right? So you just, you know, type in a prompt, you know, analyze my codebase, uh, and it'll, you know, do, do the work.

• 6:24Speaker 02

  I guess the key difference here is this is not specific to any model. We happen to be using Sonar 4 because practically today it's the best one for this type of thing. But at some point in the future, that'll change and this will still be a good tool to use with whatever kind of shifts in the model, uh, space.

• 6:41Alessio Fanelli?

  Yeah. The, I noticed the share thing at the top. I don't think Claude Code has that. How does that work? Where do you?

• 6:50Speaker 02

  Yeah. So we have this feature, uh, we actually, we actually just broke it. So let me.

• 6:55Speaker 01

  Let me see.

• 6:56Speaker 02

  I'll show you an example that I already had up. This isn't a great example, but basically this snapshots 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 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.

• 7:41Speaker 02

  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.

• 7:50Speaker 01

  Yeah.

• 7:51Speaker 02

  Um, so if you, again, going back to like the, the two E 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, it's like a file explorer. You can look through files. You can see diffs. This is all like pretty early, but the idea here is, um,

• 8:20Speaker 02

  code review tools effectively, like when you're talking to these L M's, 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, rollback. Uh, things like that are all, are all on our roadmap.

• 8:36Speaker 01

  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 if, that is approaching an IDE, but not quite, you know? It's, it's weird. Like either, either you form, either you know fork VS code or you build VS code.

• 8:56Speaker 02

  Yeah, it's. So the, the, I say, I think one of the traps here is.

• 9:02Speaker 02

  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 formater or like the syntax highlighting isn't working or I want to 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 going to use this alongside whatever editor you choose to use. But we think we can do some stuff for the review part.

• 9:32Speaker 01

  So the idea is that you only interact with prompts, right? You never do direct code manipulation yourself?

• 9:41Speaker 01

  Or is that something different?

• 9:43Speaker 02

  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, but I'm flipping back and forth. But yeah, you're right. Like in this tool, you're not editing the code at all. You use whatever editor you prefer.

• 9:58Speaker 01

  Yeah, amazing.

• 10:01Speaker 01

  And like, so, you know, I think there's, there's a lot of questions about these core agent harness, agent loop. Yeah, let's just like, talk about the technical lesson on the journey that you went through. Where did you start and where have you ended up?

• 10:17Speaker 02

  Yeah, so I obviously didn't know about any of how any of this stuff worked until we're like, maybe like about two months into development, so probably 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

• 11:01Speaker 02

  with a bunch of tool descriptions, it tells you what tools to call, you call it tools and the results back. And there's really not too much magic there.

• 11:11Alessio Fanelli?

  Yeah, let's run through maybe outside of, I think this is the prompt to code kind of thing. And then I think what people like about Cloud Code is the plan mode, kind of like the thing. Well, there's kind of all these different ways to use it. What does this look like here?

• 11:27Speaker 02

  Yeah, so we're still exploring exactly how that's going to look. So plan mode is one of the most requested features. We're probably going to ship it this week, but we're not implementing it as an explicit plan mode. We're implementing a concept of modes, so you'll be able to hit tab and cycle through different modes. 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 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 like talking to Gemini when I'm doing like larger code based things. So you can have a good 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.

• 12:11Speaker 02

  And then once you have a plan there, you can you can tab back and get to implement mode, which might be done what's on it 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 and in different cases.

• 12:30Alessio Fanelli?

  I think, you know, when we did the Cloud Code episode with Boris and Cat, Boris called it like a Unix utility.

• 12:37Speaker 02

  Yeah.

• 12:38Alessio Fanelli?

  I think to me, it seems like they're moving more and more towards having some of these product things in Cloud Code, like the plan thing. It almost feels to me like, you know, you should plan in LLM that can then use Cloud Code. It's like, or, you know, Open Code 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.

• 13:01Speaker 02

  Yeah, this is one of those things where I don't think there's a trade off with doing both. So Open Code also can be used like a Unix utility. You can run a command in your CLI, pipe it into Open Code, pipe the results and it's somewhere else. Like it works the same way you'd expect like a very minimal utility would. But then the two E experience, I think so. The one other difference between us and Cloud Code is under the hood, there's a client and server architecture here. So Open Code is a server that has a built in two E client.

• 13:32Speaker 02

  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. We can have a desktop app. So the server is a utility part. This two E experience you're seeing is our like opinionated version of what a product around open code 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.

• 13:57Speaker 01

  Yeah, um, you, I mean, you have, I'm on your GitHub. And actually, you've done a nice job of documenting your sort of modular choices. Any other sort of like technical decisions that might be interesting?

• 14:11Speaker 02

  Yeah.

• 14:11Speaker 01

  A lot of people have, have to deal with like cloud codes, like compacting. That's like a big one. You have a SQLite persistence thing. I don't know if that's different from cloud code, anything, anything that you're, you're.

• 14:23Speaker 02

  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. So, uh, the, uh,

• 14:32Speaker 02

  so 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, you know, Mac, Windows, Linux, it just works. There's no dependency. You don't need to install no JS or anything. So it kind of 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 LM providers. They get downloaded dynamically

• 15:12Speaker 02

  as you use them. So if you configure 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 kind of import 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 languages if it, if it makes sense. We honestly would have 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.

• 15:57Speaker 02

  Given like how deep we've gone into this world.

• 16:01Speaker 02

  So that's like on the packaging side. I've seen now Claude Code in their job posting. They actually mentioned specifically they're hiring someone that had experience in Bun executables. I think I saw AMP is also doing something similar now. So it just kind of makes sense. I think Bun really unlocks building something in JavaScript and TypeScript where you have these great libraries without the trade offs of it being like annoying to run.

• 16:27Speaker 02

  That's like the key packaging stuff. In terms of some of the LM tech, like you say in a compaction thing, we implement compaction probably in the same way as Claude Code. 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. 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.

• 17:02Speaker 01

  Okay, I think I just see a lot of tweets about, oh, you know, I'm running out of the context window, so I'm in trouble.

• 17:10Speaker 02

  Yeah.

• 17:10Speaker 01

  But yeah, 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

• 17:22Speaker 01

  rag on it, you know, rag on your own conversation history. I feel like, you know, based on what you say, people don't even get there. But like, I think people like the power users seem to all run into compaction issues. So I don't know.

• 17:37Speaker 02

  Yeah. So this is one of those areas where I'm kind of 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 the experience we have kind of 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 those.

• 18:12Speaker 02

  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 LM eventually gets like kind of lose the need to do it, given how fast things are moving. It doesn't mean every problem is automatically going to be solved, but an example of this is like the fast edit models that came out for a while where LM's 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 LM and have it output something and give it to that LM 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 Xperat.

• 18:54Speaker 02

  And their entire businesses were founded on providing that model. And then, you know, Sonnet four 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 kind of 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 kind of need to be really clever in knowing what optimization is not just going to go away in a couple of weeks.

• 19:28Speaker 01

  Simplicity works here.

• 19:31Speaker 02

  Yeah, simplicity. Yeah, exactly.

• 19:35Speaker 01

  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 either does?

• 19:42Speaker 02

  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.

• 19:52Speaker 02

  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 LM to do. I'm usually asking it 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, 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.

• 20:19Speaker 02

  So one of the 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, Open Code's like the best on his benchmark." I more care about, "I made a change to how our edit 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 and like the dimensions that matter two weeks down the road. But I just feel lost trying to improve this stuff, so at first we're trying to at least like develop

• 21:01Speaker 02

  some kind of benchmarks that look like what my day-to-day work actually looks like.

• 21:05Speaker 01

  Yeah, I mean, I think Aether is like up there. But also, I think this is curious, like since you're building public, probably this is public, but like what's an example of a thing that, you know, locally temporarily improved things, but actually you regretted it two weeks later?

• 21:20Speaker 02

  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 LM for the file you want to 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 search the old string, you find it, you replace it. Sometimes it kind of 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 use spaces. Um, so you can have a series of fallback strategies and the client team published all of their fallback strategies, which I then ported to Open Code. And then I was like, "That was easy. I just had Open Code port it."

• 22:02Speaker 02

  Let me go crazy. I went to Gemini's CLI and I was like, "Let me take all their strategies too." And 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 these totally messed up ways. And I should have known because 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 because I was using the tool.

• 22:31Speaker 01

  Nice. I mean, that that's how you find out, but like also I know you have like an issue of just Gemini code in general. So you like, you know, you're able to use like cloud codes, a 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.

• 22:47Speaker 02

  So we actually never, that was, I think the client team did that and they rolled it back. We, we have a PR for it. I decided not to merge it, given I expected that. Open code is gonna have a, gonna have a plugin system in the next couple of 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.

• 23:12Alessio Fanelli?

  Talking about, yeah, model usage, do you have any high level stats on people's usage? Like what models to 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.

• 23:39Speaker 02

  So we actually have been really conservative with telemetry. I usually, I generally don't care that much about telemetry. I'm not like some extremist when it comes to that stuff, but

• 23:49Speaker 02

  Open code 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. Open code 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. Is there, it's a really confusing question because I've been using the Claude Max plan for the whole time I've been working open code and I was like, I actually can't tell you, am I getting the value out of this? So I switched in the past two weeks to just using open router and just paying per use.

• 24:35Speaker 02

  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 want usage based.

• 24:52Speaker 02

  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 want to understand this a little bit more. Obviously, the economics of all this are a big question right now.

• 25:05Speaker 02

  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 tragedy, not like any long-term pricing thing that that can work, at least at the current, given the current state of things.

• 25:22Alessio Fanelli?

  The mystery continues.

• 25:25Alessio Fanelli?

  I'll be trying to figure that out.

• 25:28Alessio Fanelli?

  Anything you want to ask people?

• 25:32Alessio Fanelli?

  Feedback that you want on specific pieces of the product? Any contributions you want in open source?

• 25:38Speaker 02

  Yeah, it's fine. The ask I would actually have is stop submitting PRs without talking to us. We get some pretty awesome contributions, but, you know, this is a very, it's a very producty product where just adding every feature, the first version of every feature is like not going to result to a good place. So I have clearly the read me, like, please open an issue. Let's discuss it before you implement it. But I think we get these giant PRs oftentimes implemented with open code. So we're like trying to figure out how to like juggle all that. And we don't open source 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 open source is

• 26:20Speaker 02

  we don't think a product is good because it's open source. Usually a product is bad because it's open source, tends to be like designed by committee and like just a smash of like a bunch of different competing priorities. The reason we open source some of these things is because there is a part of it that has a long tail. So getting open code 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 is great at. They can kind of blast my old, figure those things out, make the LSPs work for all different languages, make the formatters work for all of the languages. The stuff that has like, there's a core and once you put the core, there's like 100 integrations to do. That's where open source really shines.

• 27:04Speaker 02

  And there's a lot of that in open code. That's why we made it open source. But core features, you know, it's, it's hard to really run it like a true open source project.

• 27:13Speaker 01

  And I mean, this is why the cloud code team didn't want to open source, right? They, they didn't want it to retain ownership of the roadmap and, and not piss people off by like rejecting their PRs that they work so hard on or, or may not. Yeah, I, you know, I, I think that's

• 27:28Speaker 01

  like, is there a world in which like, you know, you are basically a clean superset of Claude code.

• 27:36Speaker 01

  But you can use all the other models that is open source, 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?

• 27:48Speaker 02

  Yeah. So the reality is right now, if you look at how things like the, say the ecosystem, we're always going to be number two to Claude code. That's again, that's going to be the case. We're going to be, our shot right now is be good enough to be number two. And I think we're fast approaching that.

• 28:05Speaker 02

  What's gonna, what we're hoping?

• 28:06Speaker 01

  I actually think you're number two. I don't know.

• 28:09Speaker 02

  Yeah. I mean, yeah, I think, I think we're basically there. But I think the point there is I was actually pretty low bar. 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 open code. I think we do a lot of stuff better, but there's just a momentum they have.

• 28:28Speaker 02

  What would change things is if there's a day where either another LM lab or like, you know, an open source model drops that is competitive with Sonnet, maybe even better than Sonnet. On that day, open code is going to be the only way to do this kind of thing. Cause you know, Claude isn't going to do first class support for a different, a different provider. 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 four is really the only model that works really well inside this kind of product.

• 29:13Speaker 02

  And as long as that's the case, I think Claude code is going to be number one.

• 29:17Speaker 01

  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. Yeah, but I mean, that's cool. You know, like I was, I was gonna say like, the only other people are Gemini and OpenAI, who's, who are most likely to, you know, compete with Anthropic on Frontier Coding Model. But they both have their own CLI now, so they're, they're even not likely to, to jump on the open, open code tree. So like, I almost think you should work with like, magic.dev, like even Cursor is out, because Cursor hired Boris and Kat. So now presumably they're gonna do Cursor code, right? I don't, do you have a take on that, by the way?

• 29:58Speaker 02

  Uh, I'm, I'm really, it's fine, their, their CEO just messaged me a couple of days ago. But uh, like we on the terminal side.

• 30:05Speaker 01

  He's collecting, yeah.

• 30:08Speaker 02

  On the terminals, 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. And so we're pretty friendly with the Cursor team. My, I'm a little confused about that move. Mostly because they, they made, the, the team they acquired, they made them head of product and head of engineering, which is like a very large scope.

• 30:37Speaker 01

  Much bigger than just, like, just do Cursor CLI, you know?

• 30:40Speaker 02

  Yeah, exactly. So I'm like, are they gonna build a new product? Like, I'm not really, I don't fully understand that, to be honest.

• 30:48Speaker 01

  Okay, to, to engage a little, like, and obviously I, I don't want to get you in trouble. If there's a future version of this, where you, you like, OpenCode joins Cursor, like, you know, get that bag, right? But like, to me, like, a cloud code, like Boris and Kat basically made the number one most serious competitor to Cursor since Cursor.

• 31:09Speaker 02

  That's true, yeah.

• 31:10Speaker 01

  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?

• 31:22Speaker 02

  I mean, when I saw the acquisition, I was like, oh, this is actually more intense now because the cursor team is going to move faster than the Claude code team. I think that's my, that's my feeling, given they have to, there's more pressure on them. And they're smaller.

• 31:38Speaker 01

  Like to Anthropic, it's like a side project to

• 31:41Speaker 02

  Yeah, exactly.

• 31:42Speaker 01

  Existential.

• 31:43Speaker 02

  Yeah.

• 31:43Speaker 01

  Yeah.

• 31:44Speaker 02

  Yeah, exactly. So. Yeah, so we'll see. At this point. It's very early, so it's hard for me to, hard for me to say how this stuff shakes out, but 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 going to be a desktop app, there's going to be all that stuff as well.

• 32:05Speaker 02

  It comes down to whether it makes sense to have that as a separate app, or people still prefer inside the editor, like cursor is overwhelmingly. So that's probably what it ends up coming down to.

• 32:15Speaker 01

  Awesome. Any other commentary? I think I love the podcast. I'm going to plug tomorrow FM. So you're, you're, you're a very skilled yapper.

• 32:27Speaker 01

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

• 32:36Speaker 02

  Yeah, I think right now what it feels like is working open code has been really easy. 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 LM's 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 formater. There's like a hundred simple things like that to fix, and we're going to continue to fix those. And we think if you add all those up, it results in a really good product. So in the product realm.

• 33:21Speaker 02

  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 just see a shift to a very boring, straightforward, who can package the right product. And that's kind of where the battle is going.

• 33:58Speaker 01

  Yeah. Yeah. Um, do you have plans to monetize somehow that I don't know?

• 34:06Speaker 02

  Yeah. But given like, 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. Open code itself will never be monetized. The day you monetize your open source project is a day it starts to die. There's kind of a natural fit for open code in terms of monetization. When we talk to bigger enterprisey boring companies that uh want to 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 want to have oversight on that.

• 34:49Speaker 02

  But 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?

• 35:08Speaker 01

  Yeah, amazing. Well, congrats on your success. Like I would not have, I think like someone would should have come along and done it.

• 35:17Speaker 01

  Yeah, I'm sorry. I apologize for getting you mixed up with the other open code.

• 35:22Speaker 01

  Like, I think some, I think like, this does need to exist. We need to sort of, to have like an open sort of standard terminal agents. I think there's a lot, there's a lot here. I think you're like, almost like weirdly like the right guy to do this. So I'm glad that you decided to do it, you know, because like,

• 35:41Speaker 01

  there's, there's a lot of people who, who would, you know, turn this as like the next Y C project and then it would just die after like a year or two, you know?

• 35:49Speaker 02

  Yeah.

• 35:49Speaker 01

  So.

• 35:50Speaker 02

  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 profitable company, we can kind of just focus on, I'm 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 where it's going.

• 36:17Speaker 01

  Yeah, I'm, I'm pretty big fan of like the whole building public thing as well, but like, you know, you, you got, you got a way with, with, uh, with communicating. Uh, okay, cool. Any shout outs, uh, anything call section, anything like that?

• 36:29Speaker 02

  Not really. Uh, I think, I think comes to mind.

• 36:32Speaker 01

  Just use open code.

• 36:34Speaker 02

  Yeah, open code dot A I. Go, go check it out.

• 36:36Speaker 01

  And talk before, talk before you send in a P R.

• 36:40Speaker 02

  Yes. Open it to you before the P R. Yeah.

• 36:43Speaker 01

  If we, if we do one thing right, we'll get that message out. So yeah, thanks so much, Stacks.

• 36:48Speaker 02

  Yeah, appreciate it. Good chatting.