The Future of Computers Won’t Look Like This

本站添加: 2026-05-13

[00:00:00]All right. Hi everyone. Welcome to a new pod. Today we have Utal and Muhammad.

[00:00:04]They're the co-founders of Open Computer. They're trying to build uh the sandboxing layer for AI agents. Uh you might have seen a bunch of companies around these uh you know uh around this specific niche pop up. So we'll talk about how they're trying to grow this market. How this market has become very competitive. They started in this market two quarters ago. Um what they were doing before this. They just told me they were working out of London before this. They have a bunch of inflated projects through a parent company. We'll understand all of that. their work primarily a lot of it is open source so we'll understand that as well um without any further ado Muhammad welcome to the pod we'll have to start from the top you know your your guys' background right after right after university >> yeah uh before we start I think we have a third co-founder Igor who couldn't make it today he's dealing with customer problems so yeah uh kudos to Igor too um but yeah I think u we started the company in London um we were trying to simplify AWS initially uh we tried to um eager used to be in Palunteer earlier had seen these problems. Mo was in prime video seen similar problems of like internal developer tools and how how people um struggle with infra. Uh so we were trying to build like a heroku like UI inside AWS. Um realized very quickly that that was a bit of a tarpit idea. Um was kind of like a holy grail. Everybody needs it. But like most developers um like once the once the first DevOps engineer is hired, they tend to bring Terraform with them and they bring their tooling with them and then they sort of take the team with them, right? Um so we we realized and we were generating Terapform under the hood. So um in immediately after that we launched this project called which is now called Open Taco. Um now it's deployed across Fortune 500s and startups. It's an open source terform automation collaboration software. It's kind of like an alternative to Hashi Corps terapform cloud, right? Um that grew pretty well and recently like a couple quarters ago while speaking to a bunch of our customers we were like what are your biggest win for problems right now um and then sort of open computer got pulled out of us uh because they were all building agents agents needed compute different sort of forms of compute um we have our take I can elaborate on that but yeah that's TLDDR the story we were in London initially uh we raised around like last Q3 Q4 last year um and u after we raised we sort of moved here because both access to capital and access to customers are both sort of super easy here um and both super important for fast growing companies. So yeah, >> makes sense. Um so from what I understand now you've sort of I wouldn't call it a pivot but I would assume you're primarily focusing on open computer as a product.

[00:02:30]>> It's a new field. I was talking to right before this u you know they were one of the first people who started uh and it's slowly getting overly commoditized. So would love to know you know why did you think of starting in this market? you mentioned you know a bunch of customers mentioned this but also you know there are so many providers already in the market uh so it's a very competitive space uh would love to know you know your take on why what made you start >> yeah more do you want to go or like yeah >> so the reason we decided to get into this crowded space is uh because we realized that when it started the sandbox um you know craze started 2 years ago agents looked very different from what they are looking today and what they will be looking tomorrow and so like when they started agents were very short-lived and the idea of sandboxes was this short-lived tool calling thing very effeal type of workloads. Uh but slowly over time agents are running for longer and they want more access and hungrier for more compute and so we took a bet that you know eventually where this is going is like more longunning more forever running type of compute that the agents would like to reuse if possible. So which is what why we called it open computer. We initially called it open sandbox. There was a conflict in the name. Uh we renamed it to open computer because that's more descriptive of what we're we're doing.

[00:03:48]>> Got it. Makes sense. So this is like yeah sandboxes are generally meant to be ephemeral but you guys are taking a bet on you know these being much more longunning.

[00:03:54]>> Y >> interesting. Okay. So how does it this let's start from the tech I guess and you know uh what happens when I use open computer you know why will a developer use it? What are the kind of use cases that is that you guys are seeing right now? people you know use open computer for >> yeah use cases I can I can go on and on like like there's um manage open claw for example manage herms manage herms for your users like there's open claw for x right like open claw for hiring open claw for growth and stuff like that people are building vertical lovables like lovable was great lovable started a new paradigm but like there's people I know building specifically lovable for internal finance teams right like uh stuff like that um so and a whole host of internal agents being built on top of like cloud agent SDK and open agent SDK as like they're not just automating RPA.

[00:04:37]RPA is one of them, right? Like stuff that you would do with Zapier N810 earlier now that is much easier with with Claudian SDK with one system prompt, right? Um that's that's something that we're seeing too like a lot of longer running internal agents.

[00:04:50]Um >> stuff similar to ramps inspect. Um I'm sure a lot of your listeners would have heard about that too. Um which is like an internal background agent for for developers. Um there's also people building software factories right like internal again but like uh canban boards where there's like every issue is a is a is a background coding agent that's going in the background and doing jobs and increasingly what we're seeing is that um long horizon RL tasks are also coming through. We are still early in this phase but like we haven't spoken to enough people there but we see that there's a big use case here too. Um I think a bulk of large chunk of sandbox vendors actually have you know big contracts with RL companies. Um but yeah these are sort of a basket of use cases which require sandboxing and longunning sort of uh computers for agents I guess >> makes sense. Uh when I hear the term sandboxing though it it feels like you know it's meant for epheml tasks like that's what intuitively comes to my mind and if I ever want to do something more longunning like an open claw instance um feels like I'd want to deploy it on a VM. So I would love to know you know what makes that distinction you know what what would cause me to use a sandbox over a VM for longer running task.

