Cline: the open source coding agent that doesn't cut costs

Saoud Rizwan and Pash from Cline joined us to talk about why fast apply models got bitter lesson’d, how they pioneered the plan + act paradigm for coding, and why non-technical people use IDEs to do marketing and generate slides. Full writeup: https://www.latent.space/p/cline X: https://x.com/latentspacepod Full Video Episode Timestamps 00:00 - Introductions 01:35 - Plan and Act Paradigm 05:37 - Model Evaluation and Early Development of Cline 08:14 - Use Cases of Cline Beyond Coding 09:09 - Why Cline is a VS Code Extension and Not a Fork 12:07 - Economic Value of Programming Agents 16:07 - Early Adoption for MCPs 19:35 - Local vs Remote MCP Servers 22:10 - Anthropic’s Role in MCP Registry 22:49 - Most Popular MCPs and Their Use Cases 25:26 - Challenges and Future of MCP Monetization 27:32 - Security and Trust Issues with MCPs 28:56 - Alternative History Without MCP 29:43 - Market Positioning of Coding Agents and IDE Integration Matrix 32:57 - Visibility and Autonomy in Coding Agents 35:21 - Evolving Definition of Complexity in Programming Tasks 38:16 - Forks of Cline and Open Source Regrets 40:07 - Simplicity vs Complexity in Agent Design 46:33 - How Fast Apply Got Bitter Lesson’d 49:12 - Cline’s Business Model and Bring-Your-Own-API-Key Approach 54:18 - Integration with OpenRouter and Enterprise Infrastructure 55:32 - Impact of Declining Model Costs 57:48 - Background Agents and Multi-Agent Systems 1:00:42 - Vision and Multi-Modalities 1:01:07 - State of Context Engineering 1:07:37 - Memory Systems in Coding Agents 1:10:14 - Standardizing Rules Files Across Agent Tools 1:11:16 - Cline’s Personality and Anthropomorphization 1:12:55 - Hiring at Cline and Team Culture This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.latent.space/subscribe https://www.latent.space/subscribe?utm_medium=podcast&utm_campaign=CTA_2

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

• 0:05Alessio Fanelli?

  Hey everyone, welcome to the Lead in Space Podcast. This is Salacio, partner and CTO at Decibel, and I'm joined by my co-host Wix, founder of Small AI.

• 0:12Speaker 01

  Welcome, welcome. And today in the studio with a nice two guests from Kline, Pash and Saud.

• 0:19Speaker 02

  That's right.

• 0:20Speaker 01

  Yes.

• 0:21Speaker 03

  You nailed it. Let's go.

• 0:23Speaker 01

  I think that Kline has a decent fanbase, but not everyone has heard of it. Maybe we should just get like an upfront, like what is Kline maybe from you and then like you can modify that as well.

• 0:35Speaker 02

  Yeah, Kline's an open source coding agent. It's a VS Code extension right now, but it's coming to JetBrains and NeoVim and CLI. You give Kline a task and it just goes off and does it. It can take over your terminal, your editor, your browser, connect to all sorts of MCP services and essentially take over your entire developer workflow. And it becomes this point of contact for you to get your entire job done essentially.

• 1:01Speaker 01

  Beautiful. Pash, what would you modify? Or what's another way to look at Kline that you think is also valuable?

• 1:08Speaker 03

  Yeah, I think Kline is the kind of infrastructure layer for agents, for all open source agents, people building on top of this like agentic infrastructure. Kline is a fully modular system. That's the way we envision it and we're trying to make it more modularized so that you can build any agent on top of it.

• 1:28Speaker 01

  Yep.

• 1:29Speaker 03

  So with the CLI and with the SDK that we're rolling out, you're going to be able to build fully agentic systems for anything, not just coding.

• 1:36Speaker 01

  Oh, okay. That is a different perspective on Cline than I had. So, okay, let's, let's talk about coding first and then we'll talk about the broader stuff. You also are similar to Aider, I don't know who comes first, in that you use the plan and act paradigm quite a bit. I'm not sure how well known this is, like to me, I'm relatively up to speed on it. But again, like maybe you guys want to explain like why different models for different things?

• 2:03Speaker 02

  Yeah, I'm going to take the cred for coming up with plan, act first. And then Cline was the first to sort of come up with this concept of having two modes for the developer to engage with. So just in like talking to our users. And seeing how they use Klein, where it was really only an input field. We found a lot of them starting off, working with the agent, coming up with a markdown file where they asked the agent to put together some kind of architecture or plan for the work that they want the agent to go on to do. And so we would find that people just came up with this workflow for themselves, just organically. And so we thought about how we might translate that into the product. So it's a little bit more intuitive for new users who don't have to kind of pick up that pattern for themselves

• 2:46Speaker 02

  and can kind of direct and put in guardrails for the agent to adhere to these different modes whenever the user switches between them. So for example, in plan mode, the agent's directed to be more exploratory, read more files, get sort of understanding, fill up its context with any sort of relevant information to come up with a plan of attack for whatever the task is the user wants to accomplish. And then when they switch to act mode, that's when the agent gets this directive to look at the plan and start executing on it, running commands, editing files. And it just makes working with agents a little bit easier, especially with something like Klein, where a lot of the times people's engagement with it is mostly in the plan mode, where there's a lot of back and forth.

• 3:30Speaker 02

  There's a lot of extracting context from the developer, you know, asking questions. What do you want the theme to look like? What pages do you want on the website? Just trying to extract any sort of information that the user might not have put into their initial prompt. Once the user feels like, okay, I'm ready to let the agent go off and work on this. They switch to act mode, check auto approve, and just kick their feet up and, you know, get coffee or whatever and let the agent get the job done. So yeah, most of the engagement happens in the plan mode. And then act mode, they kind of just have a peripheral vision into what's going on, mostly to course correct whenever it goes in the wrong direction. But for the most part, they can just rely on the model to get it done.

• 4:15Alessio Fanelli?

  And was this the first shape of the product? Or did you get to the plan act iteratively? And maybe was this the first idea of the company itself? Or were you exploring other?

• 4:26Speaker 02

  It was a lot of, especially in the early days of the client, it was a lot of experimenting and talking to our users and seeing what kind of workflows came up that they found that were useful for them and translating them into the product. So plan and act was really a byproduct of just talking to people in our Discord, just asking them what would be useful to them, what kind of prompt shortcuts we could add into the UI. I mean, that's really all plan and act mode is. It's essentially a shortcut for the user to save them the trouble of having to type out, you know, I want you to ask me questions and put together a plan. The way that you might have to, and you know, some of the other tools, you have to like be explicit about, I want you to come up with a plan before, you know, acting on it or editing files.

• 5:09Speaker 02

  Incorporating that into the UI just saves the user the trouble of having to type that out themselves.

• 5:14Alessio Fanelli?

  But you started right away as a coding product? And then this was part of, okay, how do we get better UX, basically?

• 5:21Speaker 02

  Exactly.

• 5:22Alessio Fanelli?

  Yeah. What was the model evaluation at the time? So I'm sure part of like the, we need plan and act is like, maybe the models are not able to do it end to end. When you started working on that paradigm, where were the model limitations? What were the best models? And then how has that evolved over time?

• 5:37Speaker 02

  Yeah, when I first started working on client, this was, I think, 10 days after Cloud 3.5 Sonic came out. I was reading Anthropic's Model Card Addendum, and there was this section about agentic coding and how it was so much better at this step-by-step accomplishing tasks. And they talked about running this internal test where they let the model run in this loop where it could call tools. And it was obvious to me that, okay, they have some version, they have some application internally that's really different from how the, you know, the other things at the time were, things like Copilot and Cursor and Aider. They didn't do this for like step-by-step reasoning and accomplishing tasks. They were more suited for the Q and A and, and one-shot prompting paradigm.

• 6:22Speaker 02

  At the time, I think it was. Uh, June 2024 Anthropic was doing a Build with Claude hackathon. So I thought, okay, this is a really cool new capability that none of the models have really been capable of doing before. And I think being able to create something from the ground up and take advantage of kind of like the nuances of how much the model's improved in that point in time. So for example, Claude 3.5 was also really good at this test called Needle in a Haystack, where if it has a lot of context in its context window, for example, you know, 90% of its 200K context window is filled up. It's really good at picking out granular details in that context, whereas before Claude 3.5,

• 7:04Speaker 02

  it really paid a lot more attention to whatever was at the beginning or the end of the context. So just taking advantage of kind of the nuances of it being better at understanding longer context and it being better at task by task, uh, sorry, step by step accomplishing tasks and building a product from the ground up, just kind of let me create something that just felt a little bit different than anything else that was around at the time. And some of the core principles in building the first version of the product was just keep it really simple. Just let the developer feel like they can kind of use it however they want. So make it as general as possible and kind of let them come up with whatever workflows, you know, works well for them. People use it for all sorts of things outside of coding.

