Hacker News
Ask HN: Is anyone running multi/always-on agents that don't cost a fortune?
6 points by abejora 1 day ago | 5 comments
Yesterday a few interesting links appeared on hacker news about always-on [1] and multi-agent setups [2].

Some of those points resonate with what we're experiencing with our current approach of running agents and sub-agents locally.

- We are delegating complex and long running tasks to agents more and more. Being able to run those overnight seems like a logical next step in efficiency, because at the moment we are stopping the local agents every evening and restarting them in the morning.

- A setup with decentralized multi-agent system with shared context is 5.5x faster than Claude code + native subagents. It takes 29.3 minutes (2% of agent time waiting) versus 162.7 minutes (44% of agent time waiting). [3] This aligns with our feeling that locally running agents are often "doing nothing" while waiting on test results, each other, and so on

- The possibility to monitor "input channels" (e.g. chat channels, e-mail inboxes...) and have agents act autonomously on those seems like something that could help us out as well.

This all sounds amazing, but we're unsure how others are currently doing this and what those cost. We currently mainly power our needs via subscription-based contracts (e.g. claude (code) pro/max, chatgpt plus/pro ...)

- Is anyone running such multi-agent or always-on agent systems?

- Do you host it yourself, or do you use existings solutions like grok bots or claude remote control sessions or claude routines?

- Can you make this work with subscriptions, or do you use API pricing, or even self-hosted LLMs? How do the costs compare with running local agents?

- How are the results? Is it an improvement?

[1] Stanford CS146S: How always-on agents work

Lecture: https://www.youtube.com/watch?v=L1OBRtfPS34

Slides: https://drive.google.com/file/d/1b8WiBk_lcB3ue-jZMLijSUMLj6SDiF6Z/view

[2] CMU 11-768 AI Agents: https://www.cmu-agents.com/#/schedule

[3] Decentralized Multi-Agent Systems with Shared Context (figure 3, page 3): https://arxiv.org/pdf/2606.10662

[–] naw103 3 hours ago
I run about 45 scheduled agents for marketing and engineering across multiple products. Most of them are not always-on, they are scheduled jobs. Some run mornings,some hourly. That covers most of what I wanted from always on and many of them have some type of event listener that can trigger a run as needed (like background research on a client signup).

The part that took the work was shared state. We used GPTree for the knowledge engine. Every routine reads and writes from the same knowledge and anything public or high risk gets an approval card to continue.

[–] abejora 1 day ago
Links from the post:

[1] Stanford CS146S: How always-on agents work

Lecture: https://www.youtube.com/watch?v=L1OBRtfPS34

Slides: https://drive.google.com/file/d/1b8WiBk_lcB3ue-jZMLijSUMLj6S...

[2] CMU 11-768 AI Agents: https://www.cmu-agents.com/#/schedule

[3] Decentralized Multi-Agent Systems with Shared Context (figure 3, page 3): https://arxiv.org/pdf/2606.10662

[–] abejora 1 day ago
It was brought to my attention that Decentralized Multi-Agent Systems with Shared Context (DeLM) has a project website that also lists those findings and graphs: https://yuzhenmao.github.io/DeLM/
[–] morisblake 7 hours ago
Try https://opencheese.dev I'm using it for couple of months and it's very positive experience. Cheap claude, codex, gemini, deepseek and uncensored models. They also have some free models. I use deepseek agents and minimax 3.1 flash a lot here.
[–] harlequinetcie 1 day ago
agent-swarm.dev is open source/MIT exactly meant for these scenarios.

Particularly interesting for you, our lasts posts on how we handle to have efficient dreaming focused on reducing costs.

tl;dr: there's a self-driven process generating more effective and efficient prompts, code, and potentially select systemone models to tackle the cost problems.

We have companies using the system that we understand have stayed 'flat' in token consumption but with increasing workloads (ie. more workflows running).

Hope it helps!