dbmikus

Congrats on the launch! Seems like a great time this type of thing, with all the new robotics, chips, etc companies coming out

I don't know too much about hardware simulation. How much of the simulation is deterministic, versus probabilistic or ML based?

haha hey! this was your story

OpenCloud --> ButtButt

Funny story: I worked at a company where someone had the Chrome extension that replaced "cloud" with "butt". They were editing one of the company's docs pages, and when they hit "save" it swapped "cloud" to "butt" everywhere in the page.

They didn't notice right away, because the "butt" translation didn't run on WYSIWYG preview, so everything looked fine.

I love homelab stuff and self-hosting. Writing software is my job, but tinkering with computers + devops is my hobby

I have a media server I run on a spare desktop, and at one point was messing around with https://syncthing.net/ for a self-hosted form of Dropbox. More recently, I'm using a VPS to run some internet scraping jobs for things I want to monitor, like apartment listings in NYC (where I live).

Of course, I also use this to run long-running cloud coding agents! Basically exactly what DHH's AI shed is. You need something stronger than $5-$10 / month VPS. I connect with https://herdr.dev/ for persistence

Because of how relevant the "AI shed" concept is, I would be remiss to mention my startup: https://www.amika.dev/

Amika lets you turn any computer into an always-on, network-connectable, AI shed. It's not ready for primetime quite yet (beta launching soon), but I use it for all my dev work

It's partially open source, which is here: https://github.com/gofixpoint/amika

I agree in using a separate OS-level sandbox or a VM. Better to have the option for modularity.

However, for ease of use, it is nice for harnesses to by default run with sane and safe sandboxing setup. Then give the option to disable them.

You ship an operating system with the correct defaults, where agent processes run like this by default. You don't require every user to configure it correctly themselves

I don't know why it's taken as a given that we can't design a hypervisor that is secure.

Cursory research with AI says

> ~3 clearly documented, publicly demonstrated full escapes directly through KVM kernel code over roughly 15+ years of widespread KVM deployment

Surely, there are more, but we could formally verify the correctness of the entire codebase, with the help of AI.

Then we'd have "jails" that work, as long as you don't connect them to the internet.

If you had a super smart AI, you could then totally airgap it if you wanted to.

Networking opens up a can of worms and there won't be zero vulnerabilities, but we can design safer software.

I think the operating system itself has to adjust so each "agentic process" can run inside its own jail, which is a VM + files in the VM + ingress/egress rules for the network and filesystem data

These cloud agents work as cloud infra, but we're kind of in the mainframe era, before personal computing. Personal OS for agents is somewhere in the future!

And an interesting extension of that idea: if an agent runs inside a microVM, can you have that VM transparently run on another host? Maybe we'll get for-real distributed and networked operating systems

Agree!

Ultimately, we need better "jails" for agent processes, but the system primitives should be flexible in what can be exposed across jails. Or you could run multiple agents in the same jail if you want them to have unrestricted interaction with each other.

You don't need to do this on a cloud, you can get the same type of VM and network jail running on your own computer. The important parts are:

    1. a VMM hypervisor
    2. a network proxy / gateway

Use your favorite VMM / hypervisor (likbrun, smolvm, microsandbox, etc). They give you control over the network interface or let you inject your own network layer.

The network proxy can handle all the ingress/egress rules, credential injection, etc.

It's still not user friendly to do all this. I think the next version of operating systems will have each "agentic process" be a bundle of VM, files in the VM, and network rules.

Been brainstorming[1] a lot of this because I've been building some open core tools[2] for spinning up sandboxed agents on arbitrary computers. There's a lot of glue and parts to stitch together to work smoothly. Don't think we've had the "Docker moment" for this, let alone the "Dropbox moment" that makes this stuff work for non-devs.

[1]: https://github.com/gofixpoint/amika/blob/main/ROADMAP.md

[2]: https://github.com/gofixpoint/amika/

For my example where I modify both the OSS and private repos, I sometimes have one agent coordinate both changes (maybe with subagents), or if the work is modular and separate, I have disjoint agents do the work separately.

That said, most of the time, I only want an agent to work in one repo. I could give it multiple repos at once and instruct it to work in just one, but that risks it forgetting my instructions and it can load more context into the agent's window.

I think my main point was to have flexibility about the topology of VMs, repos, and agents.

Restoring memory is useful if, when you resume an agent VM, you want the apps to be in the exact state when they were suspended.

But for most things, I find resuming with memory is more trouble than it's worth. If you always resume from memory, you lose the ability to control the state of a VM. It's much easier to define which services should run than to define which active RAM state should be purged

Similar to why "did you try turning it on and off again?" is good for system reliability.

Not sure about billions, but companies doing evals or RL or training will create really big bursty agent workloads. I think they are the best fit for AX, as opposed to individual dev teams building software, etc.

I think it will be, but I don't think you need a standalone machine! If you run things inside a VM, you can get safety and control over access and networks

A standalone machine is nice if you need more compute resources or if you want an always-on machine you can connect to from your laptop, phone, etc.

It doesn't look like Google's AX is quite the plug-and-play fit for running agents on a computer you own, since it requires setting up a K8S cluster, etc.

I think what's needed is something like a zero-setup combo of Tailscale and Firecracker

I'm trying to work towards that with my startup (https://github.com/gofixpoint/amika) but the bring-your-own-computer part doesn't work quite yet.

