Vm0(github.com)
github.com
Vm0
https://github.com/vm0-ai/vm0
21 comments
The canonical solution in this space so far is https://github.com/Dicklesworthstone/agentic_coding_flywheel..., and I would bet that this tool is just a paid version of the same, or worse, just a paid wrapper
hi, I'm VM0's developer. Happy to answer your questions.
I fully agree, without clear architecture docs, I wouldn't trust an infra service either. We're working on technical documentation now.
Here is some quick summaris about our arch, we uses E2B's managed sandbox (Firecracker microVMs), and keep working on our own Firecracker runner implementation (independent of E2B) with experimental network firewall features.
We use E2B because easy to start, no infrastructure needed, but self-hosted give developer full control, custom security policies, run on your own infra.
We're at an early stage and planning to release end of Jan. Detailed architecture docs are coming soon. Feedback welcome!
I fully agree, without clear architecture docs, I wouldn't trust an infra service either. We're working on technical documentation now.
Here is some quick summaris about our arch, we uses E2B's managed sandbox (Firecracker microVMs), and keep working on our own Firecracker runner implementation (independent of E2B) with experimental network firewall features.
We use E2B because easy to start, no infrastructure needed, but self-hosted give developer full control, custom security policies, run on your own infra.
We're at an early stage and planning to release end of Jan. Detailed architecture docs are coming soon. Feedback welcome!
I am also a bit confused by how this is all presented but it seems to be on GitHub too: https://github.com/vm0-ai/vm0
Especially with the wait list sign up.
One thing I'd never use LLMs for, yet I use them daily, a lot, and has since Codex CLI became available, would be to write tests wholesale.
Taking a look at 1400 lines long test file: https://github.com/vm0-ai/vm0/blob/1aaeaf1fed3fd07afaef8668b... and it becomes really clear why we shouldn't yet use LLMs (without detailed reviews) for this.
Obviously, you want your tests to test the implementation, not test that the mocks are working. I didn't read all the code, but lots of it not great. Generally, you want to treat your test code as any other production code, build abstractions and simple design/architecture that lets you heavily reduce test duplication, otherwise you end up with huge balls of spaghetti that are impossible to get a clear overview of, actually reasonably change, and hard to understand what is actually being tested. Like that run.test.ts.
Taking a look at 1400 lines long test file: https://github.com/vm0-ai/vm0/blob/1aaeaf1fed3fd07afaef8668b... and it becomes really clear why we shouldn't yet use LLMs (without detailed reviews) for this.
Obviously, you want your tests to test the implementation, not test that the mocks are working. I didn't read all the code, but lots of it not great. Generally, you want to treat your test code as any other production code, build abstractions and simple design/architecture that lets you heavily reduce test duplication, otherwise you end up with huge balls of spaghetti that are impossible to get a clear overview of, actually reasonably change, and hard to understand what is actually being tested. Like that run.test.ts.
The whole project seems to be LLM coded, even the docs are: https://github.com/vm0-ai/vm0/blob/main/.vm0/agents/docs-wri...
That's what I keep thinking about when I see those "once I started taking Claude, I lost 95% of my developement time" posts. Are they really making 20x the software, or are they and their customers simply believing that, watching all those endless streams of green checkmark and rocket emojis?
There is still space left in the title to add more context, how about something like "Vm0, build agents and automate workflows with natural language" ?
[deleted]
I built something similar to this before Langraph had their agent builder @braid.ink, because Claude Code kept referencing old documentation. But the problem ended up solving itself when Langraph came out with their agent builder, and Claude Code can better navigate its documentation.
The only thing I would mention is that building a lot of agents and working with a lot of plug-ins and MCPs is everything is super situation- and context-dependent. It's hard to spin up a general agent that's useful in a production workflow because it requires so much configuration from a standard template. And if you're not being very careful in monitoring it, then it won't meet your requirements when it's completed, when it comes to agents, precision and control is key.
The only thing I would mention is that building a lot of agents and working with a lot of plug-ins and MCPs is everything is super situation- and context-dependent. It's hard to spin up a general agent that's useful in a production workflow because it requires so much configuration from a standard template. And if you're not being very careful in monitoring it, then it won't meet your requirements when it's completed, when it comes to agents, precision and control is key.
This really resonates - the opacity problem is exactly what makes MCP-based agents hard to trust in production. You can't control what you can't see.
We built toran.sh specifically for this: it lets you watch real API requests from your agents as they happen, without adding SDKs or logging code. Replace the base URL, and you see exactly what the agent sent and what came back.
The "precision and control" point is key though - visibility is step one, but you also need guardrails. We're working on that layer too (keypost.ai for policy enforcement on MCP pipelines).
Would love to hear what monitoring approaches you've found work well for production agent workflows.
We built toran.sh specifically for this: it lets you watch real API requests from your agents as they happen, without adding SDKs or logging code. Replace the base URL, and you see exactly what the agent sent and what came back.
The "precision and control" point is key though - visibility is step one, but you also need guardrails. We're working on that layer too (keypost.ai for policy enforcement on MCP pipelines).
Would love to hear what monitoring approaches you've found work well for production agent workflows.
[deleted]
We should probably stop using adjectives to describe programs/systems.
"Run" X,Y,Z...where, where does it run? "Isolated environment". How isolation was achieved? Is it a VM, if yes then what is the virtualization stack and what it contains? Is it firecracker, just a docker image? What are the defaults and network rules in this isolated environments?
"Run" X,Y,Z...where, where does it run? "Isolated environment". How isolation was achieved? Is it a VM, if yes then what is the virtualization stack and what it contains? Is it firecracker, just a docker image? What are the defaults and network rules in this isolated environments?
Has there every been a tool before AI that we just accept as being so actively hostile to users, that we need all sorts of third party bolt ons to "secure" them? Like, "make sure you run your AI in a sandbox so it doesn't steal your secrets or wipe your harddrive" is for virus', not actual tooling
The Internet?
Well, obviously, `npm` has the same destructive power: package might include a script which steals secrets or wipes a hard drive. But people just assume that usually they don't.
Still too much work. Can we get an AI that writes intents for me?
This astroturfed? Moderation fail.
AI slop.
Is this Docker, Kubernetes, KVM/Xen, AWS, Azure, GCP, Fly.io, some other VM tech, or some rando's basement ?
Very little detail and I don't trust this at all.