Mindroom

Stars measure interest, not usage. After a year of MindRoom, with forks of a Matrix client, two Matrix servers and a Matrix web client, plus 126 workarounds for one AI framework, my rule is: depend on what millions of projects use every day, roll your own when a library only gives you the easy part, and fork when the problem is hard and few people use the code.

For years, a Docker container was a good enough box to run code in, because getting out of one usually needed a hard-to-find bug in the Linux kernel. Now AI models are good at finding those bugs, and AI agents write the code running inside the containers. This post explains what the kernel does, how containers use it to fake a separate computer, why that is a problem now, and how six lines of code let MindRoom give its agents a stronger wall.

I assumed every model is trained inside its vendor’s own coding agent, so I expected it to work best with the same tools, and best of all in a minimal agent with nothing but its native shell. Over more than 4,000 runs of 12 short terminal tasks, the native tools made only one model clearly more efficient, Claude Opus 4.8, made GPT-6 Astra and Sol use 43 to 59% more tokens, and the minimal agent won on its own.

MindRoom grew one small group at a time at IonQ, until a company-wide demo made hundreds of people sign up in a day. What surprised me is that the heaviest users include engineers who already live in their coding agents.

TypeSafe’s Jev, a new fast and cheap classifier model that doesn’t require fine-tuning, was suddenly, literally everywhere I looked, so I tried it in MindRoom. I now use it for small decisions I would never have spent an LLM call on, like whether a “thanks” should interrupt an agent that is still working.

MindRoom is an open-source system I built that creates AI agents living in Matrix. Because Matrix bridges to Slack, Telegram, Discord, and more, your agents follow you everywhere—with persistent memory, multi-agent collaboration, and 100+ built-in tool integrations.