[00:06:00]>> Yeah and that's where it's it might be a bit confusing because under the hood we are actually using a full hypervisor. So we use uh KU which is what was used in AWS to build EC2 early on not not anymore because they switched to Nitro but yeah we're thinking of it as a fullyfledged like EC2 equivalent but with better semantics. I think Paul used to say that what sandboxing should look like in the future is more like um EC2 semantics but what what was that >> lambda ergonomics >> lambda ergonomics but EC2 semantics is where we're going yeah >> it needs to spin up fast but needs to persist like you know there's there's that too the other thing is like we have what we think is unique to us is that we have elasticity so let's say you have an open claw inside inside running inside an open computer um it doesn't have to be perpetually overprovisioned. So if if it has to rust compilations are notoriously hungry, right? So it can scale up to let's say 64 um vcpus and then come back down, right? Like there's there's like um elasticity that the agent has on offer for itself and we're seeing increasingly that agents are smart enough to to to >> figure out elasticity for themselves and uh there's no compute primitive that does this as of today, right? like you either are perpetually overprovisioned or like yeah you're you're ephemeral. Um so or you're static like you know some people don't want to do it and like it's new so we may change too but like right now a lot of our customers are actually enjoying this so yeah >> interesting. Okay you're probably the first company I've heard of that provides elastic sandboxes. Um >> okay and you mentioned so you work at the hypervisor layer. So most other you know sandboxing companies that you think about are usually a wrapper on top of a GCP or an AWS. Does that mean you guys have your own data centers or >> um soon we will be to to be clear like a lot of other providers also do hypervisors. So there is there is like I I would say there's multiple categories.

[00:07:59]There's like process level sandboxes which is like uh just bash vcel and so on and there is the folks which more or less are hypervisor based which would include like firecracker ku or cloud hypervisor. Those are popular. There's a lot of people using one. As far as I know, we might be one of the few who went all in with Ko, which is a bit heavier but more like fully featured.

[00:08:24]And there is a middle ground which is like still containerbased, podman based.

[00:08:28]And I think that all three approaches are are viable. There's trade-offs. In terms of where we're hosted, we're currently like between Azure, AWS, and GCP. We're also experimenting with onrem because like I I always say like you can't build an AWS on on top of AWS. It's kind of possible for like experimentation but I think a lot of the primitives were already hitting a lot of roadblocks around like the file system speed and like we don't we don't want to like be slower because of that reason because like we're limited by what AWS primitives gives us. So yeah, we're if you go to our office now, we're experimenting with a bunch of hardware.

[00:09:09]We haven't deployed any of it yet, but yeah, coming soon hopefully.

[00:09:13]>> My desk is trashed by my CTO. [laughter] >> My CTO's trashed my desk, but uh for for I I'm happy to sacrifice that for the company. [laughter] >> Yeah. Yeah.

[00:09:23]>> All right. Very interesting. Uh this is a a fairly hard problem to solve like this like generally anything at the inlay is hard plus you know the kind of innovations that you guys are doing. So we'd love to know how you guys hire and how big is the team right now specifically engineering.

[00:09:36]>> Yeah, so we're are four people, three three co-founders and our fourth engineer, very good very very good engineer who's like fixing some issues now as we speak.

[00:09:48]>> Um and yeah, we we will be growing the team but I think we will probably still be growing very slowly. uh unless we go fully on prem then we would need like a different type of engineers that is yeah not not fully like software or soft skills. I think the world is changing there in terms of like how fast you really need to hire.

[00:10:10]>> Makes sense. Got it. And when do you do hire or this specific guy that you've hired? What does the interview process look like? How do you find people?

[00:10:17]>> Yeah, I think our interview process is very simple. Um so when assuming we we are looking for a candidate we usually our our process is like I think it's one stage only we have like each one of us founders has like a conversation with the candidate um and then we give them a score of like one to four on like tech and culture and based on the scores we just decide like higher or no higher.

[00:10:42]It's probably needs to be like a strong four. If there's a three, it's probably like a maybe, but like a four by the three founders uh would mean a hire. Unless someone like one of the co-founders feels very strongly about the candidate, then maybe we could reconsider. But yeah, it's um that's basically it to be honest.

[00:11:02]>> As we've talked about before, uh you you guys mentioned you're much different from you know a bunch of other providers, but this is a competitive space. So would love to understand the GTM for this you know how I'm assuming there two types of customers. one who's already on a different, you know, platform that needs to move and a fresh customer. How do you look at this and, you know, who's growing this?

[00:11:19]>> I think one thing, right, like especially early on, um, I think a lot of startups, like a lot of like series BC, CD startups have personality hires.