• 7:45Speaker 02

  Our product marketing guy, Nick Baumann, he uses it to connect to, you know, a Reddit MCP server, scrape content connected to an ex MCP server and post tweets essentially. Even though it's a VS Code extension and a coding agent, MCP kind of lets it function as this everything agent where it can connect to, you know, whatever services and things like that. And that's really a side effect of having very general prompts just in the product and not sort of limiting it to just coding tasks.

• 8:14Speaker 03

  I was at a conference in Amsterdam and I built my whole presentation, my whole slide deck using this library. It's like a JavaScript library called Slide Dev. And I just asked Klein like, hey, like here's like my style guidelines. I wrote like a big Klein rules document explaining like how I want to style the presentation in Slide Dev. I told Klein like the agenda, I kind of recorded using this other app called Limitless, like transcribed my voice in a text about like my thoughts, just like stream of consciousness about what I was going to talk about for this conference for my talk. And Klein just went in and built the whole, the whole deck for me. So, you know, client really can do anything.

• 8:54Speaker 01

  In JavaScript.

• 8:55Speaker 03

  In JavaScript, yeah.

• 8:56Speaker 01

  Yeah, so it's kind of a coding use case.

• 8:59Speaker 03

  It was kind of a coding use case, but then making a presentation out of it. But it can also like run scripts, like do like data analysis for you and then put that into a deck.

• 9:07Speaker 01

  Okay.

• 9:07Speaker 03

  You know, kind of combine things.

• 9:09Speaker 02

  And being a VS code extension is is kind of this like, it gives you these interesting capabilities where you have access to the user's OS, you have access to the user's terminal, and you know, you can read and edit files. Being an extension, it reduces a lot of the onboarding friction for a lot of developers where they don't have to, you know, install a whole new application or have to, you know, go through whatever internal, jumping through hoops to try to get something approved to use within their organizations. So the marketplace gave us a ton of really great distribution and it's sort of like the perfect conduit for something that needs access to files on your desktop or to be able to run things on your terminal, to be able to edit code

• 9:50Speaker 02

  and to take advantage of VS Code's really nice UI and show you like diff views, for example, before and after it makes changes to to files.

• 9:59Speaker 01

  Weren't you tempted to fork VS Code though? I mean, you know, you could be sitting on $3 billion right now.

• 10:05Speaker 02

  Well, no, I actually like pity anybody that has to fork VS Code because Microsoft makes it like notoriously difficult to maintain these forks. So a lot of resources and efforts go into just maintaining, keeping your fork up to date with all the updates that VS Code is making.

• 10:23Speaker 01

  I see. Is that because they have a private repo and they need to just sync it? There's no like.

• 10:28Speaker 02

  Exactly, exactly.

• 10:29Speaker 01

  And there's one of those kinds of open source projects.

• 10:31Speaker 02

  Right, and VS Code's moving so quickly where I'm sure they run into all sorts of issues, not just in, you know, things like merge conflicts, but also in the backend. They're always making improvements and changes to, for example, their VS marketplace API and to have to like reverse engineer that and figure out kind of how to make sure that your users don't run into issues using things like that is, I'm sure, like a huge headache for anybody that has to maintain a VS Code fork. And it also, you know, being an extension also gives us a lot more distribution. It's not that you have to use us or somebody else. You can use client in. Cursor or in WinSurf or in VS Code. And I think Klein complements all these things really well in that, you know, we get the opportunity to kind of figure out and, and work really closely with our users to figure out what the best agentic experience is.

• 11:15Speaker 02

  Whereas, you know, Cursor and WinSurf and Copilot have to think about the entire developer experience, the inline code edits, the Q and A, sort of all the other bells and whistles that go into writing code. We get to just focus on what I think is the future programming, which is this agentic paradigm. And as the models get better, people are going to find themselves using natural language, working with an agent more and more, and less being in the weeds and editing code and tab autocomplete.

• 11:43Speaker 03

  Yeah, just like, imagine how many like resources you would have to spend maintaining a fork of VS Code, where we can just kind of stay focused on the core agentic loop, optimizing for different model families as they come out, supporting them. You know, there's so much work that goes into all this that maintaining a fork on the side would just be such a massive distraction for us. But I don't think it's really worth it.

• 12:07Alessio Fanelli?

  I feel like when you talk, I hear this distinction between we want to be the best thing for the future programming. And then also, this is also great for non-programming. Is this something that has been risen for you, where like you're seeing more and more people use the MCP servers, especially to do less technical thing, and that's an interesting area? Or do you feel like programming is still like the highest kind of like economic value thing to be selling today? I'm curious if you can share more.

• 12:34Speaker 02

  In terms of economic value, programming is definitely the highest cost to benefit for language models right now. And I think, you know, we're seeing a lot of, you know, model labs recognize that. OpenAI, Anthropic are taking coding a lot more seriously than I think they did a year ago. What we've seen is while yes, like the MCP ecosystem is growing, and a lot of people are using it for things outside of programming, the majority of use case is mostly developer work. There was an article on Hacker News a couple of weeks ago about how a developer deployed a buggy CloudFlare worker and used a Sentry MCP server to pull a stack trace.

• 13:12Speaker 02

  And ask Klein to sort of fix the bug using the stack trace information, connect to a GitHub MCP server to close the issue and deploy the fix to CloudFlare, all right within Klein using natural language, never having to leave VS Code. And it sort of interacts with all these services that otherwise the developer would have had to have the cognitive overload of having to, you know, figure out for himself and leave his developer environment to essentially do what the agent could have done just on the background, just using natural language. So I think that's kind of like where things are headed is the application layer being connected to sort of all the different services that you might have had to interact with before manually and it being this sort of single point of contact for you to interact with using natural language.

• 13:56Speaker 02

  And you being less and less in the code and more and more a high level understanding of what the agent's doing and being able to course correct. I think that's another part of what's important to us and what's allowed us to kind of cut through the noise in this like incredibly noisy spaces. I think a lot of, a lot of people have really grand ideas for, you know, where things are heading, but we've been really maniacal about what's useful to people today. And a large part of that is understanding sort of the limitations of these models, what they're not so good at, and giving enough insight into those sorts of things to the end developers so that they know how to course correct, they know how to give feedback when things don't go right. So for example, Klein is really

• 14:38Speaker 02

  good about, you know, giving you a lot of insight into the prompts going into the model, into when there's an error, why the error happened, into the tools that the model's calling. We try to give as much insight into what exactly the model is doing at each step in accomplishing a task. So when things don't go wrong or it starts to go off in the wrong direction, you can, you know, give it feedback and course correct. I think the course correcting part is so incredibly important in, in getting work done. I think much more quickly than if you were to kind of give a sort of a background agent work, you come back a couple of hours later and it's just like totally wrong and it, it didn't do anything that you expected it to do and you kind of have to retry a couple of times before it gets it right.

• 15:17Alessio Fanelli?

  I think the Sentry example is great because I feel in a way the MCPs are like cannibalizing the products themselves. Like, I started using the Sentry MCP and then Sentry Release Sierra, which is like their issue resolution agent, and it was free at the start. So, I turned it on in Sentry, I was using it, it's great. And then they started charging money for it, and I'm like, I can use the MCP for free, put the data in my coding agent, and it's gonna fix the issue for free and send it back. I'm curious to see, especially in coding, where you can kind of have this closed loop, where, okay, are these MCPs gonna become the paid AI offering, so that then you can plug it in, and is Client gonna have kind of like a MCP subscription, where like, you're kind of fractionalizing all these

• 16:02Alessio Fanelli?

  costs? To me, today feels like it doesn't make a lot of sense, the way they're structured.

• 16:07Speaker 03

  Well, yeah, we were like, very early on, we like, we've been bullish on MCP from the very beginning, and-

• 16:14Speaker 02

  Were you a launch partner? A financial server MCP, I think?

• 16:17Alessio Fanelli?

  Sorry to interrupt.

• 16:18Speaker 03

  Yeah, no worries.

• 16:18Speaker 02

  I, I think when Anthropic first launched MCP, and they made this big announcement about, you know, this new protocol that they've been working on and open sourcing it, nobody really understood what it meant. And it took me some time really digging into their documentation about how it works and why this is important. I think they, they kind of took this bet on the open source community contributing to an ecosystem in order for it to really take off. And so I wanted to try to help with that for as much as possible. So for a long time, most of Client's system prompt was, how does MCP work? Because it was so new at the time that, you know, the models didn't know anything about it. And how to make MCP servers. So like, if the developer wanted to, you know, make something like that, he'd be really good at it. And I'd like to think that, you know, Client had something

• 17:00Speaker 02

  to do with how much the MCP ecosystem has grown since then. And just getting developers more insight and sort of awareness about how it works under the hood, which I think is incredibly important in using it, let alone just developing these things. And so, yeah, when, when we launched MCP in Client, I remember our Discord users just trying to wrap their heads around it. And in seeing clients build MCP servers from the ground up, they're like, okay, they started to connect the dots. This is how it works under the hood. This is why it's useful. This is how agents connect to these tools and services and these APIs. And sort of saved me a lot of the trouble of having to do this sort of stuff myself.

