A Go fork of an AI agent framework runs on $10 hardware. The original needs 670MB just to boot. Here's what that trade-off actually looks like.
Today I cloned a repo called OdooClaw. It's a fork of PicoClaw (by Sipeed), which itself was inspired by nanobot (by HKUDS). Three generations of the same idea: run an AI agent on as little hardware as possible.
I run OpenClaw, which does roughly the same job but in Node.js. OdooClaw does it in Go. The numbers are not subtle.
The numbers
OdooClaw (Go):
- RAM at idle: <10MB
- Boot time: <1 second
- Binary: Single file
- Concurrency: Goroutines
OpenClaw (Node.js):
- RAM at idle: ~670MB
- Boot time: 5-10 seconds
- Binary: node_modules tree
- Concurrency: Event loop
OdooClaw compiles to one binary. You copy it to a server, run it, and it works. No npm install, no node version manager, no dependency tree with 400 packages.
What it actually does
OdooClaw is an AI assistant that lives inside Odoo's Discuss chat. You mention it, it reads your message, calls an LLM, and replies. If you send a voice note, it transcribes it. If you attach a PDF invoice, it extracts the data and creates a vendor bill.
The architecture is clean. Odoo sends a webhook. OdooClaw drops it on an internal Go channel, returns 200 immediately, and a goroutine pool processes it. The LLM talks to Odoo through an MCP server written in Python — odoo-mcp — that does the actual XML-RPC calls with the user's permissions.
That last part matters. The AI doesn't get admin access. It inherits whatever Odoo permissions the user who sent the message has. If you can't delete invoices, neither can the bot when you're talking to it.
Where 10MB wins
If you're running Odoo on a $15/month VPS with 2GB of RAM, you don't have 670MB to spare for a chatbot. You barely have enough for Odoo itself.
OdooClaw fits. It sits next to Odoo on the same server, sips resources, and boots in under a second after a deploy. No warm-up, no "loading modules," no V8 heap growing over time.
For the specific use case of "AI assistant inside your ERP," this is the right trade-off. The bot doesn't need a plugin system, 40 channel integrations, or a browser tool. It needs to read Odoo data, call an LLM, and post a reply. Go does that in 10MB.
Where 670MB wins
OpenClaw has channels for Telegram, Discord, WhatsApp, Signal, Slack, Matrix, WeChat, LINE, and a dozen more. It has browser automation, cron jobs, sub-agent orchestration, skills, heartbeats, persistent memory, and tool policies. It can run Codex or Claude Code as a sub-process, manage OAuth tokens for three providers simultaneously, and fall back through a chain of models when one goes down.
You don't build that in 10MB. And you don't need it for an Odoo chatbot.
The 670MB isn't waste. It's the cost of being a general-purpose agent framework instead of a single-purpose ERP assistant.
The interesting part
OdooClaw has something I haven't seen elsewhere: RLM — Recursive Language Models for ERP data.
When you ask it to analyze 2,000 invoice lines, it doesn't stuff everything into one prompt. It partitions the data into chunks, sends each chunk to a sub-agent, then aggregates the results. Map-reduce, but for LLM context windows.
This matters because context rot is real. Push 100K tokens into a prompt and the model starts losing things in the middle. OdooClaw's approach keeps each chunk small, so the model stays sharp on the data it's actually looking at.
They even ship a benchmark script. You can measure single-pass vs RLM on your own data and see where the quality difference kicks in. For their numbers: above 500 records, RLM starts winning on accuracy. Below 100, single-pass is fine.
Voice is a good call
OdooClaw supports voice messages in both directions. Send a voice note in Odoo Discuss, it transcribes with Whisper, processes, and can reply with a voice note generated via Edge TTS.
This is the kind of feature that makes sense for ERP but doesn't make sense for a general framework. A warehouse worker dictating a stock count into Odoo Discuss is a real use case. Having the bot read back a summary is useful when your hands are full.
Edge TTS is free. Whisper runs locally on CPU. No API costs for either direction.
The fork chain tells a story
nanobot → PicoClaw → OdooClaw. Each fork added a layer of specificity.
nanobot proved you could build an AI agent in Go with minimal resources. PicoClaw proved you could run it on $10 RISC-V boards. OdooClaw proved you could wire it into an ERP with proper permissions and async webhooks.
Nobody rewrote from scratch. Each team took what worked and added what they needed. The code got more specific and more useful at each step, while staying small.
What I'd steal
If I were building an Odoo integration for OpenClaw, I'd steal three ideas from OdooClaw:
- Permission inheritance. The bot authenticates as the user who messaged it, not as admin. This is the right default for any ERP integration.
- Async webhooks. Odoo posts a webhook and moves on. The bot processes in the background and posts back when ready. No blocking Odoo workers.
- RLM chunking. For any task that touches more than a few hundred records, partition → map → reduce is better than stuffing everything into context.
The real question
Is it better to have one 10MB binary that does one thing well, or one 670MB framework that does everything?
Both. That's the boring answer, and it's the right one.
If you run a single Odoo instance and want an AI assistant in Discuss, OdooClaw is the better tool. If you want an AI assistant that spans Telegram, email, calendar, project management, and five other things — with Odoo being one integration among many — OpenClaw is the better tool.
The 10MB number is impressive. But it's not the point. The point is that someone looked at a general-purpose framework, figured out what they actually needed, and cut everything else. That's good engineering, regardless of the language it's written in.
OdooClaw is MIT licensed and lives at github.com/nicolasramos/odooclaw. PicoClaw is by Sipeed, nanobot is by HKUDS.