⚡️Launching Ona: Coding Agent with Fully Sandboxed Cloud Environment

Welcome to a Latent Space Lightning pod. We are excited to work with, I guess, the former Gitpod team on, on Latent Space pod on their new products. You guys are... You know, you and I, uh, Chris and Johannes, you and you-- we've been sort of, uh, familiar over the, over the years, even before this AI wave with Gitpod, when, when I was trying to show off Temporal where, where I used to work, which is like kind of a complex open source distributed system.

The only system and platform that was possible, that was i-able to make it easy to spin up infrastructure, uh, of the, of the complexity that Temporal had was Gitpod. So thank you for working on it. But now you're working on a new thing.

So you got to, you got to know Gitpod YAML.

Gitpod YAML. That was, that was the, the, the joy of, uh, of, uh, infrastructure at the time. But no, you guys, you guys worked on really, really good sort of, uh, cont... Like, I always think of it as like containers plus plus, right?

Like containers stop at like the single, uh, single sort of node, and you need more networking and like Kubernetes has, has its own thing, but like really I needed something lighter weight and, and you, you guys solved a lot of those isolation, uh, and networking issues.

Yeah, you also need like for, for dev environments, I see that happening a lot. Like for dev environments, you also want a little bit more than containers, uh, because container really up to run applications and dev containers aren't your off-the-mill application, right?

Yeah. Yeah. So anyway, you guys are co-founders of Gitpod, but also now you're sort of renaming the company. Uh, why don't you guys introduce yourself and also what we're announcing today?

Cool. I can start. So my name is Johannes. I'm, uh, one of the co-founders and CEO of, um, Gitpod and soon Ona. I think we'll talk a lot about why that happened. Also a bit about our roots and then are excited to, to showcase you also what we've been building over the last month.

So really looking forward to talking today.

So my name is Chris. I'm one of the co-founders and, and CTO at Gitpod and well, soon Ona. Gotta get used to that. But, uh- Yeah, looking forward to this conversation.

It's three letters, Chris, so easy to remember.

I know. But it's years of, years of ingrained saying Gitpod, you know?

That is true.

Yeah, yeah. So what is Ona? What, what made you start working on it when Gitpod already, uh, you know, decently successful, raised a bunch of money and like had some traction, even dumb people like me could use it.

Great. So, like, wh-why Ona?

Yeah, I think let's take a step back and also go through a couple of phases I think that the company did. So when we started Gitpod, like more than five years ago right now, the idea was really to have this one-click experience to be beamed into what we call like a ready to, um, code development environment.

Initially with the browser-based IDE. So some, some of your listeners might know, but um, back in the day, um, VS Code could actually not run in a browser, right? And it was not yet, um, refactored to support remote development.

And because as we started, we really wanted to offer a VS Code-like developer experience. Our team specifically back then, Sven and Anton, um, they created Theia, which was, um, like a cloud IDE framework that is still used, um, um, heavily by Arm, Arduino, a couple of other, um, people under the Eclipse, um, Foundation.

So we created that, and together with that, we also created OpenVSX, which I think now powers all of the extensions that you see running in Cursor and also Windsurf, which is also open source under the Eclipse Foundation, a marketplace for VS Code extensions that is not hosted by Microsoft.

Together with those were some of the building blocks, then we had to build all of the orchestration in order to get it to build or to, um, ready to code experience. And I think that was until, let's say, end of 2022, I think the first phase of Gitpod, really this one-click web IDE running in your browser, winning hearts and minds also of developers.

We scaled through open source, have more than two million folks on the platform, um, by now, and I think that's also when, when we interacted with you, when you were still with Temporal. Since the end of 2022, we really embraced also enterprises.

So I think as a company, both culturally and from a product architecture, um, perspective, we really kind of shaped what we call cloud development environments, um, with a strong focus on some of the most like regulated companies on the planet.

So today our customers include, you know, the oldest bank in the US, top sovereign wealth funds. We have like pharma companies, um, a lot of financial institutions that are running our orchestration system to power those, um, fully configured dev environments that connect to on from databases to the registries, secret managers, everything in order for you to write software in, in, um, side of your, your VPC and then connect it to desktop IDEs.

