A few months ago I audited where my code was going.
Not the deployed code. The code I was writing. Every snippet I pasted into a chat window, every file I attached to get a review, every prompt I sent while debugging at 2am - all of it passed through servers I had no visibility into. I wasn't paranoid about it. I just wanted to know.
The answer was: a lot of places.
That started me down the path of figuring out how to keep AI in my workflow without giving up control of what I was working on.
What "self-hosted AI" actually means in 2026
When people say self-hosted AI, they usually mean running a local model. Ollama, LM Studio, a quantized Llama on a machine with a decent GPU. That's one approach.
But for coding work, local models still can't match Claude Code or Gemini CLI. Not in context windows, not in tool use, not in how well they understand large codebases.
So I stopped thinking about self-hosting the model and started thinking about self-hosting everything around it.
The agent runs on my machine. It reads my files locally. The API call goes to Anthropic or Google, I accept that tradeoff. But the session state, the conversation history, the permissions, the tooling layer? None of that needs to leave my control.
The pieces you actually want to own
When you run claude or gemini in a terminal, the agent itself is already local. What's not local:
- Where you interact with it (usually a terminal you have to be physically at)
- How sessions are managed (you open and close them manually)
- How you approve or deny actions when you're not at your desk
- Whether you can run multiple agents in parallel
- Cost visibility (what did this session actually cost me?)
These are orchestration problems, not model problems. And orchestration is exactly what can and should be self-hosted.
OpenACP
I started contributing to OpenACP because it solves this specific layer.
It's a self-hosted bridge that connects AI coding agents to Telegram, Discord, or Slack. You install it on your machine, point it at your workspace, and from that point on you interact with your agents through whatever messaging app you already use.
The setup is straightforward:
npm install -g @openacp/cli
openacp
First run opens a setup wizard. You pick your platform, paste your bot token, choose a workspace, and pick a default agent. Takes about 5 minutes.
After that, your Telegram (or Discord, or Slack) becomes the interface for your agents.
Why messaging apps instead of a web UI
I originally expected to build some kind of dashboard. But then I thought about when I actually need to interact with my agents: on my phone, on the bus, between meetings.
I'm already in Telegram. My team is already in Discord. Building yet another web app to check on didn't make sense when the notification layer was already there.
The practical upside is permission handling. If an agent wants to run rm -rf or write to a sensitive file, it asks first. That prompt shows up as inline buttons in the chat, and I tap approve or deny from wherever I am. No need to rush back to a terminal.
One install, multiple agents
OpenACP uses the ACP registry to discover agents. Claude Code, Gemini CLI, Codex, Cursor, Cline, goose, and a bunch of others are all supported.
openacp agents # see what's available
openacp agents install gemini # install from registry
You can run different agents in different sessions at the same time. I usually have Claude Code running a longer task in one thread while I'm asking Gemini something quick in another. Each session gets its own topic/thread in the chat.
The daemon side
Running this as a background service is what makes it actually useful day-to-day.
openacp start # start daemon
openacp stop # stop it
openacp status # check
openacp logs # tail logs
The daemon survives terminal sessions and starts on boot. Close your laptop, open it at a coffee shop, your agents are still there. Sessions persist too, so you reconnect and pick up where you left off.
If something breaks, run openacp doctor. It checks your config, bot token, agent installs, and daemon status, then tells you exactly what's wrong.
What stays private
I want to be clear about what this doesn't do. The API calls to Anthropic or Google still happen. The model inference is not local.
But here's what stays on your machine:
- Your code and files (the agent reads them locally)
- Your session history and conversation state
- Your config and credentials
- Your cost data and usage logs
The orchestration layer is fully yours. There's no relay service sitting between you and your agent, and no vendor storing your session history on their end.
The other side of this: if I decide to switch from Claude Code to Gemini for a project, I change one config value. The messaging setup, the sessions, the permissions, the cost tracking, all of that stays the same. I'm not locked into one agent vendor.
A typical day with this setup
Morning. I open Telegram, send "review the PR on branch feature/auth" to my bot. Claude Code starts reading the diff, leaves comments in the chat. I read them on the train.
Afternoon. I need to scaffold a new API endpoint. I open a second session, this time with Gemini. It generates the boilerplate, I review the output in Discord while in a meeting (don't tell my manager).
Something fails in CI. I forward the error log to the bot, ask it to investigate. It greps through the codebase, finds the issue, proposes a fix. I approve the file write from my phone.
End of day. openacp api status shows me 3 sessions ran, roughly $4.20 in API costs. Everything's logged locally.
Getting started
npm install -g @openacp/cli
openacp
The wizard asks 5 things: platform, bot token, workspace path, default agent, run mode. If you already have a Telegram bot from @botfather, the whole thing takes under 5 minutes.
For running it long-term, switch to daemon mode:
openacp start
After that it's just there. You message your bot and things happen.
Detailed platform guides (Telegram, Discord, Slack) are in the docs.
Links
Source: https://github.com/Open-ACP/OpenACP
Docs: https://openacp.gitbook.io/docs
ACP registry: https://agentclientprotocol.com/get-started/registry
MIT licensed. I'm a contributor, happy to answer questions.
Top comments (0)