OpenClaw, a
Self-Hosted AI Gateway
One Node.js service that owns the connection to a language model, and hands the same assistant to whichever chat app I happen to be in. Built so the model underneath can be swapped without touching anything else.
One Brain, Many Front Doors
Most people using an AI assistant end up with the same conversation scattered across a browser tab, a phone app, and whatever else. I wanted one service that owns the model connection, holds the configuration, and exposes the same assistant wherever I already am. That service is OpenClaw.
It runs on my own hardware rather than a managed platform. That is the whole point: I control which provider it talks to, what it is allowed to do, and what it costs, and none of those are decisions somebody else gets to change for me.
What It Had To Do
- Run entirely on hardware I own, with no managed platform in the middle
- Treat the model provider as a setting, not an architectural commitment
- Keep configuration in one readable file rather than scattered environment variables
- Add a new chat surface without rewriting the core
- Fail in a way I can actually read in a log
Three Providers Before One Held Up
The interesting engineering here was not the bot. It was discovering that provider reliability, not model quality, is what actually decides whether a personal assistant is usable day to day.
Because each migration only touched configuration, none of them required rewriting the bots. That was not luck. Keeping the provider behind a boundary was a decision made before the first migration, and it paid for itself twice.
Where It Actually Gets Used
Both front ends talk to the same gateway, so there is one place to change behaviour and one place for it to break.
Jarvis on Discord
The primary interface. Discord was the right first surface because it is where I already spend time, which means the assistant gets used instead of admired. Runs as its own bot application against the gateway.
Telegram
Added second, and the real test of whether the architecture held. Wiring a second surface meant writing an adapter, not touching the model layer, which is what proved the boundary was in the right place.
Where It Is Going
- A multi-agent council: separate Dev and Biz agents as their own Discord bots, each with its own role and context, rather than one assistant asked to be everything
- GitHub integration, so the assistant can act on repositories instead of only talking about them
- Finish the OpenRouter cost comparison and decide whether to move
What It Taught Me
- Provider reliability and rate limits shape an AI product more than model choice does
- The boundary you draw before the first migration is what makes the second one cheap
- Self-hosting costs you convenience and buys you control, and that trade is worth making deliberately, not by accident
- Applied directly from the Anthropic Building with the Claude API credential: tool use, streaming, and prompt structure
Why This Project Matters
This is the project where I stopped consuming AI tooling and started building the plumbing underneath it. Choosing a provider, drawing the boundary so the choice stays reversible, and running it on hardware I own is the same shape of work as integrating any vendor system into a business, which is exactly the work I want to be doing.