So what happened is we as, as I think Copilot really started to become successful, we realized that if the future of agentic software development is going to happen, we didn't know back then, that was like end of 2022 or so 2023 when that will be the case.

But if that is going to happen, we have something that is very valuable, which is the fully configured environment. And at that point, we made already the decision that when we feel that coding agents have crossed the chasm, so are at a point where they efficiently can actually solve engineering tasks, we are going to fully embrace it.

And that was, I think, Chris, when did we start? End of last year. So when 3.5, so Sonnet 3.5 came out, it became clear that it will not be very far away. And then we started prototyping and, uh, developing our own software engineering agent on top of all of the primitives that we have built over the years.

And that turned out to be, um, a very great experience that like, um, in-internal engineers really used a lot and, um, we decided to fully embrace that. And with that also change then the company name to Ona to go all in into that, that future.

Very bold. Very bold. I, I think we can sort of pull it up on screen now. I always like to give people the sort of visual aid, uh, as well what we talked.

Yeah, I mean, just a quick, you know, wh- while we're putting it on screen, why, why did you have to rename the company? Like, why can't you just be like Ona by Gi- Gitpod, right? You know, like, what, what um, why so drastic?

I mean, so what we understood as we, we initially also thought about just naming the agent Ona. What we quickly understood is that it's a core part of the experience, and it's a core part of the platform. Those two things are not separate, right?

And, um, that is, that was ultimately then the driver of the decision to say, "Hey, um, let's, let's embrace that." Gitpod is also as a name very technical, so we kind of have outgrown that name to a certain extent.

Mm.

Like with Git and Pod, it's like it's a Kubernetes-based architecture. We, we, um, released a blog post a couple of months ago that was called We're Leaving Kubernetes. So it just did not really fit. So generally, you can say our ambition, product architecture, and also the value that we deliver to our customer has outgrown the core, you know, um, name of Gitpod.

Awesome. Uh, I think Chris has Ona up, so I'm just gonna let him drive a, a quick demo so we know what we're talking about. Okay, cool. So this is the, the raw unfiltered version. This is how I use Ona myself every day, and so that's exactly what, what you're seeing here.

Now, the hello world of Ona is essentially firing off an agent to do something for me and, you know, something very simple like what's in this repo. I, I don't do that every day. I know what's in our repo.

But you can then set it off on, you know, some code base that you want it to work on. You can also start from scratch, of course. But really the interesting piece here is that organizations typically have, you know, paved roads and known repositories, known projects, known dev environment setups, really standardized setups that they wanna work on.

Like, typically it's not a "nah, an agent is gonna figure it out," but there is compliance and, uh, platform team requirements around how your dev environment looks like. And so here I select this perfectly set curated setup. Okay, so I'm gonna fire that off.

And what happens now is, you know, we spin up a dev environment, which is the, has been the bread and butter of, of what we do for a very long time. And you see on the side the agent already engaging in that conversation.

And so while that's starting up, let me talk you through a bunch of ways I use Ona every day, and this is literally something that happened in a call earlier today where we were wondering if this... You see this inactivity timeout here?

And we were wondering if that inactivity timeout is still working well with the agent. And so while we were in that call, you know, I literally asked it a question, "Hey, it no longer seems to happen. Examine if this is true and if it isn't, why?"

Um, and it did a fine job at it. Very quickly gave me a detailed account of how this tracking works and that it's still in, in place and answered a question for me. And I didn't have to change my-- I didn't have to check out a different branch.

I didn't have to faff with Git worktree. All I did is I put that in a prompt box and, and it worked. You know, inquiring things like that is, is something that you can also do in other ways, you know, connect an MCP server to, to GitHub API or something like that.

Where it gets really interesting is when you wanna make changes, and you see there's a bunch of these conversations here that have changes in them, right? And so if, if I look at, uh, if I look at one, what I do a lot is I use Ona to prototype stuff.

So for example, here I'm, I'm looking into showing the, showing the, the numbers, like showing the, where we're at in the to-dos. You notice we track to-dos as the agent does its work, and I wanted to show them here on the side.