I'm working on something in the "cloud VMs for agents" space[1], so I have some battle scars and opinions!

IMO, you want the flexibility to create either: (a) permanent devbox VMs, and (b) per-task VMs

Agent sandbox platforms tend to be tuned for the latter, which sometimes involves VMM hackery for fast boot, snapshotting VM filesystem and RAM, etc.

Some workflows are a lot simpler if the multiple agents share a VM. These are workflows where agents must share state. A simple one we have: making related changes in our public OSS repo and our private repo, and then testing the change.

And other times you want to split up the tasks onto isolated VMs so they don't interfere with each other (ie run two dev servers without database or port collisions).

I tweeted a bit about this (https://x.com/dbmikus/status/2099264325231771878) and had a little debate with folks about ephemeral vs persistent VMs for agents

[1]: https://github.com/gofixpoint/amika

Now that is one vibe-coded website

If you need xcode or macOS specific stuff, our VMs are all currently Linux based

We're working on a "bring your own computer" feature which lets you take a spare Mac and slice it up into devbox VMs you can access from the cloud.

We could also integrate https://limrun.com/ as a simulator for xcode, etc on top of Amika VMs

Thanks! Have definitely appreciated your feedback as a user

That's a good point!

Pretty close, but IMO not quite. A math proof in and of itself is useless unless either:

   (A) it furthers human knowledge
   (B) it gets used in applied sciences, engineering, etc.

If you merge and deploy code, you have released a tool that can be used. If you ship a gibberish math proof, it's not useful unless someone else can understand and deploy it to some other means. Now, it's possible AI could understand and make use of the math proofs, even if we can't, which refutes some of my hair splitting :)

An AI-generated solution always provides two pieces of info:

    1. proof that there is a solution
    2. a solution that you can work backwards from to build understanding

Maybe the solution is pretty inscrutable, but it's almost always better than nothing.

So, both of these pieces of info would be at least marginally useful for advancing human knowledge.

That is close to the average rate of inflation, though. Doesn't seem unreasonable to me.

> I'd love to have exe.dev, but running on my Mac Mini.

I'm working on exactly this bit (with some more tuning for messaging AI agents)

https://github.com/gofixpoint/amika

Doesn't run on your Mac Mini yet, but should get that enabled either this week or next

If you sign up (free) I'll send you an email when the "Mac Mini mode + full OSS self-hosting" is live

I haven't paid super close attention to Orbs, but I also build an agent runtime + orchestration layer on top of remote VMs (https://github.com/gofixpoint/amika). I do think it's smart marketing to name the concept. And for coding agents, there's a lot of annoying fiddly stuff you have to do to get the experience to work well:

    1. auto-refresh base VM snapshots with latest delta of git commit changes
    2. extend the VM lifetime when it receives an interaction (chat, HTTP request, etc.) and sleep it when inactive
    3. oauth refresh of MCP servers, coding agent subscriptions, etc.
    4. support inter-VM and communication for agents and exec commands
    5. keeping track of agent work across VMs

That said, I think it's important to not hide the VM and computer from the agents. The user should have total control to put 1 or more agents on a VM, to make VMs ephemeral or permanent, to manage the network access of VMs, etc. It's basically a networking + VM scheduling problem, for which there's a ton of prior art since the 90s (or earlier).

A few examples:

Many remote agents products have a "one agent per VM" restriction, but it's better to have N agents across M VMs. For example, I have agents work on a singular VM in parallel worktrees and then stack the worktrees at the end on that VM for the final change.

Just give me OpenSSH with normal SSH key management. Lets you manage VM access the same way we've done it since the 90s.

Connect VMs in a network topology: we build our VM/agent scheduling + remote control product inside itself, so we often test interactions between user, control plane, and sandbox(es). If you can directly control VM creation and lifecycle, it's easy to spin this structure up and let agents work across it.

I should be able to use whichever coding agents I want, connected to the VM. Whether that's OpenCode or Pi Web in the browser, or loading the VM into Cursor or Codex app, or using the TUI or sending messages to agent(s) via API.

For a truly "handoff-able" session, you also need to store the data it was working on. In most cases, these are the git patches

I'm working on this at my startup, amika.dev

Open core is here: https://github.com/gofixpoint/amika

We're designing it like a meta-harness actually. The goal is to let users put any agent(s) (Claude, Codex, Pi, OpenCode) on a sandbox on any computer (local, K8S pod, cloud VPS, sandbox provider, etc.)

And then be able to interact with the agent(s) from anywhere: terminal, phone, web, or load them into the Codex, Claude, or Cursor apps

Under the hood, I think of part of our tech like mashing together Tailscale and Firecracker.

The edges are rough right now, but if you kick the tires, I appreciate any feedback! (my email is [email protected])

And besides what we're building, there are cool projects like Amp Orbs, YC's QM harness, etc.

Big enterprises are on a different github deployment, so I doubt they are affected by this

Agreed! I think the best user experience is:

    1. You can run sandboxes locally
    2. You can control them securely over the internet, for when you're on the go
    3. You can migrate them to cloud VMs if you want

If I can toot my own horn, I'm trying to build that :)

Still early and the local sandboxes are experimental right now

https://github.com/gofixpoint/amika

What's your problem with the OpenCode config?

My startup (https://github.com/gofixpoint/amika) copies agent configs into local or cloud sandboxes

We run OpenCode currently, but need to improve the setup for users, so would like understand more of the issues you have sandboxing it, if you can share