• 17:37Speaker 03

  Those were like the early days of MCP. And people were still trying to wrap their heads around it. And there's like a big problem with discoverability. So back in like February, we launched the MCP Marketplace where you could actually go through and have like this one click install process where Klein would actually go through looking at a readme. And that's like linked to a GitHub. Install the whole MCP server from scratch and just get it running immediately. And that was like, I think around that time, that's when MCP really started taking off with like the launch of the marketplace. Where people were able to discover MCPs, contribute to the MCP marketplace. We've listed over like 150 MCP servers since then.

• 18:19Speaker 03

  And like the top MCPs in our marketplace have over, you know, hundreds of thousands of downloads. People using them. And, you know, there's like really notable examples where you mentioned like, how are people like, it's like kind of eating existing products. But at the same time, we're starting to see like this ecosystem evolve where people are monetizing MCPs. Like a notable example of this is 21st Dev Magic MCP Server where it injects some taste into this coding agent into the LLM where they have this library of beautiful components. And they just inject relevant examples so that Klein can go in and implement beautiful UIs. And the way they monetize that was like a standard API key.

• 19:03Speaker 03

  So we're starting to see developers really like take MCPs, build them in, have distribution platforms like the MCP Marketplace in Klein. And monetize their whole business around that. So now it's like, almost like you're selling tools to agents, which is a really interesting topic.

• 19:22Alessio Fanelli?

  And you can do that because you're in VS Code, so you have the terminal. So you can do Npx, run the different servers. Have you thought about doing remote MCP hosting? Or you feel like that's not something you should take over?

• 19:35Speaker 03

  Yeah, we haven't really hosted any ourselves. We think that's, we were looking into it. I think it's, it's all very nascent right now, the, the remote MCPs. But we're definitely interested in, in supporting remote MCPs and, and listing them on our marketplace.

• 19:50Speaker 02

  And another part, I think. What sort of local MCP servers and remote MCPs is most of the remote MCPs are only useful to connect to different APIs. But that's only a, you know, that's only a small use case for MCPs. A lot of MCPs help you connect to different applications on your computer. For example, there's like a Unity MCP server that helps you create, you know, 3D objects with and right from within VS Code. There's an Ableton MCP server so you can like make songs using something like Cline or whatever else uses MCPs. We won't see a world where these MCP servers are only hosted remotely. There will always be some mix of local MCP servers and remote MCP servers. I think the remote MCP servers do make the installation process a little bit easier

• 20:35Speaker 02

  with, you know, with something like an OAuth flow and just authenticating a little bit not as painful as having to manage API keys yourself. But for the most part, I think the MCP's ecosystem is really in its earlier days. We're still trying to figure out this good balance of security, but also convenience for the end developer so that it's not a pain to have to set these things up. And I think we're still in this very much experimental phase about how useful it is to people. And I think now that it is seeing this level of market fit and people are coming out with, you know, these sorts of like articles and workflows about how it's totally changing their jobs. I think there's going to be a lot more of a resources and efforts that go into the ecosystem and just building out the protocol, which I think there's a lot on Anthropic's roadmap.

• 21:17Speaker 02

  And I, I think the community in general just has a lot of ideas and our marketplace in particular has, has given us insights into some ways that we could improve it, things that, you know, developers have asked for from it that where we're kind of thinking about how do we, you know, what is the MSP marketplace of the future look like? And for us, that's, it's, it's going to be a combination of, you know, well, there's, a lot of our users are very security conscious and there's a lot of ways that MCP, you know, servers can be pretty dangerous to use if you don't trust the end developer of these things. And so we're trying to figure out, you know, what is a, a future look like where you can, where you have some level of confidence in the MCP servers you're installing. I think right now it's just, it's too early and there's a lot of trusting the community

• 22:02Speaker 02

  that I don't think a lot of, you know, enterprise developers or organizations are quite willing to do yet. So that's something that's top of mind for us.

• 22:10Speaker 01

  There's an interesting tension between the Anthropic and the community here. You basically kind of have a MCP registry internally, right? Honestly, I think you should expose it. I was looking for it on your website and you don't have it. Like, the only way to access it is to install Klein. But there's others like Smithery and all the other guys, right? But then Anthropic has also said they'll launch a model registry at some point, or MCP registry at some point.

• 22:33Speaker 02

  Some point.

• 22:34Speaker 01

  If Anthropic launched the official one, would they just win by default, right? Because, like, would you just use them?

• 22:40Speaker 02

  I think so. I think the entire ecosystem will just converge around whatever they do. They just have such good distribution and they're...

• 22:46Speaker 01

  They came up with it.

• 22:48Speaker 02

  Yeah, exactly.

• 22:49Speaker 01

  Cool. And then I wanted to, I noticed that you had some, like, really downloaded MCPs. I was going by most installs. I'm just gonna read it off. You can stop me anytime to comment on them. So top is file system MCP. Makes sense. Browser tools from Agent Desk AI. I don't know what that is. Sequential thinking, that one came out with the original MCP release. Context 7? I don't know that one.

• 23:12Speaker 03

  That's a big one.

• 23:13Speaker 01

  What is that?

• 23:14Speaker 03

  Context 7 kind of helps you pull in documentation from anywhere. And it has like this big index of all of the popular libraries and documentation for them.

• 23:25Speaker 01

  Okay.

• 23:25Speaker 03

  And your agent can kind of submit like a natural language query and search for any documentation.

• 23:32Speaker 01

  It just says everyone's docs.

• 23:32Speaker 03

  Yes.

• 23:33Speaker 01

  And apparently Upstach did that, which is also unusual because Upstach is just normally Redis. Git tools, that one came out originally. Fetch. Browser use. Browser use, I imagine, competes with browser tools, right? I guess. And then below that, playwright.

• 23:47Speaker 03

  Competition.

• 23:48Speaker 01

  Right? So there's a lot of, like, let's automate the browser and let's do stuff. I assume for debugging. Firecrawl, Popriteer, Figma. Here's one for you, perplexity research. Is that yours?

• 23:59Speaker 03

  Well, yeah, I forked that one and listed it, but yeah, that's, you know, that's another very popular one where you can research anything.

• 24:06Speaker 01

  So people wanna, people wanna emulate, automate the browser. I'm just trying to learn lessons from what people are doing, right? Are they gonna automate the browser? They wanna access Git and file system. They wanna access docs and search. Anything else that you think is notable?

• 24:21Speaker 03

  There's all kinds of stuff where it's like, you know, there's like the Slack MCP where you can send, you know, that's actually one workflow that I have set up where you can like automate repetitive tasks in client. So I tell client like, okay, pull down this PR, use the GH command line tool, which I already have installed, using the terminal to pull the PR, get the description of the PR, the discussion on it, and get the full diff as like a, like a single command, non-interactive command, pull in all that context, read the files around the diff, review it, ask a question like, hey, do you want me to approve this or not with this comment? And if I say yes, approve it and then send a message in Slack to my team using the Slack MCP, for example.

• 25:02Speaker 01

  Oh, use it to write?

• 25:04Speaker 03

  Yes.

• 25:04Speaker 01

  I would only use it to read.

• 25:06Speaker 03

  Yeah, I know. It's, you know, people like, I love it, you know? I love being able to just like send an automated message in Slack or whatever. You can also like set it up, like set up your workflow however you want where it's like, okay, client, please ask me before doing anything, you know? Just make sure you're asking me to like approve before you send a message or something like that.

• 25:26Speaker 01

  Yeah. Okay. Just, just to close out MCP side, anything else interesting going on in MCP universe that we should talk about? MCP OFF was recently ratified.

• 25:35Speaker 03

  I think monetization is a big question right now for the MCP ecosystem. We've been talking a lot with Stripe. They're very bullish on MCP and they're trying to figure out like a monetization layer for it. But it's all so early that it's kind of hard to really even envision where it's going to go.

• 25:55Speaker 01

  Let me just put up a straw man and then you can tell me what's wrong with it. Like, how is this different from API monetization, right? Like, you sign up here, make an account, I give you a token back, and then you use token, I charge you against your usage.

• 26:07Speaker 03

  No, like, like, I think that's how it is right now. That's how like the, the magic MCP, the 24step guys did it. But we're kind of envisioning a world where agents can pay themselves for these MCP tools that they're using and pay for each tool call. And you can't deal with like a million different API keys from different products and like signing up for all this. There needs to be like a unified kind of payment layer. Some people talk about like stable coins, how like those are coming out now that agents can natively use those. Stripe is, they're considering this like abstraction around the MCP protocol for payments. But like I said, it's kind of hard to really tell where it's gonna, how that's going to manifest.