And so I ended up building a prototype for this, and that too is entirely conversation driven, you know. I have as I walk it through and, and talk to it, and I can do that without, again, needing to change any state.

I can do this in parallel to getting actual work done. And that's how my day-to-day actually looks like. I typically do one or two prototypes on the side. In a call we'll run inquiries or ask how things are actually working, and then also work on some light feature stuff alongside, and I can do all of that in parallel.

So if we look over here, you can also very easily track the, the state of your changes. And if I need to go deeper and wanna see how these changes look like, I can pop into VS Code right here.

You know, it's one click, and I'm, I'm right there and then in VS Code and, you know, this is true VS Code running in the web. If I need to go even deeper than that, I can open this in a, in an actual editor, uh, on my desktop.

You know, I, I can pop into Cursor or VS Code or any of the other editors that, that we support. So I'm gonna pause there. Like this is the, the he- the core of it really is the parallelization, this ability to run so many things at the same time without needing to, you know, maintain any of that state and well knowing that the dev environment is perfectly set up for how it needs to be.

And, you know, f- for a weekend warrior where the setting it up on, setting up the dev environment might not feel like much, but, you know, if you're working a bit of Python here and a bit of Go over here and a bit of TypeScript over there, it already becomes a handful.

If you're working at a, any decent sized shop, let alone an enterprise, the way you set up your dev environment is really ha- at the heart of all of this. And of course, you want your agents to work in exactly the same space that you as a human can operate in, um, and you want that parallelism, and this is what that platform gives you.

Yeah, amazing. What was the hardest part of the, you know, this exploration? Anything that you struggled with like figuring out in terms of like putting the agent together?

So I think one of the big ones is, is the user experience and a lot of the design decisions around, you know, is there a one-to-one mapping between environment and conversation or do you have multiple conversations in an environment and how do people think about that?

And this is something that will clearly evolve, but making that accessible not only to the really plugged in one percent that is listening to this podcast or folks who really know their stuff, but also to maybe the more AI-skeptical or the ones who think that tap, tap autocomplete as of today is the pinnacle of, you know, AI-based writing, writing code.

And making these decisions... Sorry, there's a camera popping in here. Making these decisions, making this really accessible, I think has been one of the challenges.

Yeah, I mean, I think that's always a challenge for all the agent builders I talk to. One thing I realized that may not be super obvious is that, you know, you're, you're showing a demo here that is, uh, very front-end oriented.

I wonder if you had decisions on front-end versus back-end workload. I kind of see Gitpod as obviously more infrastructure, more back-endy, and obviously you're more capable of, of back-end intensive things as compared to something like Bolt, who we've had on the podcast before, where they use web containers, so it, it's very, very sort of tuned to, to front end, right?

Both are capable of front end and back end. It's just like I, I expected some kind of lean. Oh, you, you showed me some Go code base.

I think one thing that is very important to, to mention, what Chris showed here is our own product. So the whole product that you're seeing, we are building with Ona. So I think last week we had seventy-five percent of all of our PRs being co-authored by Ona.

So we're heavily dogfooding. So all the environments that Chris just has showed are or have the whole platform with its front end, with its back end, the whole orchestration platform, um, running inside of them. And I think that is, as you, as you mentioned, huge difference from, from folks like Bolt who use web containers, um, is that everything that runs on Linux runs on Ona.

And, um, our customers, as Chris also alluded to, are oftentimes the ninety-nine percent of developers, um, and we have to support a huge spread and, uh, variance of different workloads and everything, again, that runs on Linux runs on the platform.

Chris, maybe it's helpful if you show a bit the how the environment automation is set up from the dev container and the automations YAML file, which I think is one of the very, very hard things in order to get this running in production, both as our customers, but in general, is that you create those very reproducible environments.

Let me, let me show that. Like, this is also why I went back out of code. Like, you see these services here, you know, I c- I can run our, our back end right, right there and then. Most of the work that we do, like I, I showed some front end stuff, but most of the work we do is, is back end.

