So think of all this as LLM orchestration runtimes. None of these actually run an LLM, it's just taking care of the interface spaghetti.
Main components they all have:
LLM API integration - you pick your API platform, the model to use and you give it a key
Chat channels with owner - a gazillion built-in integrations with every thinkable comms platform (This is what I'm looking at to remove bloating from in #1444916)
Built-in tools to communicate with the OS (from ls and cat to interacting with your browser - not all of them have all options)
Skills (markdown instructions)
Memory (most often just markdown files it reads and writes)
"Bot Identity" (markdown)
Scheduling: heartbeat and crontabs
That's really all it is and why you can fit it in a 600kb, 10MB or 300MB runtime. Smaller if you remove bloat, and the smallest runtimes often have already removed a lot of bloat.
Out of the box, picoclaw takes about 20MB RAM on x86_64. zeroclaw was said to be better but honestly, having a million rust crates as dependency is awful and the binary linking took infinite RAM and froze my dev box for a few minutes, so I figured that that was too much work. It's all vibe-coded anyway, so all of this stuff is fully disposable.
So think of all this as LLM orchestration runtimes. None of these actually run an LLM, it's just taking care of the interface spaghetti.
Main components they all have:
lsandcatto interacting with your browser - not all of them have all options)That's really all it is and why you can fit it in a 600kb, 10MB or 300MB runtime. Smaller if you remove bloat, and the smallest runtimes often have already removed a lot of bloat.
Out of the box, picoclaw takes about 20MB RAM on x86_64. zeroclaw was said to be better but honestly, having a million rust crates as dependency is awful and the binary linking took infinite RAM and froze my dev box for a few minutes, so I figured that that was too much work. It's all vibe-coded anyway, so all of this stuff is fully disposable.