• 26:50Speaker 01

  I would say like we I I covered when they launched their agent toolkit um last year, a few months ago. It seemed like that was enough, like it you didn't seem to need stable coins, except for the fact that they take like thirty cents every transaction.

• 27:03Speaker 03

  Yeah.

• 27:05Alessio Fanelli?

  Have you seen people use the X four O two thing by Coinbase to make it's basically like the you can do a HTTP request that includes payment in it?

• 27:14Speaker 01

  What?

• 27:15Speaker 03

  Yeah, yeah, it's a it's been around forever, the four O two error, that's like payment not accepted or something, right? So yeah, we've seen some people talking about that, like more like natively building that in. But yeah, nothing, yeah, no one's really doing that right now.

• 27:32Speaker 01

  Anything you're seeing on like are people like in making MCP startups that are interesting?

• 27:39Alessio Fanelli?

  Mostly around rehosting local ones and do remote and then basically do instead of setting up ten MCPs, you have like a canonical URL that you put in all of your tools and then expose all the tools from all the servers.

• 27:51Speaker 01

  Yeah.

• 27:52Alessio Fanelli?

  There's like MCP that run some of these tools.

• 27:54Speaker 01

  Yeah.

• 27:55Alessio Fanelli?

  But I think it kind of has the same issues of how do you incentivize people to make better MCPs? You know?

• 28:01Speaker 01

  And will it be mostly first party or will it be third party?

• 28:04Alessio Fanelli?

  Yeah.

• 28:04Speaker 01

  Like your perplexity MCP was the fourth one. What was wrong with the perplexity one?

• 28:08Speaker 03

  With MCPs and installing them locally on your device, there's always a massive risk associated with that. And when an MCP is created by someone that we have no idea who they are, at any point, they might, you know, update the GitHub to like introduce some kind of malicious stuff. So even if you like verified it when you were listing it.

• 28:26Speaker 01

  Okay.

• 28:27Speaker 03

  You might change it. So I ended up having to fork a few of those to make sure that we lock that version down.

• 28:33Speaker 01

  Oh, okay. So this is just like you're just forking it so that you you don't change it.

• 28:38Speaker 03

  Yeah.

• 28:38Speaker 01

  Without without knowing. It's interesting. These are all the problems of a registry, right?

• 28:42Speaker 03

  Right.

• 28:42Speaker 01

  That you need to ensure security and all that. Cool. I'm happy to move on. I I would say like the last thing that's kind of curious is like, if Anthropic hasn't hadn't come along and made MCP, what would have happened? What's the alternative history, right? Like, would you have come with MCP?

• 28:56Speaker 02

  So we saw some of our competitors who have kind of working on their own version of plug and play tools into these agents. They kind of had to natively create these tools and integrations themselves.

• 29:07Speaker 01

  Yeah.

• 29:08Speaker 02

  Directly into their product. And so I think anybody in the space would have had to just do the laborious work of having to recreate these tools and integrations for. So I think Anthroby just saved us all a lot of trouble and tapped into the power of open source and community driven development and allowed individual contributors to make an MCP for anything people could think of and really take advantage of people's imagination in a way that I think is necessary right now for us to really tap into full potential of this sort of thing. So.

• 29:39Alessio Fanelli?

  We've had, I think, a dozen episodes with different coding products.

• 29:43Speaker 01

  Yeah. And this, by the way, this, this episode came directly after he tweeted about the Claude episode, where they were sitting right where you're sitting.

• 29:50Alessio Fanelli?

  Thanks for sharing it. I'm a rag, yeah. Can you give people maybe the matrix of the market of, you know, you have like fully agentic no IDE, you have agentic plus IDE, which is kind of yours, you have IDE with some co-piloting. How should people think about the different tools and what you guys are best at, or maybe what you don't think you're best at?

• 30:11Speaker 02

  I think what we're best at and like our ethos since the beginning is just meet the developers where they're at today. I think there is a little bit of insight and handholding these models need right now. And the IDE is sort of the perfect conduit for something like that. You can see the edits it's making, you can see the commands that it's running, you can see the tools that it's calling. It gives you the perfect UX for you to have the level of insight and control and be able to course correct the way that you need to, to work with limitations of these models today. But I think it's pretty obvious that as the models get better, you'll be doing less and less than that, less and less of that and more and more of the initial planning and prompting and sort of have the trust and confidence that, you know, the model will be able to get the job done pretty

• 30:53Speaker 02

  much exactly how you want it to. I think there will always be a little bit of a gap in that these models will never be able to read our minds. So we'll, there will have to be a little bit of, you know, making sure that you give it the most comprehensive and sort of like all the details of what you want from it. So if you're a lazy prompter, you can expect a ton of friction and back and forth before you really get what you want. But I think we're, we're all learning for ourselves as we work with these things, kind of the right way to prompt these things and to be explicit about what it is that we want and kind of how they hallucinate. The gaps that they might need to fill to to get to the end results and how we might want to avoid something like that. So what's interesting about Claude Code is there isn't really a lot of insight into what the agent's doing. It kind of gives you this like checklist

• 31:38Speaker 02

  of what it's doing holistically at a high level. I don't think that really would have worked well if the models weren't good enough to actually produce work that people were generally happy with. We're kind of there and I think the space has to catch up to, okay, maybe people don't need as much insight into these sorts of things anymore and they they are okay with letting an agent kind of get the job done and really all you need to see is sort of the end result and tweak it a little bit before it's it's really perfect. And I think there is going to be different tools for different jobs. I think something like totally autonomous agent that you don't have a lot of insight into is great for maybe scaffolding new projects, but for kind of the serious, more complex sorts of things

• 32:21Speaker 02

  where, you know, you do need a certain level of insight or you do need to kind of have like more engagement, you might want to use something that does give you some more insight. So I think I think these sorts of tools complement each other. So for example, writing tests or spinning off 10 agents to try to fix the same bug, you know, might be useful for a tool that doesn't require too much engagement from you, whereas something that requires a little bit more creativity or imagination or extracting context from your brain requires a little bit more of insight into what the model's doing and a back and forth that I think client is a little better suited for.

• 32:57Speaker 03

  Visibility into what the agent is doing, that's like one axis. And then another is autonomy, like how how automated it is. And we have a category of companies that are focusing more on the use case of people that don't even want to look at code, which is like, you know, the lovable's, the replits, where it's like you go in, you build an app, you might not even be technical and you're just happy with the result. And then you have kind of stuff that's kind of like a hybrid where it's, you know, for engineers, it's built for engineers, but you don't really have a lot of visibility into what's going on in a hood. This is like for like the vibe coders where they're, you know, fully, you know, letting letting the AI take the wheel and building stuff very rapidly. And lots

• 33:41Speaker 03

  of open source fans and, you know, people that are hobbyists enjoy coding in this in this manner. It is really fun. And then you get to like serious engineering teams where they can't really give everything over to the AI, at least not yet. And they need to have high visibility into what's going on every step of the way and make sure that they actually understand what's happening with their code. You're kind of handing off your production code base to this non deterministic system and then hoping that you catch it in review if anything goes wrong. Whereas personally, the way I use AI, the way I use Klein is I like to be there every step of the way and kind of guide it in the right direction.

• 34:24Speaker 03

  So I know every step of the way, like as every file is being edited, I approve every single thing and make sure that things are going in the right direction. I have a good understanding as things are being developed where it's going. So like this kind of hybrid workflow really works for me personally. But you know, sometimes if I want to go full YOLO mode, I go ahead and just auto approve everything and just step out for a cup of coffee and then come back and you know, review the work.

• 34:50Alessio Fanelli?

  My issue with this as an engineer myself is that we all want to believe that we work on the complex things. How have you guys seen the line of complex change over time? I mean, if we sat down, I mean, this discussion 12 months ago, complex was like much easier than today for the models. Do you feel like that's evolving quickly enough that like, you know, in 18 months, it's like you should probably just do follow GENTIC for like 75% of work, 80% of work? Or do you feel like it's not moving as quickly as you thought?

• 35:21Speaker 02

  I think, I think what was complex a couple of years ago is totally different to what is complex today. Now, I think what we need to be more intentional about are the architectural decisions we make really early on and how the model kind of builds on top of that. If you have kind of a clear direction of where things are headed and what you want, you kind of have a good idea to what, how you might want to like lay the foundation for the code base that you're producing. And I think what we might have considered complex a few years ago. Algorithmic challenges, that's pretty trivial for models today and stuff that we don't really necessarily have to think too much about anymore. We kind of give it a certain expectation or unit test about what we want and it kind of goes off and puts together the perfect solution.

• 36:04Speaker 02

  So I think there is a lot more thought that has to go into tasteful architectural decisions. That really comes down to you having experience with what works and what doesn't work. Having a clear idea for the direction of where you want to take the project and your vision for the code base. Those are all decisions that I think is hard to rely on a model for because of its limited context. And it's inability to kind of see your vision for things and really have a good understanding of what you're trying to accomplish without you putting together a massive prompt of everything that you want from it. I think what we spent most of our time working on a couple of years ago has totally changed and I think for the better. I think architectural decisions are a lot more fun to think about than putting together algorithms.