[00:11:28]Like you you hire someone because they're nice people. They're like I think there's there's there's this thing about, hey, this thing is novel. This thing is new. I want to use this new tool. um a large chunk of the YC startups right now are using open computer just because they're curious right that curiosity element exists but you can't bank on a business being built on curiosity so we are getting a large chunk of usage from that and we're overwhelmed by that right now so let's let me caveat my answer with that but outside of that we do a whole lot of outbound so we do a bunch of outbound we write content like day before yesterday we were on the front page of hacker news um I think Eigor is one of our best sort of he's he he writes long blogs he has a way of also recording ing himself writing and then he says see me type and there's a video with every blog so that if anybody insinuates that it's AI generated we share a loom like it's it's [clears throat] interesting yeah he has an interesting pattern but like um content has been getting us a bunch of inbound uh we're writing it especially about like there's very specific problems that the user cares about right like the more we speak about the problem the more users trust us about the solution um and like there's there's interesting problems in sense that like do you put harness inside computer or do you separate harness from comput like the labs are saying you need to separate it But like between right and easy people tend to use easy not right right like that's that's how an engineer thinks most times. Um so we we write we write a lot about the problem and how we are thinking about the problem and people self-filter almost like 80% of what we get is inbound and like there's a lot of outbound we do which informs discovery. We don't really we also speak to users of other other platforms.

[00:13:00]There's specific weaknesses that each platform has and strengths too. Like just like us, we have strengths and weaknesses like we're great for a few to few sort of agents. We're not great for some, right? Um so yeah, if I I think that's sort of our process right now. We also do a lot of growth hacks here and there. Sometimes ads, sometimes like we send cakes to people. Uh so like there's there's there's that happening too. But >> that and curiosity we can't bank on as a repeatable channel. Uh outbound and content we can. I think um we just do that as much as we can. But that's that's our little strategy I guess.

[00:13:31]>> Makes sense. Uh got it. You mention uh you mentioned persistence and longer running tasks, right? Uh so would love to know when you say persistence, do you mean you know across um start? So can I start a sandbox, stop it and then restart it and you know the file system will still be retained. If yes, how are you guys you know figuring this out technically? Uh because from the ones that I've used until this point um the only way to do persistence is to do it in house. So you export your file system somewhere and then you know you import it whenever you restart the sandbox. Uh is this like a primitive by default in open computer?

[00:14:01]>> Yeah. So basically that's one of the things we're banking on is that the first thing we did is we said there is no like timeouts when you start a sandbox in open computer. So it's the same way you start an EC2 and you come back a year later you imagine it's there. It's very much um a similar process here. So you you reserve those four cores for yourself for as long as you need them. And um you have the option so if you want to save cost you have the option to hibernate but hibernate manually >> and then start it again. And the hibernation in this case is like full memory snapshot plus disk. So if you had like a game running in the sandbox and you hibernated and then you restart it, it will probably still be running. Um the other thing we do in order to like obviously capacity is limited right. Um so this is the reason why we chose um KO hypervisor is it because it can like migrate workloads between VMs uh while the while the VM is running. And so like say say we have two 64 core machines and one of them is like at capacity and you decide to like scale up or we don't have any capacity, we can like choose to like move some of the smaller ones and pack more of them in the small v in the in the other VM and then make room for like a larger VM like a 32 gig to come in. Um, and I think under the hood, AWS, GCP, Azure, they do this process all the time where it's just transparent for you.

[00:15:35]>> So, we're like almost rebuilding EC2 at this point. Uh, but you know, more having more tricks to make it like faster to start and easier to like use.

[00:15:46]>> Makes sense. You mentioned you're on Azure and a bunch of other cloud providers, right? Uh do they have like hypervisor offerings or are you building on top of that, you know? uh >> so a lot of them so the only thing that matters for sandboxing in this way for any sandbox provider is the exposure of KVM >> and that can be either like through bare metal instances that they provide or it could be through nested uh virtualization so they they exposure through nested so AWS Azure Azure I think they're more on the nested camp GCP also I think they do nested AWS you can have >> [snorts] >> um you could have bare metal actually let me correct so you can do metal on all and some of these clouds can do like nested KVM support um there's a small like performance hit if you do nested KVM but it's almost negligible uh the interesting thing about bare metal is you're literally like you're not there's nothing between you and the actual host and so one of the challenges there is like for example what I learned recently is there's no guarantees that against the host failure. So for example, if you're you have a metal host on AWS and it dies, you're actually your data is basically gone. So like we have to make sure that you know the data is backed up and then this at this layer it's kind of like we might as well like have our own instances [laughter] which is like why we're really considering it.

[00:17:17]>> Cool. And you also mentioned you guys are open source right? Uh so if people want to contribute uh generally for you know eventually a hiring pipeline or you know generally to learn how these things work under the hood is the whole product open source by the way.

[00:17:27]>> Uh yes so we're also like have offerings for self-hosting. So it's on digger hq/opencomputer is our repo and we welcome all contributions there and yeah it's fully open source fully self-hostable on any cloud.

[00:17:44]>> Got it.

[00:17:45]>> And it's a project 2.0 licensed so yeah >> cool. So, if you guys do want to check out the codebase, feel free to do start the repo. With that, thank you guys for coming on.

[00:17:53]>> Thank you so much. Thank you so much.

[00:17:55]We'll see you guys in the next one.