Fundamentally, it's a lot of infrastructure stuff. You see the Go code. All this is also written obviously within Ona, and at the heart of it is, is a dev container, is a dev container JSON that contains the, the version of-- defines the version of Go.

It, it comes down to a Docker file at the end. Um, okay, don't find... There we go. Dev container Docker file. There we go. It comes down to, to a Docker file at the end and which, you know, itself isn't a, like, Docker itself isn't a security boundary.

You don't wanna be relying on that, but for specifying the tools that, that you need, Docker is, is, is a decent way to doing that, or dev container is a decent way of doing that. And then on top of that, we built what we call automations.

Sorry, Gitpod. That's one of the reasons we're renaming. No more GitHub and Gitpod conflation. Can't wait-

Yeah

...for this. There is, there's an automations YAML, uh, file which also gives you these services that I showed earlier, right? Like here there is a, there's a back end that you can run, and here's the definition of what it takes to actually run that, run that back end, and then also commonly run task.

And all of this is, of course, also available to agents. You know, like this stuff has been very useful for humans because it takes an outdated README file and makes it into s- turns it into something machine executable that it can actually automate and, uh, you see there, there are triggers here also where we, where we trigger things on post dev container style and stuff like that.

And all of this now becomes also input and context that, that helps the agent navigate your dev environment.

Yeah. Yeah. Wow. Um, okay. Uh, d- how, how good is, uh, our LLMs at speaking your YAML, by the way? I'm just kinda curious 'cause you, you made the cutoff, right? Like, uh, I think actually right now it's kind of a golden age of, um, pre-LLM era infrastructure companies because all your tooling is like-

Yes

...inside the training data and like people who started it afterwards is not.

We did make the cutoff. It's, it's really decent generating the, the dev container, uh, the, the automations YAML. And then obviously like, you know, the moment you do that within one of these environments, it can also try it out.

We didn't even have to give it tools. We just told it, "Here's the CLI, go knock yourself out."

Yeah. Is there anything that it, that it cannot do or you warn people not to, not to do? You know, like what, what is like within, well within normal capabilities and what is flakier, like in your experience?

So I think we're seeing the very similar problems that, that a lot of other folks are seeing where, um, so- some prompting, some input is reasonably naive, so the underspecification problem we, we also see a lot with, uh, especially people who come to this for the first time.

And the second is the decomposition p-piece. You know, if you give it sort of a vaguely specified too large task, it's gonna go astray, much like it would with, with any other agent. The advice that we generally people, uh, give to people is like start small and work your way up.

Learn how to decompose, learn how to really be excessively specific about what you want. Don't make assumptions necessarily, and that, that gets folks quite far. So there is a learning curve we find. You know, it's not- I mean, the au- the audience will also know that, of course, like this isn't some magic fairy dust that you just give some...

It can't read your mind, you know. You have to specify what you want and this is part of the challenge also in building this product of how you educate folks who sit in front of that prompt box.

Yeah, totally. Uh, w-what is, what is other challenges, I guess? Like, people always talk about, like memory. Do you talk about like which mo-model you're using, any discoveries from like using GPT-5 versus Claude 4, you know, anything like that?

Yeah. So we right now, um, essentially live on top of Sonnet 4 and, uh, we've tried a bunch of other models. We found that to work really, really well for us. The, uh, like one of the, the trickier parts to get right actually was file edits, surprisingly.

Like the-

Yeah

... you know, we, we tried different iterations. We tried to come up with our own. We started very simple and we're like, you know, "Here, produce diff, we're gonna apply diff." That didn't go very far. We tried to tell it, "Use sed to make edits," and then had a lot of, um, problems with it getting backslashes wrong and we tried essentially a fork of Cline's applyEdit tool for a long time and at this point we've landed at, uh, essentially Anthropic's standard re- uh, string replace built-in tool and that's working decent, but it's obviously model specific and, you know, so at the moment we, uh, like for the other models that, that we support, we will need to find something else.

But file edit

didn't know, but it's really, really hard and it's very much at the heart of it. Like if that fails, your agent's gonna go astray and burn tokens for no good reason very quickly.