• 36:50Speaker 03

  It kind of frees up the senior software engineers to think more architecturally. And then, once they have a really good understanding of what's what the current state of the repository is, what the current state of the architecture is and when they're introducing something new, they're really thinking at an architectural level. And they articulate that to Klein and that's also there's like some skill involved there. And some of that can be mitigated with like asking follow up questions, being proactive about clarifying things on the agent side. But ultimately, you need to articulate this new architecture to the agent. And then the agent can go down and down into the mines and implement everything for you. And it is more fun working that way. Like personally, like I find it a lot more engaging to just think on a more architectural level.

• 37:34Speaker 03

  And for junior engineers, it's a really good paradigm to learn about the code base. It's kind of like having a senior engineer in your back pocket where you're asking Klein like, hey, can you explain the repository for me? If I wanted to implement something like this, what files would I look at? How does this work? It's great for that as well.

• 37:53Alessio Fanelli?

  If you're moving on from competition, I have one last question. Competition. So there's Twitter beef with RuCode. I just want to know what the backstory is because you tweeted yesterday. Somebody has RuCode to add Gemini CLI support. And then you guys responded, just copy it from us again. And they said, thank you. We'll make sure to give credit. Is it a real beef?

• 38:14Speaker 03

  No, no.

• 38:15Alessio Fanelli?

  A friendly beef?

• 38:16Speaker 03

  I think we're all just having fun on the timeline. There's, there's a lot of forks.

• 38:22Speaker 02

  There's like 6,000 forks.

• 38:23Speaker 03

  Yeah, there's like, if you search Klein in the VS Code marketplace, it's like the entire page, just like forks of Klein. And there's like even forks of forks that, you know, came out and raised like a whole bunch of money. And it's, yeah, it's crazy.

• 38:38Speaker 02

  The top three apps and open router are all Klein and then Klein fork, Klein fork. It's funny.

• 38:42Speaker 03

  Yeah, billions of tokens getting sent through like all these forks. There's like, there's like fork wars and 10,000 forks and all you need is a knife, you know?

• 38:54Speaker 03

  No, it's, it's exciting. I think they're all really cool people. We've got people in Europe forking us. We've got people in China making like a little fork of us. I think Samsung recently came out with like a, was a Wall Street Journal article where they're using Klein, but they're using like their own little fork of Klein that's kind of isolated. You know, we, we encourage it.

• 39:12Alessio Fanelli?

  Do you have any regrets about being open source?

• 39:15Speaker 02

  Not at all. I think Klein started off as this like really good foundation for what a coding agent looks like. And people just had a lot of their own really interesting ideas and spin offs and concepts about, you know, what they thought, you know, they, that they wanted to build on top of it was. And just being able to see that and see the excitement around just in the space in general has just been, I think, inspirational and has helped us kind of glean insights into what works and what doesn't work and incorporate that into our own product. And for the most part, I think for, you know, the Samsungs and all the organizations where there's a lot of friction and, and being able to use software like this on their, on their code bases. It reduces that barrier to entry, which I think is like incredibly important. When you want to get your feet wet with this whole new agentic coding paradigm that's going to completely upend

• 39:59Speaker 02

  the way that we've written software for, for decades. So in the grand scheme of things, I think it's a net positive for the world and for the space. And so no regrets.

• 40:07Speaker 03

  In a lot of ways, like, you know, it's us and the forks. We were kind of there originally when we were like the only ones with this like philosophy of keeping things simple, keeping things down to like the model, letting the model do everything, not cutting on, not trying to make money off of inference, going context heavy, reading files into context very aggressively and kind of going back to Claude code. I was actually like, it was really nice to see that they they came out and they validated our whole philosophy of like keeping things as simple as possible. And that kind of goes in with like the whole rag thing, which is like rag was this

• 40:45Speaker 03

  early thing in like 2022, you started getting these vector database companies, context windows were very small. This was like a way of people called it like, oh, you can give your AI infinite memory. It's not really that, but that was like the marketing that was sold to the venture backers that were like investing in all these companies. And it became this narrative that really stuck around. And like even now, like we we get like potential, like, you know, enterprise perspective, like they're they're going through like the procurement process and there it's almost like they're going through like a checklist asking like, hey, do you guys do like indexing and like of the code base and doing rag? And I'm like, well, why? Like, why are you like, why do you want to do this?

• 41:27Speaker 03

  I think Boris said it said it very well on on this exact podcast where we tried rag and it doesn't really work very well, especially for coding. It's like, the way rag works is you have to like chunk all these files across your entire repository and like chop them up into small little pieces and then throw them into this hyper dimensional vector space and then pull out these random chunks when you're searching for relevant code snippets. And it's like fundamentally, it's like so schizo and like, I think it actually distracts the model. And you get worse performance than just doing well, like a senior software engineer does when they first they're introduced to a new repository where it's like that you look at the folder structure, you look through the files, oh, this file imports from this other file. Let's go take a look at that.

• 42:13Speaker 03

  And you kind of agentically explore the repository. That's like. We found that works so much better. And there's like similar things where it's like, like the simplicity always wins, like this bitter lesson where fast apply is another example. So Cursor came out with this fast apply, like they call the instant apply back in July of 2024, where the idea was models at the time were not very good at editing files. And the way editing files works in kind of the context of an agent is you have a search block and then a replace block where you have to like match the search block exactly to what you're trying to replace. And then a replace block just swaps that out. And at the time, models were not very good. It was like, I forget, like GPT they were using under the hood at the time wasn't very good at formulating these search blocks perfectly and it would fail oftentimes.

• 42:59Speaker 03

  So they came up with this clever workaround to fine tune this fast apply model where they let these frontier models at the time, they let them be vague, they let them output those like lazy code snippets that we're all very familiar with where it's like rest of the file here, like rest of the imports here, and then fed that into this fine tuned fast apply model that was like, probably like a Quen 7B or something, Quantize, very small, dinky little model. And they fed this lazy code snippet into this smaller model and the smaller model we fine tuned to output the entire file with the code changes applied. And that, you know,

• 43:39Speaker 03

  the, one of the founders of ADR said this really well in like very early GitHub discussions, where he said like, well, now instead of worrying about one model messing things up, now you have to worry about two models messing things up. And what's worse is the other model that you're giving, that you're handing your production code to, this like fast apply model, it's like, it's a tiny model, its reasoning is not very good, its maximum output tokens, you know, there might be 8,000 tokens, 16,000 tokens, now they're training like 32,000 tokens, maybe. And a lot of the coding files, like we have a file in our repository that's like 42,000 tokens long. And that's longer than the maximum token output length of one of these smaller

• 44:22Speaker 03

  fast apply models. So what do you do then? Then you have to build workarounds around that. Then you have to build all this infrastructure to like pass things off and then it's making mistakes. It's like very subtle mistakes too, where it's like, it looks like it's working, but it's not actually what the original frontier model suggested. And it's like slightly different.

• 44:40Speaker 03

  And it introduces like all of these subtle bugs into your code. And what we're starting to see is like, as AI gets better, the application layer is reducing. You're not going to need all these clever workarounds. You're not going to have to maintain these systems. So it's really liberating to not be bogged down with RAG or with fast apply and just focus on this like query gentic loop and maximizing diff edit failures. Like in our own internal benchmarks, Claude Sonnet four recently hit a sub 5% or like around actually 4% diff edit failure rate. At the like, when fast apply came out, that was way higher. That was like in the twenties and the thirties. Now we're down to 4%, right? And in six months.

• 45:22Alessio Fanelli?

  How does it go to zero?

• 45:24Speaker 03

  Well, it's going to zero like as we speak, it's going to zero every day, you know? And I was actually talking with the founders of some of these companies that do fast apply. They were trying to kind of work with us. Their whole bread and butter is fine tuning these fast apply models. And you know, like relays and morph. And I had like a very candid conversation with these guys where I was like, well, there's a window of time where fast apply was relevant. Cursor started this window of time back in July. How much time do you think we have left until they're no longer relevant? Do you think it's an infinite time window? They're like, no, it's definitely finite. Like this, this era of fast apply models is definitely coming to an end. And I was like, well, how long do you guys think? They were like, maybe three months, maybe less. So I still think there's some cases where RAG is useful.

• 46:09Speaker 03

  You know, if you have a lot of human readable documents, a large knowledge base of documents where you don't really care about like inherent logic within them, like sure, index it, chunk it, do retrieval on it. Or fast applies, like maybe if your organization, you're forced into using like a very small model that's not very good at search and replace, like a deep seek or something. You know, maybe use a fast apply model.

