How about the memory and battery consumption? I plan to keep it running 24/7 on my MacBook Air M4…. I am not sure if local VM is better than a VPS 🤔

Great tutorial! Safe and easy is exactly the right approach with Moltbot. If you want to take it one step further, we host it on Elestio with a dedicated VM, automated backups and security patches handled for you. Literally deploy in a few clicks and you're good to go. Perfect for anyone who wants zero headaches 😄

Mike! This is 🔥🔥🔥‼️

C'est une chose très intéressante, merci pour cette vidéo instructive.

Is there Windows alternative like UTM to create a virtual machine?

Do you think you'll do a video of the aws route? As that's also free using the free tier and isn't going to add load to my daily driver mac mini

Great tutorial.
Why does AI have to be so cheesy and over the top haha?

This level of tech still blows my mind 🤯🤯

finally someone put a nice 1.o version to use moltbolt— Thank you Mike —

Mike, this is great how you created a safe workaround! I just saw that UTM is $9.99 USD. A reasonably priced app if you need to run a virtual version of macOS on your normal macOS. Excellent explanation and thank you for starting off by saying how dangerous MoltBot is! I hyped the video, so more people can see this! 🕊️🫶

would like to know if it can also be run on a local LLM

We can also use docker

If you enable a bunch of connections in Zapier MCP then would the moltbot send all of the tools in the context to anthropic API ? Would it cost more because of the bloated context containing all the tools ?

🤍🖤🤎💜💙💚💛🧡❤💯💌

For the security aspect, I think we can place a WAF like BunkerWeb in front of MoltBot. By enabling ModSecurity, rate limiting, and enforcing strict headers and request types, we already achieve a solid level of protection, for example.

Amazing Tech – Can you make it talk to you using elevenlabs voice live?

i dont wanna pay for anything, i think i video explaining how to do this with a local llm would be beneficial to the community and your channel

While UTM is a fantastic tool for running Linux or Windows on a Mac, using it for a locally hosted AI agent on M4 hardware will result in a significant performance penalty compared to running natively.

Here is why UTM is not ideal for your specific Moltbot evaluation on an M4 Mac Mini:

1. The GPU/Metal Barrier
The primary reason you bought an M4 Mac is its Neural Engine and GPU, which share Unified Memory with the CPU.

Native: Frameworks like Ollama or MLX talk directly to the Apple "Metal" API to run models at lightning speed.
UTM: While UTM supports "Virtio-GPU" (which allows for 3D acceleration in Linux guests), it does not provide the low-level Metal pass-through required for high-performance AI inference.
Result: The model will likely fall back to the CPU (using "Accelerate" or "OpenBLAS" instead of Metal). On an M4, this can be the difference between getting 50 tokens per second and 5 tokens per second.
2. Memory Fragmentation (The 32GB Limit)
32GB is the "sweet spot" for running high-quality 14B or 20B parameter models natively.

The VM Tax: In UTM, you must "hard-allocate" RAM to the Virtual Machine. If you give the VM 24GB, your host macOS is left with only 8GB. This is inefficient.
The Native Advantage: macOS is incredibly good at managing memory dynamically. If the AI model isn't active, that 32GB is available for the system. When the AI starts up, macOS clears room for it. In a VM, that memory is "locked away" regardless of whether it's being used.
3. File System Latency
Moltbot is an "Agent," meaning its value comes from reading and writing files, searching your network, and executing shell scripts.

UTM Isolation: UTM creates a virtual disk image. For the agent to interact with your "real" internal network or local files, you have to set up shared folders (VirtFS) or network bridges.
Performance Hit: Moving data across a virtualized file system is significantly slower than native NVMe speeds. If you ask Moltbot to "summarize this 50MB PDF log," it will take much longer inside UTM.
4. Networking Complexity
Since your goal is to have the bot communicate via Telegram and interact with an internal network:

In UTM: You have to manage the VM's network stack (NAT vs. Bridged). If the VM is behind a NAT, the Telegram webhook or the internal tool-calls might require complex port forwarding.
Natively: The agent sits on the same network layer as your Mac Mini. It "sees" the internal servers, printers, and databases exactly as you do.
When SHOULD you use UTM?
The only scenario where UTM is recommended for this project is Safety Isolation:
If you are worried that Moltbot (which has shell access) might accidentally delete a system file or execute a destructive rm -rf command during your evaluation, running it inside a UTM Linux VM creates a "blast radius." If the agent goes haywire, it only destroys the virtual disk, not your Mac Mini.

The "Sweet Spot" Alternative
If you want the organization of a VM without the performance hit of UTM/Docker:

Use conda or mamba: Create a totally isolated Python environment. This keeps the dependencies (like Moltbot's specific libraries) from messing up your system Python.
Use a dedicated User Account: Create a macOS user named ai-agent. Log into that account to set up Moltbot. This provides "Permissions Isolation"—the agent will only be able to see and delete files that belong to that user, protecting your main system files.
Use screen or tmux: Run the processes in a persistent terminal session so the bot stays alive even after you close the terminal.
Summary for your M4 evaluation: To truly see what the M4 chip can do (especially with tool-calling models like Qwen 2.5), stay native. Virtualization is a layer of "friction" that will make the AI feel slower and dumber than it actually is.

What about windows?