Yeah, I mean, I, I think it's, uh, we've covered this in our podcast a couple of times and I think both Anthropic and OpenAI have open sourced their, the way that they do file edits-

Yes

... and it's kind of a, a research topic. But I didn't expect it to be that much of an unsolved issue. I haven't tried to do this myself, but it seems to be like something that's, that's, uh, every lab is, is coming to deal with and obviously we'll post train for.

The other thing I'll mention here is MorphLM, which apparently is, uh, focusing on just file editing, like the, the, they do the sort of the, the fast edit company. Okay, cool.

Especially doing that for larger files is really interesting. You know, like doing that for 100 lines, no problem, but almost sorry to say, like the largest te- Go... It's a test file actually. The largest Go file we have is about 8K lines and, you know, adding a test case in there is really a challenge.

Yeah. Um, so one thing that always comes up with like all this conversation about like coding agents is pricing model. Obviously you guys are enterprise-y business, so in, in some, in some ways you already have a, a, you know, a lot of large, uh, contracts anyway.

How are you thinking about pricing for Ona?

Yeah, so I think they're really, you know, um, on the, on the enterprise side, how we always also have differentiated is that we can deploy inside of the VPC of our customers, which is a requirement. So Ona is powered by a runner-based architecture where we can deploy in various, you know, infrastructure and compute destinations.

And so we run inside of the network of our customers, which gives us more flexibility where we can connect also to their like Bedrock and Vertex instances inside of the enterprise. So there we have, we have, we have high pricing flexibility.

On the self-serve side, which we are also, um, launching, so when this podcast is out you can just go to ona.com and try this for yourself. In September, you will get $100 in credits if you upgrade to the core, um, tier, so that will be made available for you to try that out.

And here we follow a credit model where we blend a bit the compute and, and token usage. Generally our, um, we are really f- we're not in the inference game, right? And I think the value that we provide, which is important, we want to price on the value that our platform provides, is really in the sandbox isolation, the connectivity, so that you have access to everything you need in order to write professional software.

It's in the parallelization, it's in the autonomy that you get, it's in the editing experience. I think Chris quickly showed that, but having VS Code in the browser, this is a native and full func- like fully working, um, VS Code version that I think gives us a very nice blend where you don't need to access your desktop IDE, but you can get a lot of things done in VS Code in the browser.

And if you want to transition, there is a one-click opportunity as well for you to do that, to continue to work in Cursor, in VS Code, in JetBrains, whatever IDE and desktop IDE you prefer. And the mobile experience is also something we have, we have really optimized for.

So all of that is ultimately what we will, what we-

Yeah, I think, uh, that, that is reassuring to hear, right? Like that, that you're not in sort of the, uh, the sort of inference, uh, subsidy game or whatever. It's a, a lot of the conversation recently has been like what people have been calling Cursor, the Cursor problem.

Yeah.

I don't know if it's a problem. They, they seem to be doing fine, but like at some point you have to make the finances work.

Yeah. I think if you look from a business model perspective on this, I think at least right now we are not planning to build our own models. I think ultimately that's a way out, you know, if you also are building your own models.

We're not doing that. We are really betting on the frontier labs who are focused on coding, um, um.

Yeah. Awesome. Um, and, uh, you know, I think this calls back a little bit, you know, the, the whole VS Code in the browser thing to the end of localhost post that I, that I wrote that I know you guys saw.

Like I guess like will we ever stop using IDEs? You know, like right now you have the, you know, pop out to Cursor button, pop out to whatever, uh, VS Code. I can kind of tell that you kind of don't want them to do that.

It's like, okay fine, you're so married to your IDE, like fine, go ahead. But like really, do we need it? I don't know. I will steel man the argument for why people love, love their IDEs. They-- We have much more powerful local machines than we have in the cloud.

I rent my Linux box from you. Like, I have only so much memory, I have only so much whatever, and like you, you shut it down it, so there's like a cold start and all that. Uh, I open up my laptop.

It's a super powerful machine that's like M4 Mac or whatever, and it's, and it's always warm because I'm on it. So, you know, like, how does this work? How does, how does, how does the IDE go away, the local IDE?