• 46:34Speaker 02

  I think RAG and fast apply were these just tools in a toolkit for when models weren't the greatest at large context or search and replace def editing. But now they are extra ingredients that could make things go wrong that you just don't need anymore. There was an interesting article from cognition labs about, you know, multi-agent orchestration. Getting right into it. It's like you're on autopilot for us.

• 47:03Speaker 02

  That's cool. Yeah.

• 47:04Speaker 03

  It's a great article, by the way.

• 47:05Speaker 02

  Yeah, it's a great article. They talked about how, you know, when you start working with different models, different agents, there's a lot that gets lost in the details. And, you know, the devil are in the details. That's, those are the most important things. And making sure that it doesn't, you don't have the agents who are like running in loops and running to the same issues again. And have sort of like all the, the right context. And, and so I think being close to the model, throwing all the context you need at it, not taking these cost optimized approach to pulling in relevant context. Use something like RAG or a cheaper model to apply edits to a file. I think ultimately, yes, it's more expensive asking, you know, a model like Claude Sonnet to do sort of all these sorts of things,

• 47:46Speaker 02

  to grab an entire code base and to, you know, fill up its entire context. But you kind of get what you pay for. And I think that's been another benefit of, of being open source is that our developers, they can peek under the kimono. They can see, you know, where their requests are being sent, what prompts are going into these things. And that creates a certain level of trust where, you know, when they spend 10, 20, a hundred dollars a day, they know kind of where their data is being sent, what model it's being sent to, what prompts are going into these things. And so they get comfortable with the idea of spending that much money, get the job done.

• 48:20Speaker 03

  Yeah, it's like not making money off of inference. I think the, the incentives are so, they're so relevant in this discussion because, you know, if you're incentivized, you know, if you're charging, you know, $20 per month. And you're trying to make money on that. You're going to be offloading all kinds of important work to smaller models or optimizing for costs with RAG, like retrieval with RAG, not reading the entire file, but maybe reading like a small snippet of it. Whereas if you're not making money off inference and you're just going direct, you know, users can bring their own API keys. Well, then all of a sudden, you're not incentivized to cut down on cost. You're actually incentivized just to build the best possible agent. And we're starting to see this trend of the whole industry is moving in that direction, right?

• 49:04Speaker 03

  You're trying to see like everyone open up to pay as you go models or pay directly for inference. And I think that is the future.

• 49:12Alessio Fanelli?

  What's the client pricing business model?

• 49:16Speaker 02

  Right now, it's bring your own API key. Essentially, just whatever pre-commitment you might have to whatever inference provider, whatever model you think works best for your type of work. You just plug in your Anthropic or OpenAI or OpenRouter, whatever it is, API key into client and it connects directly to whatever model you select. And I think that level of transparency, that level of we're building the best product. We're not focused on sort of capturing margin on, you know, the price obfuscation and clever tricks and model orchestration to, you know, keep costs low for us and optimize for higher profits. I think that's put us in this like unique position to really push these models to their full potential.

• 50:00Speaker 02

  And I think that's shown, you know, I think that's, that's, you get what you pay for. Throw a task in client and, and it gets expensive, but.

• 50:10Speaker 03

  That's the cost of intelligence, right?

• 50:11Speaker 02

  It's the cost of intelligence, yeah. So yeah, the business model right now is, is you, you get to choose kind of where it's open source. You can fork it. You can choose where your data gets, and you could choose who you want to pay. A lot of organizations we've talked to get some, you know, a certain level of volume based discounts with, with these providers. And so they could, they can take advantage of that through client, which is helpful because client fee got pretty expensive and yeah.

• 50:34Speaker 01

  Wait, so I mean, I'm still not hearing how you make money. Like you said, you don't.

• 50:38Speaker 03

  Why?

• 50:39Speaker 01

  Why make money?

• 50:40Speaker 03

  Yeah.

• 50:42Speaker 01

  Because you have to pay your salaries?

• 50:44Speaker 03

  No, that's the, that's the, a lot of people ask us that and I always just throw the why at them, but it's.

• 50:49Speaker 01

  These sound like the party fool guys.

• 50:52Speaker 03

  The, the real answer is enterprise. So.

• 50:55Speaker 01

  We can say because you're, you know, we released this when you launch it. Yeah.

• 50:58Speaker 03

  Yeah. So you want to talk about enterprise?

• 51:01Speaker 02

  Yeah, I think being open source and bringing an API key has given us a lot of easy adoption in these organizations where things like data privacy and control and security are top of mind. And it's hard to commit to sending their code in plain text to God knows what servers, training their data to do, training their data on models that might, you know, output their IP to random users. I think there, people are a lot more conscious about where their data is getting, getting sent and what's being used to it. And so it's given us this opportunity to say, okay, nothing passes through our own servers. You have total control over the entire application where your data gets sent. And that's given organizations that, you know, we've been talking to over the course of the last couple of months.

• 51:46Speaker 02

  This sort of like easy adoption. And I think this opportunity for us to, to work more closely with them and say, you know, what are all the things that we can do to help with adoption in the rest of your organization? Essentially, how can we pour gasoline on sort of the evangelism that, you know, people have for client in these organizations and spread the usage of, of agenda coding, I think at an enterprise level?

• 52:08Speaker 03

  Well, yeah, what's, what's crazy is, um, so we, we had, we open source client, people really liked it. Developers were using it within their organizations. Their organizations were kind of like reluctantly okay with it because they saw like we're open source and we're not sending our data, their data anywhere. They could use their existing API keys. And then we launched like on our website, like a contact form for enterprise. Like if you're interested in enterprise offering, hit us up. And we had no real enterprise product at the time. And it turned out like we just got this massive influx of big enterprises reaching out to us. And, you know, we had a Fortune five company come up to us and they were like, hey, um, we have hundreds of.

• 52:51Speaker 03

  Using client within our organization and this is a massive problem for us. This is like a fire that we need to put out because we have no idea what API keys they're using, how much they're spending, where they're sending their data. Please just like, let us give you money to make an enterprise product. So the product kind of just evolved out of that.

• 53:10Speaker 02

  Right, right. I mean, it's, it really just comes down to more of listening to our users. So right after we put out this page, we just had a lot of demand for sort of like the table stake, enterprise features, the security, guardrails and governance and insights that sort of like the admins in these organizations need to reliably use something like client. Yeah, we've gone a lot of people wanting us to sort of give them two things. Invoices, just to help with like all the budgeting and spending the, you know, thousands of dollars.

• 53:40Speaker 01

  All the Europeans.

• 53:42Speaker 02

  Yeah, just the other thing which I thought was a little bit surprising was some level of insight into the benefit that clients providing them. So it could be our site or lines of code written. Cause it allows these sort of like AI forward drivers for adopting these sorts of tools in these organizations to take that as a proof point and go to the rest of their teams and say, this is how much client's helping me. You need to start adopting this so we can keep up with the rest of the industry.

• 54:07Speaker 01

  This for like internal champions to prove the ROI?

• 54:10Speaker 02

  Exactly.

• 54:11Speaker 01

  Okay.

• 54:12Speaker 02

  Uses sort of evidence for this, you know, to justify the spend.

• 54:16Speaker 01

  Yeah.

• 54:16Speaker 02

  But also to promote the product in these organizations.

• 54:19Speaker 01

  We can do this afterwards, but we'd like to talk to those and actually feature some of them, what they're saying to their bosses on the podcast so that we can get a sense. Cause like oftentimes we here, we only talk to founders and builders of like the dev tool, but like not the end consumer. And actually we want to hear from them, right? Like about how they're thinking about it, what they need. Kind of cool. One thing I wanted to ask, to double click on is the relationship between open router and then like your, your enterprise offering, right? So my understanding is currently everything runs through open router.

• 54:49Speaker 02

  Not everything. So you can bring API keys to OpenAI, Anthropic, Bedrock.

• 54:55Speaker 01

  And then you have a direct connection there. If, if I.

• 54:57Speaker 02

  The user has a direct connection there.

• 54:59Speaker 01

  Yeah, great. But everything else would run through OpenRouter. And so basically, the enterprise version of Klein would be you have your own OpenRouter that you would provide visibility and control to that enterprise.

• 55:13Speaker 03

  Yeah, like that's for like the self-hosted option, right? Like, there's a lot of enterprises where they're okay with not self-hosting, but as long as they're using their own Bedrock API keys and stuff like that. Whereas the ones that are really interested in like self-hosting or like that want to be able to manage their teams, there would be like this internal router going on.

• 55:32Speaker 01

  The curious thing here is like, what if, what if model costs just go to zero? Like Gemini code just comes out and it's like, yeah, guys, it's free.

• 55:41Speaker 02

  Well, yeah, no, they, they came up with, yeah, it'd be great for us. So our, our thesis is inference is not the business.

• 55:46Speaker 01

  You would just never make money on inference, right?

