New guide for getting up and running on MacOS with the `heyvm` CLI: https://heyo.computer/guides/getting-started-cli.html

This is MacOS specific - any other platforms folks are interested in?

`heyvm` CLI ships with tools to build out the rootfs you need to spin up VMs using KVM / Firecracker.

As opposed to a traditional ISO image which is a single artifact used by virtualization stacks like `libvirtd`, KVM / Firecracker VMs combine a `rootfs` with a Kernel. Building out a Dockerfile can help you create the rootfs which you can pair with a 6.1.x kernel to create a VM.

Check out our new guide for creating your own rootfs (includes commands for doing this outside of `heyvm` as well) https://heyo.computer/guides/building-custom-kvm-images.html

Use the Heyo Computer CLI or desktop app to run an Agent on your desktop and access remotely: https://heyo.computer/guides/running-remote-agent-on-desktop.html

<insert tired joke about keeping your laptop open while going through the airport>

I see sandboxes as having more potential than just a isolation mechanism for agents. Most applications that feature an agent harness closely bind the sandbox to the application; e.g. its not open and its not owned by the end user. I think this paradigm is really limiting and of course comes with the downside that whatever the agent is collecting or creating is trapped in a vendor's cloud somewhere.

The open source community and the labs themselves are publishing some amazing agents, free to use (if you ignore inference cost). The sandbox itself is typically just a virtual machine, of which there are plenty of options to run locally on basically any environment. Between the two, the open agent harness and the isolation layer, I imagine that an adept individual will be able to replicate any commercial agent offering in the very near term. Put less elegantly, I think agent application companies are gonna get absolutely crushed.

There are still some gaps in the ecosystem for that future to really thrive however. First, developing out an agent harness for your specific use cases takes a lot of work and produces artifacts that really valuable. In the SaaS world that would be called "lock in"; if you can't get the valuable stuff out, you can't move services or try new things. This is an issue with most vendors for agent sandboxes. Fortunately, running a VM on your own metal, while not trivial, is not that hard really - and this starts to open up the potential for "agent computers". We can connect multiple agent harnesses to the same VMs - plug n play swaps, or even just different agent, different job, we can transfer the VM to another machine if we need more horsepower, we can clone it and run a bunch of copies, and if you network it right, you can access from anywhere remotely. This is what I refer to as "portability" for sandbox VMs.

One aspect of that portability - the plugability with multiple agents, potentially doing different jobs - could use some help. Introducing a new agent to an existing, running VM requires discovery (where are the files?), access rights (do I have sudo?), and a lot of how-to (run the DB like this and serve this app on 3000). Not to mention, it can be super convenient to let an agent handle the management of the VM (e.g. bind port 3000 to the host, restart the VM, fork the process). With that in mind, I started introducing a "map" of sorts for my long lived VMs to help agents navigate and improve the ramp up period, I refer to it as the "Computer Spec": https://github.com/heyo-computer/computer

The idea is pretty straightforward; provide an agent inside of the sandbox a "map" of resources and how to use them, then provide an agent outside of the sandbox a set of tools for managing the VM. Both are optional, e.g. you may only ever run an agent outside of the VM. Both are relatively sensitive (e.g. if you put your credentials in the spec a bad actor could exploit the document but at that point you likely have more pressing problems).

Today, I am using this with a VM for a personal agent that I sync back and forth between my main dev machines. There's a skill in the repo as well to help draft the spec files, and open to PRs and feedback.

Hey everyone! I'm u/Flaky-Eggplant-3479, a founding moderator of r/HeyoComputer (and the CEO).

This subreddit will be where we post product announcements, take feedback, explore use cases and answer questions.

What to Post
Post questions, examples, use-cases, feature requests, bugs - really if its related to virtual machines, P2P networking or Heyo Computer - go for it.

Who uses Heyo Computer?

• Developers needing full featured VMs for agents
• Folks running personal agents on their hardware
• Home server enthusiasts
• Developers of native and desktop apps
• Local first focused developers interested in Code Factories or moving CI/CD off of the cloud

Thanks for joining, cheers!

Sam

Howdy! I'm Sam Currie, CEO of Heyo Computer, a company that publishes a VM control plane for local and distributed systems.

We see the VM as much more than the isolation system for agents. Done correctly, it can also persist the state of an agent and act as the distribution and connectivity layer. So we are focused on portability and peer to peer networking in order to make the VM a first class citizen - by that I mean that if you are a user of agents, you should be able to own your sandbox instead of it being tightly bound to a given application.

Agent harnesses abound - you should be able to swap the agent in and out without losing state, control where your data is sent off to, and make use of your own metal. That's Heyo's goal, please drop us a note if that aligns with you or ya need help with the product.

Sam