It's interesting. I think the, um, the m- reason... I think there are two main reasons why folks really love their IDE. One, we're all creatures of habit. Like, this has been conditioned for 30 years. We've been writing software like this for decades.

You know, there's a long tail in that change for sure. Like, just changing the habit alone is gonna take a long time, and it shows in the way, you know, folks have set up their key bindings and really made it their home.

The second is, I think the way you work, like the, the way you write code influences the tool you wanna use. And so as long as you're writing code in this deep mono-focused work where you're doing one thing at a time, an IDE is a good tool.

It, it is built for that. And we've spent de- again, decades optimizing this one particular way of working. What's changing with agents is as they gain more and more autonomy, we'll be asked to turn this autonomy into productivity, and the only way we can do that is by doing multiple things in parallel, as we've shown.

And the moment you do multiple things in parallel, IDEs really aren't the way. They're not built for this. It's cognitive overload. If you try and Alt+Tab between a bunch of Cursor windows, good luck to you. You know, you're not gonna have a good time.

So we will need new interfaces that help make this parallel work-

Yeah

... not only easy, but highly enjoyable. You know, how do you get into flow when you're doing five things in parallel? It's a question that, that we need to answer. And I think this is actually the thing that's gonna drive people, that's gonna fundamentally change how we think of an IDE.

We might still use the term, but, you know, give it, give it... I don't know, I don't wanna say a time here, but, like, give it some time. I, I do think we'll, we'll... the interfaces will change, not because we move away from compute to a different form of compute so much, but because we move away from a way of working.

You know, we'll move away from this mono-focused work to some parallel track working.

And I think one point what is very important to us when we designed this from also product point of view is that we give people choice. So I would actually disagree that we don't want people to click that button.

Over time, more and more people should not do that because they get, um, value out of it. But we always want to give, um, engineers the choice. And I think as habits change, as workflows, um, change, whatever interface works for you, you should use.

If that is a conversational interface that Chris showed, great. If you can get so far with the agent, amazing. If you need this like hybrid, you know, native VS Code in the browser interface to make a couple of quick edits or review, great as well.

And then if you want to go to focus mode and like work on a specific task where you need, I don't know, Cursor's tab, tab, tab, which is like an amazing feature, or your full JetBrains functionality, go. Do that, right?

So I think it really will depend, at least as we are in th- this like transitionary phase over the next years, what's the task at hand? And for each task at hand, we want to build a platform that gives developers the tools in order to get that task done.

One, one mental model, like we all seem to like, uh, car mental models. Like we, we spoke about the time between disengagement at some point, and one, one mental model I have in my mind is like, as long as you work with agents, as long as you go the long distance, it's a bit like highway driving.

You know, you're making miles and miles and miles. You're getting a lot of stuff done. And then the moment you, you go into the city, you need... You know, your driving changes. You need more... You need to pay more attention to more details.

More things happen, and so you, you maybe wanna pull in this IDE on the side. If you're driving, if you're driving a car race, you know, the moment you go on a racetrack, you need a very specialized tool.

You need to be extremely focused, and then you need a race car to do it, and then you're in an IDE. Do you go shopping with your race car? Absolutely not. Do you, do you haul stuff across country apps with a race car?

Absolutely not. So th- that's the right tool for the job, and I think this is also how things are gonna shift over time.

Yeah. I, I definitely think so. It's weird. It's a, it's a such a interesting, twisting journey through all this, but I, I think like you guys are, uh, definitely at the forefront of like designing that shift up in terms of like the, the, the sort of power tools.

I think the other, the other thought I always have, uh, with this stuff is, uh, the other direction, which is in- going into production. Um, you know, you have like pseudo production infrastructure anyway.

Mm-hmm. Yep.

You know, maybe people at the highest scale really need to scale up. But for a lot of people, especially a lot of like vibe-coded apps, like development is all you need. Can I run my like, you know, internal apps on like, you know, my own, uh, vibe-coded app, right?

Like maybe, maybe that's enough.

You definitely have the, you have the choice for sure. So there's an SDK available for the entire platform, and if within your domain you choose to adopt Ona this way, you can. You know, y- you can use it to, to spin up a machine.