• 55:47Speaker 02

  Yeah, we want to give the end user total transparency into price, into, which I think is like incredibly important to, you know, even get comfortable with the idea of spending as much money as you do. I think the, the price obfuscation in this space has given developers this reluctance to opt into usage-based to plans. And, and we're seeing a lot of people kind of converge on this concept of, okay, maybe have like a, a base plan just to, to use the product, but sort of get out of the way of the inference and respect the end developer enough to give them the level of insight into not just the cost, but the models being used and give them more confidence in spending however much it takes to get the work done. I think there, you know, there, you know, you can use tricks like RAG and Fast Supply

• 56:29Speaker 02

  and things like that to keep costs low. But for the most part, there's enough ROI on, on coding agents where, you know, people are willing to spend money to, to get the job done.

• 56:40Speaker 03

  And for a truly like good coding agent, the ROI is almost hard to even calculate because there's so many things that I would have never even bothered doing. But then I, now I have Klein and I could just like do this weird experiment or do this side project or, you know, fix this random bug that I would have never even thought about. So like, how do you measure that? Right?

• 57:01Speaker 01

  One variant of this problem, we're about to move on to context engineering and memory and all the other stuff. One variant of this I wanted to touch on a little bit was just background agents and multi-agents. So the instantiations of this now, I would say, our background agents is, it would be Codex, for example, like spinning up, you know, one PR per minute and, or Devon or Cognition. So would you ever go there? That's one concrete question I can ask you, like, would there be client on the server, whatever? And then the other version is still on the laptop, but more sort of parallel agents, like kind of the Kanban is currently very hyped right now. People are making like Kanban interfaces for Cursor and also for Cloud Code.

• 57:45Speaker 01

  Just anything like in the parallel or background side of things.

• 57:48Speaker 03

  So we're releasing a CLI version of client and using the CLI version of client, it's fully modular. So you can ask client to run the CLI to spin up more clients, or you could run client in some kind of cloud process in a GitHub action, whatever you want. So the CLI is really the form factor for these kind of fully autonomous agents. And it's also nice to be able to tap into an existing client CLI running on your computer and be able to like take over and steer it in the right direction. So that's also possible. But what do you think, Sad?

• 58:23Speaker 02

  I don't think it's an either or. I think all these different modalities complement each other really well. So the Codex, the Devins, Cursor's background agent, I think they all sort of accomplish the same thing. They, if we were to come out with our own version of it, I'd say that it would be the foundation for how other developers could build on top of it. So Nick's older brother, Andre, he's sort of thinking 10 years ahead. And it always kind of blows my mind a little bit about some of the ideas that he has about where the space is going. But we recently had a discussion about building this open source framework for coding agents for any sort of platform, building the SDK and the tool necessary to bring client to,

• 59:08Speaker 02

  you know, Chrome as an extension, to the CLI. Two jetbrains, two Jupiter notebooks, two your smart car, whatever it is. But to build the-

• 59:17Speaker 01

  Your fridge.

• 59:17Speaker 02

  Your fridge, exactly. To, to put to-

• 59:20Speaker 01

  Microwave, maybe?

• 59:21Speaker 02

  Yeah, exactly. I mean, this is what we saw, kind of like with, you know, the 6000 forks, you know, on top of Klein is, we sort of like, put together this foundation for how this community of developers, we sort of put together this foundation that this community of developers could like, build on top of, and sort of take advantage of, you know, their experiments and imagination, their creativity about where the space is headed. And I think, looking forward, building an open source foundation and the building blocks for how we bring something like Klein to things that go outside the scope of software development, or, you know, VS Code extension. I think that'll open up the door to things that, you know, ultimately complement each other really well, but it'll never be sort of this like, either or thing. I think background agents are good for certain kinds of work, and parallel can been,

• 1:00:05Speaker 02

  multi-agents might be good for when you want to experiment and iterate on, you know, five different versions of, you know, how a landing page might look. And then something like a back and forth with a single agent like Klein, works really well for when you want to, you know, pull context and put together a really complicated plan for a really complex task. And I think all these different tools will ultimately end up complementing each other, and people will kind of develop a taste and an understanding for what works best for what kind of work. But I, I think something, just looking 10 years ahead, we at the very least want to sort of be at the frontier of providing sort of the building blocks for what the next thing is after background agents or, you know, multi-agents.

• 1:00:43Speaker 01

  I was gonna go into context engineering, kind of like, topic du jour. I think that, uh, this is kind of similar-ish in a thread to RAG, and how RAG is a mind virus, which I love, by the way, that, the way that you phrased it. Yeah, you, you have, you have in your docs, context management. You also have a section on memory bank, which is kind of cool. I think, uh, a lot of people are trying to figure out memory. Let's just start at the high level, and then we'll go into memory later. Uh, what, you know, what does context engineering mean to you?

• 1:01:07Speaker 02

  Context engineering mean to me?

• 1:01:10Speaker 03

  Meets prompt engineering.

• 1:01:12Speaker 01

  Yeah, right. Like, I mean, so I think like there is a lot of art to like what goes in there. I think that really is like the 80 20 of building a really good agent is like figuring out what goes into the context. And and I go, you know, I think interplay between MCP and your system client, you know, recommended prompts, I think is what is ultimately making a good agent.

• 1:01:38Speaker 03

  Yeah, I I think context management is like, one part of it is what you load in to context. The other part of it is how do you clean things up when you're reaching the context window? Right? How do you curate that whole lifecycle from zero to maximum context window? And the way that I think about it is there's so many options on the table. And there's so many risks to misdirecting the agents or distracting the agents. There's ideas about, you know, rag or other kinds of forms of retrieval. That's that's one idea. There's the agentic exploration. That's another idea that we found works much better.

• 1:02:22Speaker 03

  And it seems like the trend is generally for loading things into context. It's giving the model the tools that it can use to pull things into context, letting the model decide what exactly to pull into context, as well as some hints along the way, kind of like a like a map of what's going on. Like ASTs, abstract syntax trees, potentially what tabs they have open in VS Code. That was actually in our internal kind of benchmarking that turned out to work very, very well. It's almost like it's reading your mind when you have like a few tabs open.

• 1:02:53Speaker 01

  It stresses me out because like sometimes then I'm like, I have like unrelated tabs open and I have to go close them before I kick off a thing.

• 1:02:59Speaker 03

  I I wouldn't think too much about, especially when you're using Klein. Klein does a pretty good job of just navigating that. But I definitely, there are edge cases, right? There's edge cases for everything. And it's kind of like, okay, what's like the majority use case is like, you know, when are you starting a brand new task? And you don't have a single tab open that's relevant to it. Obviously, in the CLI, you might, you don't have that little indicator. So there you have to think outside the box for that. So that's like for reading things into context. And then for context management is when you're approaching the full capacity of the context window. Is how do you condense that? And we've played around with this kind of naive truncation very early on where we just like throw

• 1:03:43Speaker 03

  out the first half of the conversation.

• 1:03:46Speaker 01

  It's common.

• 1:03:46Speaker 03

  And there is problems with that, obviously, because it's like, kind of like you're halfway through a book and you're like, you start reading halfway through, right? You don't know anything that happened beforehand. And we like to think a lot about like narrative integrity is like every task in Klein is kind of like a story. It might be a boring story where it's like this lonely coding agent that's just, you know, determined to help you solve, you know, whatever it is, like the child, like the, the big thing that the protagonist needs to overcome is like the resolution of the task. Right? But how do we maintain that narrative integrity where every step of the way the agent can kind of predict the next token, which like predict the next part of the story to reach that conclusion?

• 1:04:28Speaker 03

  So we played around with things like cleaning up duplicate file reads. That works pretty well. But ultimately, this is another case where it's like, well, what if you just give the model, like, what if you just ask the model, like, what do you think belongs in context? Another form of this is summarization, which is like, hey, summarize all the relevant details and then we'll swap that in. That works really, really well.

• 1:04:50Speaker 01

  Yep. Double clicking on the AST mention, that's very verbose. When do you use that?

• 1:04:56Speaker 02

  Right now, it's a tool. The way that it works is when Klein, once, when Klein's doing sort of the agentic exploration of trying to pull in relevant context and it wants to sort of get an idea of what's going on in a certain directory, for example, there's a tool that lets it pull in all the sort of language from a directory. So it could be the names of classes, the names of functions, and that gives it some idea of, okay, here's what's going on in this, in this folder. And if it's, if it seems relevant to whatever the task is trying to accomplish is, then it's sort of like zooms in and starts to actually read those entire files into context. So it's essentially a way to help it kind of figure out how to navigate through large code bases.

• 1:05:37Speaker 03

  Yeah, we, we've seen some companies working on, it's like an interesting idea. It's like an AST, but it's also a knowledge graph and you can run these discrete deterministic, almost like actions on this knowledge graph where you could say like, hey, find me all the functions that, find me all the functions of the code base and find me all the functions that aren't being used and delete all of them. And the agent can kind of reason in this almost like sequel like language. Working with this knowledge graph to do these kinds of global operations. Like, right now, if you ask a coding agent to go through and remove all unused functions, or do like some kind of large refactoring work, in some cases it might work, but very oftentimes, it's just gonna struggle a lot, burn a lot of tokens and fail ultimately.

