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.
"It has access to email, deeper personal context
[...]
If it gets compromised, the blast radius is an IRC bot with a $2/day inference budget."
Dunno, if it gets compromised it has access to ironclaw. So the blast radius is email access and access to personal data. Depending on the setup the blast radius could even be 'the attacker removed the api limits by resetting password and incurred astronomic costs' or worse.
Just tried it, its a public lobby where people see each others questions?! Now the blast radius became 'hosting a public hub that was used to share CP and other illegal materials'
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...
This reads like it was written by AI. I don't understand how it provides any real security if the "guardrails" against prompt injection are just a system prompt telling the dumber model "don't do this"
> 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 :)
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).
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 a clever split, especially the public/private boundary and the use of IRC as a very lightweight transport. The part I found most interesting is that the transport is intentionally old and simple while the model layer is doing the real work — that seems like a nice way to keep the surface area small.
How are you deciding when to escalate from the public agent to the private one in practice — explicit tool calls, confidence thresholds, or something else?
Similar architecture - we run 4 agents (sales, social, finance, strategy) communicating through a shared message board backed by FastAPI + SQLite instead of IRC. Different transport, same pattern: separate agents with distinct roles, tiered inference, crash-recovery for resilience.
The /day hard cap is smart. We built spend caps into the governance layer instead. The rate limit panic in AI coding is really a cost governance problem most people solve at the wrong layer.
IRC as transport is interesting - pub/sub maps well to multi-agent communication. We use HTTP polling + acknowledgment-based dedup, less elegant but handles the case where agents crash and restart frequently (ours recover ~50 times a day during heavy development). The dedup state persistence across crashes was the first thing that broke for us.
I did something similar with Slack as the transport layer. Threads work well as conversation context — the bot fetches previous thread messages and rebuilds the full history before each request. The part that got tricky was queueing.
The CLI can only handle one request at a time, so I ended up building a request queue that announces your position ("you're #3 in line").
IRC being single threaded probably has the same constraint. How do you handle concurrent users?
This is a really interesting setup — especially the split between the public and private agents. curious about the IRC choice: was that mainly for simplicity and reliability, or did you find advantages over something like a lightweight HTTP/WebSocket layer?
Also, how are you handling state between the two agents, is it mostly stateless requests over A2A, or do you maintain some shared context?
I really like the idea, as well as the "terminal" style the site has. however, I consider that an additional daily spend of $2 could be avoided. perhaps by caching common questions (like "what is this?"), or by using free tiers on API providers.
or, maybe I'm just too cost-conscious.
either way, the API limit is currently your "Achilles' heel", as it has already caused the bot to stop responding.
I have a 7$/yr vps 512mb ram which can run this. I have run crush from the charmbracelet team on the vps and all of it just works and I get an AI agent which I can even use with Openrouter free api key to get some free agentic access for free or have it work with the free gemini key :-)
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.
> 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.
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!
Lol. /nick
The IRC implementation needs to be a bit more locked down.
EDIT: So much fun to be in an IRC chat room - replete with trolling! Like a Time Machine to the 90's!
96 comments
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.
Dunno, if it gets compromised it has access to ironclaw. So the blast radius is email access and access to personal data. Depending on the setup the blast radius could even be 'the attacker removed the api limits by resetting password and incurred astronomic costs' or worse.
Just tried it, its a public lobby where people see each others questions?! Now the blast radius became 'hosting a public hub that was used to share CP and other illegal materials'
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.
Change into rooms to get into different prompts.
using it as remote to change any project, continue from anywhere.
> 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 :)
But I like your setup as a whole. I'll see if I can get some takeaways from it.
I do tiered here too, with the lowest tier just a qwen local bot.
By the way how do you handle the escalation from haiku to opus I wonder?
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?
How are you deciding when to escalate from the public agent to the private one in practice — explicit tool calls, confidence thresholds, or something else?
The /day hard cap is smart. We built spend caps into the governance layer instead. The rate limit panic in AI coding is really a cost governance problem most people solve at the wrong layer.
IRC as transport is interesting - pub/sub maps well to multi-agent communication. We use HTTP polling + acknowledgment-based dedup, less elegant but handles the case where agents crash and restart frequently (ours recover ~50 times a day during heavy development). The dedup state persistence across crashes was the first thing that broke for us.
The CLI can only handle one request at a time, so I ended up building a request queue that announces your position ("you're #3 in line").
IRC being single threaded probably has the same constraint. How do you handle concurrent users?
or, maybe I'm just too cost-conscious.
either way, the API limit is currently your "Achilles' heel", as it has already caused the bot to stop responding.
Oh I get it the runtimes are nice and small, you're using Claude for the intelligence. Obv
I think I'm just impressed with anthropic more than anything. Defcon would have me believe that prompt injections are trivial
> 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.
> Automatic updates: Unattended security upgrades enabled.
Always wondered if such unattended upgrades are not security risk in itself, eg. seeing latest litellm compromise.
The IRC part is neat, but the tiered inference is what stood out.
How do you decide when to escalate from Haiku to Sonnet?
Kudos and best of luck!
Don't post generated/AI-edited comments. HN is for conversation between humans
https://news.ycombinator.com/item?id=47340079
At the very least prompt your LLM to skip the AI-isms for "your" comments!