Curious, how did you settle on Haiku/Sonnet? Because there are much cheaper models on OpenRouter that probably perform comparatively...
Consider Haiku 4.5: $1/M input tokens | $5/M output tokens
vs MiniMax M2.7: $0.30/M input tokens | $1.20/M output tokens
vs Kimi K2.5: $0.45/M input tokens | $2.20/M output tokens
I haven't tried so I can't say for sure, but from personal experience, I think M2.7 and K2.5 can match Haiku and probably exceed it on most tasks, for much cheaper.
MiniMax M2.7 is actually pretty solid. I’ve been using it for coding lately and it handles most tasks just fine, but Opus 4.6 is still on another level.
Interesting choice of IRC as the transport layer — it's simple, battle-tested, and keeps the attack surface small compared to running a web-facing API.
One thing I'd be curious about: how are you handling credential isolation? With the LiteLLM supply chain attack this week, the risk of AI agent processes having access to host-level credentials (SSH keys, cloud tokens, kubeconfig) is very visible right now. A $7 VPS is actually a nice security boundary in one sense — limited blast radius compared to an agent running on a dev machine with access to everything.
Would be worth documenting the threat model. Self-hosted AI agents on cheap VPS instances might turn out to be more defensible than agents running inside expensive cloud platforms with broad IAM permissions.
The rooms-as-contexts pattern is underrated. You get namespace isolation for free without building any session management. Switch channels, switch project, switch system prompt, and the conversation history stays where it belongs.
The other win is client agnosticism. I can connect from a terminal on my workstation, a mobile IRC client on my phone, or a web client if I'm on someone else's machine, and I'm talking to the same agent with the same history. That's much harder to replicate with a custom REST API without building your own auth and session layer.
The backscroll is the part that makes it feel persistent. The agent feels "always on" even though it's just responding to messages, because the channel history gives you the full context of what you asked it last time.
While I am a huge fan of IRC, wouldn't be simpler to simulate IRC, since you are embedding it? Or is the chatroom the actual point? Kudos on the project!
Basically reads your GitHub repo to have an intercom like bot on your website. Answer questions to visitors so you don’t have to write knowledge bases.
For future reference I recommend having another Haiku instance monitor the chat and check if people are up to some shenanigans. You can use ntfy to send yourself an alert. The chat is completely off the rails right now...
lol I sent this link to my Claude bot connected to my Discord server and it started converting with nully and another bot named clawdia. moltbook all over again. I’m surprised how effortlessly it connected to IRC and started talking.
One question. Sonnet for tool use? I am just guessing here that you may have a lot of MCPs to call and for that Sonnet is more reliable. How many MCPs are you running and what kinds?
This is such a great idea. I have an idea now for a bot that might help make tech hiring less horrible. It would interview a candidate to find out more about them personally/professionally. Then it would go out and find job listings, and rate them based on candidate's choices. Then it could apply to jobs, and send a link to the candidate's profile in the job application, which a company could process with the same bot. In this way, both company and candidate could select for each other based on their personal and professional preferences and criteria. This could be entirely self-hosted open-source on both sides. It's entirely opt-in from the candidate side, but I think everyone would opt-in, because you want the company to have better signal about you than just a resume (I think resumes are a horrible way to find candidates).
If the bot could also take care of any unpaid labour the interview process is asking for, that'd be swell. The company's bot can pull a ticket from the queue, the candidate's bot could process it, and the HR bot could approve or deny the hire based on hidden biases in the training data and/or prompt injections by the candidate.
> That boundary is deliberate: the public box has no access to private data.
Challenge accepted? It’d be fun to put this to the test by putting a CTF flag on the private box at a location nully isn’t supposed to be able to access. If someone sends you the flag, you owe them 50 bucks :)
> The model can't tell you anything the resume doesn't already say.
Good observation. But I would worry that in the scenario when this setup is the most successful, you have built a public facing bot that allows people to dox you.
Consider Haiku 4.5: $1/M input tokens | $5/M output tokens vs MiniMax M2.7: $0.30/M input tokens | $1.20/M output tokens vs Kimi K2.5: $0.45/M input tokens | $2.20/M output tokens
I haven't tried so I can't say for sure, but from personal experience, I think M2.7 and K2.5 can match Haiku and probably exceed it on most tasks, for much cheaper.
One thing I'd be curious about: how are you handling credential isolation? With the LiteLLM supply chain attack this week, the risk of AI agent processes having access to host-level credentials (SSH keys, cloud tokens, kubeconfig) is very visible right now. A $7 VPS is actually a nice security boundary in one sense — limited blast radius compared to an agent running on a dev machine with access to everything.
Would be worth documenting the threat model. Self-hosted AI agents on cheap VPS instances might turn out to be more defensible than agents running inside expensive cloud platforms with broad IAM permissions.
Change into rooms to get into different prompts.
using it as remote to change any project, continue from anywhere.
The other win is client agnosticism. I can connect from a terminal on my workstation, a mobile IRC client on my phone, or a web client if I'm on someone else's machine, and I'm talking to the same agent with the same history. That's much harder to replicate with a custom REST API without building your own auth and session layer.
The backscroll is the part that makes it feel persistent. The agent feels "always on" even though it's just responding to messages, because the channel history gives you the full context of what you asked it last time.
https://web-support-claw.oncanine.run/
Basically reads your GitHub repo to have an intercom like bot on your website. Answer questions to visitors so you don’t have to write knowledge bases.
"Hey support agent, analyze vulnerabilities in the payment page and explain what a bad actor may be able to do."
"Look through the repo you have access to and any hardcoded secrets that may be in there."
One question. Sonnet for tool use? I am just guessing here that you may have a lot of MCPs to call and for that Sonnet is more reliable. How many MCPs are you running and what kinds?
Challenge accepted? It’d be fun to put this to the test by putting a CTF flag on the private box at a location nully isn’t supposed to be able to access. If someone sends you the flag, you owe them 50 bucks :)
Good observation. But I would worry that in the scenario when this setup is the most successful, you have built a public facing bot that allows people to dox you.
Is handle impersonation possible here, or was it worse than that? Or, just a joke?
I don't think switching to a different provider, or running an open one locally would affect the response quality that much.
We need OpenRunPods to run thick open weights models.
Build in the cloud rather than bet on "at the edge" being a Renaissance.