We're very, we're very dev focused, so we're really intensely obsessed about developers doing their thing, and right now are really focused hard to sort of, what we say, left of the commit. But it doesn't have to... Or left of, left of it going to production at this point.

But it doesn't have to be this way. Like you, you can use this platform. There's a lot of versatility in it. For our own focus, we're really focused on, on the developer's experience.

Exactly what Chris said. I think like it's professional engineers right now. We really want to build like a professional editing, um, experience here or general, um, agentic experience. And then let's see. I think there will be a lot of change over the next years coming, and, uh, we've played around with, with that idea going more to the right in the past.

So let's see. Definitely we have the infrastructure in place.

Yeah. I, I mean, I think like the... I would have normally said that, and then, you know, Bolt and Lovable came up and, you know, they're making like $140 million in like, in a year and like... You know, at some point that's real money.

Yeah.

Okay, cool.

We have a 90% margin though right now on, on our enterprise offering, so-

Yeah

... that's also real money.

Better than minus whatever margin that, uh, those guys have. Okay, cool. Uh, yeah. Great. Congrats on your launch. I'm excited to try it out myself, uh, and give feedback. And, uh-

Please do

... what other, any other calls to action that you guys have? I think Johannes already sort of- ... spilled the beans on like self-serve, you know, you get $100, but anything else that you want people to try? Like what's a, what's a good first thing that you, you encourage people to try?

So go to, go to Ona, go through the onboarding. We curated some of the use cases to, to get you off the ground, and really play with it, use it. It's, it's definitely changed the way I work. It also works well on mobile.

I don't think we, we've touched on that enough. Like, I'll share that. I, I have a three months old son, and so I spend a lot of nights sitting on a sofa with a son on one hand and, uh, like him sleeping and a phone in the other.

And, you know, I'll, I'll get a lot of stuff done. The way I said that to my team at some point is, "You know, I'm now three times more productive on my phone than I was on my laptop six months ago."

It's, it's crazy how much that shifts and because it's the same environment on my phone as it is on my desktop, you know, I have a seamless transition. I come into this the next morning and my prototype's still there, my change is still there, and it's the exact same environment that I can continue from, and that, that's incredibly powerful.

Yeah, I agree with that. We've seen a lot of folks using it also with their iPad. Gives you a bit of more estate and then I think like VS Code in the browser also, um, really, really shines. But try it out, give it a, give it, give it a shot.

Um, all of those environments are fully sandboxed because of the, because of our underlying infrastructure, so give them autonomy. I think that would be really our advice. You can run a couple of them in parallel, like let them do their job.

You do not need a dangerously skip permission flag here. Like that is by default not-

Ooh

... not, not, not, not existing because it doesn't run on your local machine. So that is totally like we love, we love, we love what, what folks are, are doing there. But we have isolated every environment so you can just give more autonomy to, to, to folks and are by default in Yolo mode essentially.

Yeah. Uh, you just made me realize I can actually run Cloud Code inside of Ona so I can have-

Of course

... like two agents.

Yeah.

And we can-

But also the-

... recommend that as well if you want that.

The other thing is as well is like it's not dangerous to skip permissions, right? So you actually, you can just remove dangerous because it's not dangerous. You can throw away environments, which is very helpful.

Mistakes become risk-free in a way, you know? So you can throw away. They're, they're ephemeral, those environments.

It's the default that, you know, the, the agent by default is allowed to do anything and everything, and then also as an enterprise customer, you might still not want that. You might have compliance reasons why you don't want that.

So there's a deny list. You can say, "I don't want you to run X," and we're going, we're going deeper and deeper also in the system to make that happen because you tell an agent it can't run a command, it's gonna write a script to run the command.

And so the, uh, we're going deeper and deeper to also make sure that that deny list is true. But by default will open.

Great. Yeah. Great. Uh, well, you know, I've, I've already probably run over time a little bit, but thank you so much for jumping on and sharing and congrats and everyone should go try it.

Amazing. Love to hear the feedback. Thank you, Sean.

Thank you.