• 1:06:22Speaker 03

  Whereas with these kinds of tools, it can actually operate on the entire repository with these kinds of query, like, short little query statements. I think there is a lot of potential in something like this, where it's like the next level beyond the AST, and it's like a language for querying this kind of knowledge graph. But, like we've seen with the Claude 4 release, is these frontier model shops, they tend to train on their own application layer. And you might come up with like a very clever tool that in theory would work really well, but then it doesn't work well with Claude 4, because Claude 4 is trained to grep, right? So, that's another interesting phenomenon,

• 1:07:03Speaker 03

  where it's like you're expecting these frontier models to become more generalized over time, but instead, they're becoming more specialized, and you have to like support these different model families.

• 1:07:16Alessio Fanelli?

  Just to wrap on the memory side, memory is almost the artifact of summarization. So you summarize the context, and then you kind of extract some sides. Any interesting learnings from there? Like, things that are maybe not as intuitive, especially for code? I think people grasp the like, memory about humans, but like, what are memories about code bases and things look like?

• 1:07:37Speaker 02

  I think memories, right now, for the large part, are mostly useless. I think the kinds of memories that you might want the coding agent to hold on to are, you know, specific quirks about how, you know, your team works in the project, or certain rules, like, only use like camel case, for example. It's better to place those sorts of things in like a general sort of like guideline or rules file, for example. But I've found that the idea of like asking the agent, at least coding agents, to like hold on to certain memories about the project, or like how you work, or things like that, or you mostly have to like force it to store those things into memory, and I don't think people, they don't want to have to think about those sorts of things, so.

• 1:08:21Speaker 02

  It's something we're, we're thinking about is, is how can we hold on to the tribal knowledge that these agents learn along the way that people aren't documenting or putting into rules files without these are having to go out of their way to sort of force them to store these things into a memory database, for example.

• 1:08:37Speaker 03

  Those were like, kind of like workspace rules or tribal knowledge, like general patterns that you use as a team. But then there is, like in our, we ran this like internal experiment where we built this to do list tool where it was only one tool where you could just write the to do. And every time you could like rewrite the to do from scratch. And we would passively as part of every, like not every message, but like every once in a while, we would pass in this context of what the latest state of this to do list is. And we found that that actually keeps the agent on track after multiple rounds of context summarization and compaction. And it could all of a sudden build like an

• 1:09:22Speaker 03

  entire complex kind of task from scratch over, you know, 10x the, the context window length. And in internal testing, this was like very, very promising. So we're trying to flesh that out. And I think something like that, we had earlier versions of the, the memory bank, which actually are like Nick, Nick Baumann, our, our marketing guy, came up with this memory bank concept where it was like this client rules where you would tell a client like, hey, whenever you're working, have the scratch pad of what you're working on. And this is like a more built in way of doing that. And I think that also might be very, very, very helpful for the agents to just have like a little scratch

• 1:10:03Speaker 03

  pad of like, hey, what have I done so far? What's left? Specific app file mentions like what kind of code we're working on, general context and passing that off between sessions. Yeah.

• 1:10:15Alessio Fanelli?

  Any thought on Claude MD versus Agents MD versus Agent MD? I built an open source tool called Agents 927, like the X KCD that just copy paste this across all the different file names, so all of them have access to it. Do you think there should be a single file? Like, there's also like the IDE rules versus the agent rules. There's kind of like a lot of issues.

• 1:10:35Speaker 02

  I actually think it's fine that each of these different tools have their own specific instructions, because I find myself using a cursor rules and a client rules separately. When I want Klein the agent, I want him to work, you know, a certain way that's different than how I might want, you know, cursor to interact with my code base. So I think each tool is specific to the kind of work that I do, and I have different instructions for how I want these things to operate. So I think, I've seen like a lot of people complain about it, and I get that it could make code bases look a little bit ugly, but for me, it's been like incredibly helpful for them to be separated.

• 1:11:08Alessio Fanelli?

  I noticed that you said him. Does this Klein have?

• 1:11:11Speaker 02

  Klein's the he/him?

• 1:11:12Alessio Fanelli?

  Yeah. Okay. Does he have a whole backstory?

• 1:11:15Speaker 02

  Yeah.

• 1:11:15Alessio Fanelli?

  Personality?

• 1:11:16Speaker 02

  Klein, so Klein is a play on CLI and editor.

• 1:11:20Alessio Fanelli?

  Cause it used to be Claude Dev and now it's Klein.

• 1:11:22Speaker 02

  Yeah, I feel like Klein kind of stands out in the space for having, for being a little more humanized than something like, you know, a cursor agent, or a copilot, or a cascade.

• 1:11:33Alessio Fanelli?

  And I think there's Devon, which is a real name, you know?

• 1:11:36Speaker 02

  Well, yeah.

• 1:11:36Speaker 03

  Claude is a real name, I guess.

• 1:11:37Alessio Fanelli?

  Claude's a real name.

• 1:11:38Speaker 02

  Yeah, yes, I've been, I've been, I think we've all been intentional about just sort of humanizing it, because at least in working with kind of Gizzy more confidence in it and that I could like lean on it a little bit more. There's, there's kind of a, of a trust building with, I think with an agent, and the humanizing aspect of it, I think has been helpful to me personally, and.

• 1:11:56Speaker 03

  This goes back to like the narrative integrity, it's just, it's actually really important, I think, to anthropomorphize agents in general, because everything they do is like a little story. And without having a distinct kind of identity, you get worse results. And when you're developing these agents, that's kind of how we need to think about them, right? We need to think that we're like crafting these stories. We're almost like Hollywood directors, right? We're putting all the right pieces in place for the story to unfold. And yeah, having an identity around that is really, really important. And Klein, you know, he's a cool little guy. He's, you know, he's

• 1:12:33Speaker 01

  Just a chill guy.

• 1:12:33Speaker 03

  He's just a chill guy. He's helping us out, you know? He's always like happy to help. Or if you tell him to not be happy, he can be very grumpy. So that's great.

• 1:12:45Speaker 01

  Awesome. I know you're hiring. You are, you have your 20 people now. You are aiming to 100. You have a beautiful new office. What's your best pitch for working at Klein?

• 1:12:55Speaker 02

  A lot of our hiring right now is, so far, it's been just friends of friends, people in our network, people that we've worked with before that we've trusted and that we know can show up for like this incredibly hard thing that we're working on. And there's a lot of challenges ahead. And I think the problem space is probably the most exciting thing to be working on right now. Engineers in general love working on things that make their own lives easier. And so I couldn't imagine working on something more exciting than a coding agent. And you know, it's a little biased, but I think a large part of it is it's an exciting problem space. We're looking for really motivated people that want to work on challenges, like figuring out kind of like what the next 10 years looks like and building kind of the foundation for, you know,

• 1:13:39Speaker 02

  what comes next after background agents or multi-agents? And really help in sort of defining how all this shapes up. We have this like really excited community of users and developers. I think being open source has also created a lot of goodwill with us, where a lot of the feedback we get is like incredibly constructive and helpful in shaping our roadmap and the product that we're building. And working with a community like that is like one of the most fulfilling things ever. Right now, we're kind of in between offices, but you know, doing things like go-karting and kayaking and things like that. So it's a lot of hard work, but you know, we make sure to have fun along the way. So.

• 1:14:15Speaker 03

  Yeah, no, like Klein is a, it's a unique company because it really does feel like we're all just like friends building something cool. And we work really, really hard and the space is, it's not just competitive. It's like hyper competitive. There's like capital is flowing into all, every single possible competitors. We have forks of forks, like I said, raising tens of millions of dollars. And we're growing very rapidly. We're at 20 people now. We're aiming to be at 100 people by the end of the year. And being open source, it has its own challenges. It's like people, we do all this research. We do all this benchmarking work to make sure our diff editing algorithm is robust.

• 1:14:56Speaker 03

  The way we're working with these models to optimize for the lowest possible diff edit failures. And then we open source that. And then we posted on Twitter and someone's like, oh, thanks so much for open sourcing that. I'm going to go and like raise a bunch of money with like our own product with it. But the way that I see it is like, this is, you know, let them copy. We're the leaders in the space. We're, we're kind of showing the way for the entire industry and being an engineer and building all this stuff is super exciting. So working with all these people is just amazing.

• 1:15:26Speaker 02

  Okay.

• 1:15:26Alessio Fanelli?

  Awesome. Thank you guys for coming on.

• 1:15:28Speaker 02

  Yeah.

• 1:15:29Speaker 03

  All right.

• 1:15:29Speaker 02

  Thank you.

• 1:15:29Speaker 03

  Thanks so much.

• 1:15:30Speaker 02

  This was so much fun.