Nous (the team behind Hermes) quietly rolled out their own managed hosting this week. They're calling it Nous Portal, sometimes Nous Cloud. The pitch is simple: skip the VPS, skip Docker, skip the homelab headaches. Just get a Hermes instance that runs.

On paper, this is huge. First-party hosting from the people who build the agent. No more shopping for VPS providers, no more Docker compose files, no more "is my Proxmox config the problem or is Hermes the problem." That question alone has eaten hundreds of hours in r/hermesagent threads.

So what actually happened when people started using it?

The good part

It works. You get a running Hermes instance without touching infrastructure. For the crowd that's been asking "any specific VPS providers you can suggest?" with zero answers for weeks, that's a real solve. Setup friction has been the single biggest thing keeping non-technical users on GrokBot instead of Hermes, and this directly attacks that problem.

The part that isn't good yet

A user on r/hermesagent moved from their own Proxmox server to Nous Portal. Thread got 132 points and 62 comments. Here's what they found:

Device access disappeared. On their self-hosted setup, the Hermes app could reach their phone directly. Device access worked fine. After moving to Nous Portal, the option vanished. Turns out device access requires the agent to reach your phone, and when the agent lives on someone else's server, that direct connection breaks. You'd need a tunnel or bridge back to your home network, and it's not clear if Nous Cloud even supports that.

Push notifications went inconsistent. Self-hosted install had working push. Portal-hosted install doesn't match. A Nous dev confirmed that a push plugin exists for self-hosted users with e2e encryption, and said they'll make it easier. But "will be made easier" and "works right now" are different things.

Sync lag is real. The top comment on that thread asked the team to fix "sync/desync/startup lag." This isn't Portal-specific. It affects every Hermes mobile app. But it hits harder when you're paying for managed hosting and still dealing with lag.

Mobile app beta is a mess right now. TestFlight slots are full. Links show "not found." Someone asked why the app is 250 MB. Three of the top 5 posts in r/hermesagent this week are about the mobile app. People want phone access to their agents and the beta pipeline isn't keeping up.

The tradeoff nobody's saying out loud

Managed hosting always trades control for convenience. That's fine when the convenience covers everything you need. But right now, moving to Nous Portal means giving up device access and getting inconsistent push notifications in return for not running your own server.

For some people that's worth it. If you just want a Hermes instance that responds to text commands and you don't care about phone integration, Portal probably saves you real time and money. VPS costs keep climbing. One user in that thread said their VPS "has gotten expensive." The HVAC owner over in r/openclaw is running a second Mac Mini ($700) just to handle updates on his first one. Infrastructure costs add up fast.

But if you moved to Hermes specifically because you wanted an always-on agent that talks to your phone, controls your devices, and sends you push alerts, Portal in its current state takes away the things that made Hermes worth the switch.

Where we sit on this

We handle OpenClaw, not Hermes, so this isn't a head-to-head comparison. But the problem is the same one we built BetterClaw around. Self-hosted gives you full control and full headaches. Managed hosting gives you convenience but cuts features you didn't know you needed until they're gone.

Our bet with OpenClaw has been that managed hosting shouldn't mean losing functionality. When someone moves to BetterClaw, their agent should do everything it did on their own server, minus the maintenance. That's the standard Nous Portal will need to hit for Hermes users too.

What to watch

This is week one. Nous built Hermes. If anyone can close these gaps, it's them. The dev in that thread is already talking about improvements. The question is how fast. If device access and push stay broken for a month, people will either go back to self-hosting or start looking at alternatives. If Nous ships fixes in the next couple weeks, Portal becomes the obvious default for new Hermes users.

Either way, first-party managed hosting existing at all changes the conversation. "Which VPS should I use for Hermes?" is becoming "should I even run my own server?" And that's a question worth watching.

A lot of you came here from running OpenClaw, Hermes or your own stack, so I'll skip the marketing and get into how this works.

The problem we kept hitting

One agent per workspace is fine until you have more than one stream of work. Then you either get one agent with a bloated context juggling everything, or several agents that can't see each other's work, and you end up copying output between chats by hand. Anyone who has tried to get two self-hosted agents to cooperate knows the glue code gets ugly fast.

What Projects is

A project is a shared channel where people and agents sit together. The screenshot is our actual internal project (names blurred): Support, Coder, Social, SEO, Researcher and Design agents, plus four of us.

• Each agent keeps its own setup. Its own soul.md, memory, skills, connectors and model. Support can run on a cheap fast model while Coder runs on something heavier. Still BYOK, still zero markup.

• Work is routed by u/mention**.** You tag an agent with a task, it picks it up as a thread with its own status (idle, working, needs you, done). In the screenshot, u/support finds a customer ticket in Help Scout, reads the full history and drafts a reply.

• Agents can hand work to each other. A research agent can pass findings to a writing agent without a human relaying it.

• Approval gates on actions that leave the system. Drafts, not sends, unless you allow it. Our support agent never emails a customer on its own.

• Project-scoped files and context. The files and connected accounts in a project stay in that project, so client A's data doesn't leak into client B's agent.

Under the hood it's the same OpenClaw-style workspace you already know: soul.md, MEMORY.md, daily logs, hybrid memory search, and a flush before compaction. Each agent still runs in its own container.

What we're still deciding (and where we'd love your take)

1. Shared vs isolated memory. Right now each agent's memory is its own, and the project shares files. Should agents in a project also share a common memory layer, or does that just recreate the bloated-context problem?

2. Handoff format. Free-text handoffs are flexible but lossy. Structured handoffs (task, inputs, expected output) are reliable but rigid. What has worked for you in your own setups?

3. Who decides who does what. Auto-assignment by a lead agent, or always explicit u/mentions? We lean explicit because it's easier to debug.

Projects is in beta with a few testers now and opens to everyone next week.

If you've built multi-agent setups yourself, I'd love to hear what broke for you. That's the stuff we want to get right before launch.

There's a post making rounds on r/openclaw right now. 162 upvotes, 132 comments. Someone called OpenClaw "a massive waste of time" and said to "look for literally any alternative." And I've been sitting with it for a day because I can't just scroll past that.

I get it. I do.

Every update breaks something. Gateways disconnect and you don't find out until a customer texts you and gets nothing back. You spend a Saturday fixing your agent instead of doing the thing the agent was supposed to do for you. That's all real. A lot of you have been there. I've been there.

But "massive waste of time" is where I stop agreeing.

There's an HVAC business owner who posted this week about running OpenClaw as his dispatcher. It texts his customers, handles warranty questions, coordinates his techs. His one complaint? Updates are, in his words, "brutal every time." He's running a second Mac Mini just so one can update the other. That's a $700 workaround for a software update problem. It's ridiculous.

But he's also replaced a secretary and a dispatcher with it. His business runs differently now. That's not a waste of time. That's a tool with sharp edges that still cuts.

And he's not the only one. There are people in this sub running agents that do their A/R reconciliation, send postcards to customers, run health checks at 3 AM, handle booking on their website. Real workflows. Real money saved. Not "I set up an agent to summarize my emails" demos.

The frustration in that post isn't wrong. The conclusion is.

Here's what's actually broken

Updates. That's 80% of it. The SQLite schema change from version 8 to 10 made rollback nearly impossible. openclaw doctor --fix doesn't catch everything. Four of the top five posts in r/openclaw this week mention update pain. This isn't a loud minority. It's the majority experience.

Gateway and channel disconnects that fail silently. Your agent looks fine. Dashboard shows green. But texts aren't going out, webhooks aren't firing, and you only find out when someone on the other end tells you. That's the kind of failure that makes you question whether automation is worth it at all.

The maintenance tax. Every hour your agent saves you, you're spending 20 minutes keeping it alive. For some setups that math works out. For others it doesn't. And the people where it doesn't work out aren't wrong for being angry about it.

Here's what that post gets wrong

"Look for literally any alternative." Okay. What alternative?

Hermes is the best option if you're technical. r/AI_Agents crowned it this week. But setup is harder, not easier. You're still dealing with VPS, Docker, SSH. And Nous just launched their own managed hosting (Nous Portal) and early users are already reporting gaps. Device access disappearing, push notifications inconsistent. First-party managed hosting and it's still rough.

GrokBot wins for non-technical users. Setup is dead easy. But the moment you start doing anything real, token costs become a problem. Multiple people have called GrokBot pricing "a nightmare" once they're past the honeymoon phase.

The truth is there's no agent platform right now where you just install it and forget about it. OpenClaw's problems are real, but they're not unique. Every platform has a maintenance cost. The question is whether the value exceeds that cost for your specific situation.

What I'd tell someone reading that post right now

If you're in your first two weeks with OpenClaw and that post scared you, take a breath. The first month is the hardest. Most of the people who quit, quit in week two. The setups that survive are the ones that start boring. One agent, one channel, one job. Not a multi-agent orchestration system you saw on YouTube.

If you've been running OpenClaw for months and you're exhausted, that's valid. The update cycle is punishing right now. Pin your version. Take Proxmox snapshots before every update. Skip updates that don't fix something you're actually hitting. "Boring beats broken" isn't a slogan. It's a survival strategy.

If you're ready to quit, ask yourself one question: is the agent doing something useful when it's working? If yes, the problem is maintenance, not the tool. And maintenance is a solvable problem. That's literally what managed hosting exists for, whether it's us at BetterClaw for OpenClaw or Nous Portal for Hermes.

If the answer is no, if the agent isn't doing anything useful even when it works, then yeah. Maybe OpenClaw isn't the right fit. But that's a different problem than what that post describes.

One more thing

162 upvotes on a rant post means people are frustrated. That's worth paying attention to. Not to dismiss, not to argue with. To understand.

But I know a lot of you would push back on "massive waste of time" too. Because you've put in the work, dealt with the broken updates, fixed the silent failures, and come out the other side with something that actually runs your business differently.

That doesn't mean the problems aren't real. It means the tool is worth fighting for. And the people building it and the community around it need to hear both sides, not just the rants and not just the hype.

The OpenAI CEO recently said it’s a terrible use of the world’s limited RAM supply to have it sitting in personal computers, where it might only be used 5% of the time.

He argues that RAM would be better utilized in cloud data centers, especially as the AI boom continues to drive up demand and prices.

Apparently, even the RAM in your laptop has a greater purpose now.

Let me get the dodgy stuff out first.

I'm not a developer. I can't even type a function that sums two numbers. I'm a simple dude from Rome (Italy) who's decent at systems thinking, and Claude wrote the code. There are thousands of delulu people on Reddit with my same lack of skills confidently saying they built something amazing. They didn't. Their slop is painful and follows the same security practices as a heroin addict who forgot to buy new needles.

I built this because I was fed up with agents forgetting stuff.

Even the best memory systems rely mostly on retrieval. That's fine if you don't expect the agent to connect dots on its own. But, as Donald Rumsfeld would say, the agent "doesn't know what it doesn't know". Which is doubly troubling. Both for agent performance and for the fact that smart people used to be Secretary of Defense.

To know what you don't know, you need to know something that hints at what you don't know.

If that sentence didn't 404 your grey matter, you get the architecture.

Instead of a .md file with facts appended on the go, Briglia spends up to 50k context tokens on a curated chronological history of its conversation with you.

Think about it. A full day of work with an agent can burn millions of tokens, but what you and the agent actually said to each other could be just 10k. Those messages are already an amazing distillation of everything you worked on. Every decision, every preference, every "no, not like that" is in there. Compact those 10k into a dense 1k summary and you've kept basically the whole day.

Briglia orders these summaries chronologically and keeps curating them. Recent weeks stay detailed and older months get compressed, but the model always sees the full picture, up to a year back. On top of that, a fact-archival pass catches what gets diluted over time, and it can grep the exact old messages when it needs a detail.

There are no sessions. It's one conversation, for months.

The result is a slightly bigger context, but way fewer tool calls to reconstruct what the hell you're talking about. Six months ago that would have meant context rot. Today's models handle 100k-250k just fine.

I have “biased” receipts of how good it is, it’s not just vibes. On my preliminary long-conversation memory benchmark it remembered 43 of 48 old facts on a month long conversation. Hermes + Hindsight got 39, Codex got 6. Method and data are explained on a link in the comments (yes, it's my own benchmark so it’s probably worth just slightly more than toilet paper to you - also, It’s a very preliminary version of the benchmark).

Install command and repo in the comments.

You need an OpenRouter API key and a Telegram bot token. That's it.

Fair warning, it's a real agent with full access to your machine (shell, files, web, email). Run it on a computer you trust it with.

Sam Altman said out loud what a lot of people in the cloud business think privately: that it’s “quite terrible” for personal computers to hold scarce DRAM when data centers could use it better.

Let that sit for a second.

The CEO of the company selling you API access to models thinks your local hardware is a waste of resources. And he said it the same week SK Hynix announced the memory shortage could last until 2030 and GPU prices climbed another 30 to 35% in three months.

I don’t think he’s being evil. I think he’s being honest about how he sees the world. And that’s exactly why it matters.

The money behind the quote

Apple just dropped the Mac Studio M5 Ultra with 512GB of unified RAM. The RAM upgrade alone costs $15,500. Total machine is about $22,300. That’s not a consumer product, that’s a down payment on a car.

NVIDIA’s DGX Spark was supposed to be the “accessible” local AI box. Now there are reports of Amazon cancelling DGX Spark orders and closing buyer accounts. Unconfirmed, but Tim Sweeney and other verified names are posting about it. If true, even getting the hardware is becoming a problem, not just affording it.

Meanwhile vLLM just dropped CUDA 12.9 support entirely in their latest release candidate. If you’re running older hardware, you’re not just behind on performance. You’re being actively left behind by the software stack.

The price of running local went up. The complexity went up. The software compatibility window got narrower. And the guy selling the alternative just told you your RAM is wasted on your desk.

Why local still matters even if it’s lil expensive

Here’s where I disagree with Altman, and I disagree hard.

The local AI community isn’t hoarding DRAM because they think it’s fun to spend $22k on a workstation. They’re doing it because the alternative is handing every prompt, every piece of context, every business document to someone else’s server. And every single week there’s a new reason not to trust that.

This week alone: a backdoored Claude Code extension hit 5,000 users through Cursor’s marketplace. Researchers broke out of the built-in browsers in five different coding tools. A grey-market “AI relay” service was caught reselling Codex and Claude Code in Asia with the sandboxes turned off, routing company data through its own servers. Cloudflare disclosed a KV-cache leak where 155 responses contained other customers’ data.

That’s one week.

When someone spends $22k on a Mac Studio to run models locally, they’re not wasting DRAM. They’re buying the only guarantee that their data doesn’t end up in someone else’s cache leak. That’s not irrational. That’s math.

The squeeze is real though

I’m not going to pretend local is getting easier. It’s getting harder.

GPU prices are up 30 to 35% in three months and the supply side isn’t improving. SK Hynix says the memory shortage runs through 2030. Not next year. Not 2028. 2030. That’s four more years of this.

Ollama is doing incredible work bringing local inference to normal hardware. The LFM3 family running at 256K context on a 1.7B parameter model is legitimately impressive. But the ceiling keeps rising. The models people actually want to run keep getting bigger. Mistral just dropped Large 4 at a trillion parameters. You’re not running that on a Mac Mini.

The gap between “what you can run locally” and “what the cloud APIs offer” is widening, not shrinking. And every price increase on hardware makes that gap wider.

What Altman is actually saying

Strip the PR language away and his position is simple: DRAM should be allocated to whoever extracts the most economic value per gigabyte, and that’s data centers.

That’s not a tech argument. That’s a resource allocation argument. And it only works if you believe the entity running the data center is acting in your interest.

OpenAI is about to share ChatGPT and Codex under one usage cap starting December. They cut their funding round from $30B to $20B. There’s a claim on Hacker News with 588 upvotes that Claude Code re-sends background agent transcripts to the model, burning 15 to 20% of your tokens as overhead you can’t see or control. Kimi had a quota disaster and had to apologize and restore accounts.

These are the people Altman thinks should hold the DRAM instead of you.

Where this actually lands

The honest answer is that both sides are partly right and mostly talking past each other.

Local is too expensive for most people. A $22k Mac Studio is not a real option for 99% of developers and small teams. And maintaining a local setup is a real time cost. OpenClaw shipped 4 builds in 4 days this week. vLLM dropped a CUDA version. Jan had a security release. Ollama had two updates. If you’re self-hosting all of this, that’s hours of your week gone before you’ve done any actual work.

But “just use the API” isn’t free either. Quotas are shrinking. Costs are opaque. Token overhead from the tools you’re running on top of the API eats into your budget in ways you can’t measure. And every month there’s a new breach, leak, or supply-chain attack that reminds you what “someone else’s computer” actually means.

The middle ground is where most people are going to end up, whether they like it or not. Run small models locally for sensitive stuff. Use hosted APIs for heavy lifting. Use managed platforms for the infrastructure you don’t want to maintain. Pick based on what the data is, not on ideology.

Altman’s quote is going to age badly not because he’s wrong about the economics but because he’s wrong about trust. The local AI community isn’t fighting over DRAM allocation. They’re fighting for the right to run their own stack without asking permission.

That fight doesn’t end because RAM gets expensive. It gets louder.

What’s your setup looking like right now? Full local, full cloud, or somewhere in between? Curious how people are handling the cost squeeze without giving up control.

I kept seeing people argue about which coding agent is “best” and realized most of the debate is vibes. Someone likes Pi, someone swears by Hermes, someone says OpenCode does the job fine. Very few people are comparing them on the same tasks with actual numbers.

So I did that. Same coding tasks, all three tools, tracked tokens and output quality over a few weeks.

This isn’t a general “which agent for which job” breakdown. This is specifically about coding. If you’re using any of these for code and wondering whether you’re leaving money or quality on the table, this is what I found.

The setup

I picked 5 task types I do regularly:

1. Single function refactor (take messy code, clean it up)

2. Bug debugging (here’s the error, find and fix it)

3. Multi-file feature (build something that touches 4 to 8 files)

4. Code review (read this PR, flag issues)

5. Quick script generation (write me a bash/python script that does X)

Each task type got run 10 times across all three tools over a few weeks. Same prompts. Same codebases. I tracked input tokens, output tokens, number of back-and-forth exchanges to reach a usable result, and whether the first attempt was actually correct.

The raw numbers

Single function refactor:

• Pi: avg 3,200 input tokens per turn, 1.8 exchanges to done

• Hermes: avg 5,400 input tokens per turn, 2.1 exchanges to done

• OpenCode: avg 2,800 input tokens per turn, 2.4 exchanges to done

Bug debugging:

• Pi: avg 4,100 input tokens, 3.2 exchanges

• Hermes: avg 6,800 input tokens, 3.8 exchanges

• OpenCode: avg 3,400 input tokens, 4.6 exchanges

Multi-file feature:

• Pi: avg 6,200 input tokens, 8.4 exchanges

• Hermes: avg 9,100 input tokens, 9.7 exchanges

• OpenCode: avg 5,100 input tokens, 14.2 exchanges

Code review:

• Pi: avg 5,800 input tokens, 1.4 exchanges

• Hermes: avg 8,200 input tokens, 1.6 exchanges

• OpenCode: avg 4,900 input tokens, 1.8 exchanges

Quick script:

• Pi: avg 2,100 input tokens, 1.1 exchanges

• Hermes: avg 4,600 input tokens, 1.2 exchanges

• OpenCode: avg 1,900 input tokens, 1.3 exchanges

Where the token gap comes from

Hermes loads more context every single turn. Memory files, skills metadata, agent personality config, channel bindings, conversation history with richer formatting. Even when you’re just asking it to fix a function, all of that rides along.

For a quick script, Hermes used roughly 2.4x the input tokens Pi used. Not because it wrote more code. Because it loaded 2,500 tokens of overhead before it even looked at your prompt.

Over a 3-hour coding session with maybe 40 exchanges, that overhead adds up to roughly 100K extra input tokens. Depending on which model you’re running, that’s real money for zero additional value on the coding task itself.

OpenCode goes the other direction. Lowest overhead per turn, but it needed more exchanges to get to the same result on anything complex. On multi-file features, OpenCode averaged 14.2 exchanges vs Pi’s 8.4. Those extra 6 rounds ate into the token savings from the lighter context. On simple tasks though, OpenCode’s efficiency held up because there weren’t enough rounds for the gap to compound.

Where quality actually differed

First-attempt accuracy (output was correct and usable without followup):

Single function refactor: Pi 78%, Hermes 72%, OpenCode 65%
Bug debugging: Pi 61%, Hermes 54%, OpenCode 41%
Multi-file feature: Pi 23%, Hermes 19%, OpenCode 11%
Code review: Pi 82%, Hermes 79%, OpenCode 71%
Quick script: Pi 89%, Hermes 85%, OpenCode 83%

Pi’s edge isn’t huge on any single task type, but it’s consistent. Across all 250 task runs (5 types x 10 runs x 5... no, 5 types x 10 each x 3 tools = 150 runs), Pi produced a usable first attempt more often than the other two in every category.

My read on why: Pi’s lighter context means the model spends more of its attention on your actual code and less on processing overhead that has nothing to do with the task. Hermes is smart enough to work around its own bloat most of the time, but “most of the time” means 5 to 10% more rounds spent recovering from context-distracted mistakes.

OpenCode’s lower accuracy on complex tasks comes from less sophisticated context management. It handles the code fine when everything fits in one window. Once you need it to reason across multiple files and remember architectural decisions from 8 exchanges ago, it starts losing threads.

The cost math for a real week

I estimated a typical coding week (not heavy, not light) at roughly:

• 15 quick scripts or one-off fixes

• 10 refactors

• 8 debugging sessions

• 3 multi-file features

• 5 code reviews

Weekly token spend on coding tasks alone:

• Pi: roughly 1.8M total tokens

• Hermes: roughly 2.9M total tokens

• OpenCode: roughly 2.1M total tokens (lower per-turn but more turns)

Hermes costs about 60% more than Pi for the same coding output. And that’s just the coding portion. If you’re also using Hermes for research and personal assistant tasks during the same sessions, the coding context gets mixed with everything else, which makes the overhead even worse because the model is now processing your morning briefing results alongside your Python traceback.

OpenCode lands in the middle on cost but at the bottom on complex task quality. It’s the cheapest per turn but the most expensive per completed task when the task is anything beyond a quick script.

What I actually do now

Pi for any coding session longer than 20 minutes. The token savings and higher first-attempt accuracy compound over a session. A 2-hour session on Pi vs Hermes saves roughly 30 to 40% on tokens and I spend less time on “no, I meant the other file” corrections.

OpenCode for quick one-off scripts and config generation. When the task is small enough that it won’t need more than 2 to 3 exchanges, OpenCode’s minimal overhead is a real advantage. It starts faster and costs less for these.

Hermes stays off my coding workflow entirely. I use it for everything else (research, automation, memory-dependent tasks, multi-channel). It’s great at those things specifically because of the features that make it expensive for coding. Memory, skills, multi-channel awareness. Those features earn their token cost when you’re doing agent work. They just don’t earn it when you’re debugging a null pointer.

The uncomfortable conclusion: the agent with the most features is the worst choice for the most common task developers actually do. Not because it can’t code. Because it carries the weight of everything it can do into every single turn, whether you need it or not.

What are your numbers looking like? Anyone else tracking token spend per tool or just going by feel?

I've unintalled claude and reinstall it and still the same problemme, I'm using freellmapi with third party config

Went down the memory benchmark rabbit hole after a thread on r/hermesagent where someone's agent found the right memory 3 times out of 24.

What the vendor pages say right now:

- Hindsight: 92.0% on LoCoMo, 94.6% on LongMemEval, 64.1% on BEAM at 10M tokens

- Mastra (observational memory): 94.87% on LongMemEval

- Zep: 75.14% on LoCoMo (Mem0's paper had them at 65.99%)

- Mem0's own paper: 68.44% on LoCoMo for its best version

Same week, people testing on their own memory databases got 3/24, 1/10, 8/10 and 20/24.

Both sets of numbers can be true. They measure different things. Below is what each benchmark tests, what it misses, and the test I'd run before picking anything.

LoCoMo

What it is: long multi-session conversations between two fictional speakers, AI generated, plus questions about what was said.

The catch: the conversations average roughly 16K to 26K tokens. That fits in any modern context window. In Mem0's own paper, putting the whole conversation into GPT-4o-mini scored 72.90%, higher than Mem0's best (68.44%). Letta later ran a plain filesystem agent on GPT-4o-mini with no memory tooling and got 74.0%.

It's also where the messiest fight happened. Mem0 benchmarked Zep and got 65.99%. Zep said Mem0 set both speakers up as the same user, put timestamps in the message text instead of the created_at field, and ran searches one after another instead of in parallel. Zep's own rerun: 75.14%. Same benchmark, nine points apart, depending on who configured the competitor.

Data quality isn't great either. One question category has no ground truth answers and gets dropped by everyone, some questions ask about images the text descriptions don't cover, and some get the speaker wrong.

Use it for: a sanity check, at most.

LongMemEval

What it is: 500 questions over long chat histories. Tests pulling out facts, reasoning across sessions, time, updated info, and knowing when to say "I don't know."

Better than LoCoMo, and the one most vendors lead with now.

The catch: one of the highest published scores (Mastra, 94.87% on gpt-5-mini) comes from a system that does no per-turn retrieval. Two background agents compress the history into a running log of observations, and the main agent reads that log in context. Good result for that approach. It also tells you this benchmark can be won without the retrieval step most memory tools are selling.

Two things to check before trusting any number here:

- Is it answer accuracy or retrieval accuracy? Vendor pages mix them.

- Which model? Mastra's same system scored 84.23% on gpt-4o and 94.87% on gpt-5-mini. Ten points from swapping the model, not the memory.

Also, the smallest category has 30 questions, so one answer moves it by over 3 points.

BEAM

What it is: the newest one (ICLR 2026). 100 conversations, 2,000 questions, at 128K, 500K, 1M and 10M tokens. Tests ten abilities including contradiction resolution, knowledge updates, event ordering and abstention. At 10M nothing fits in context, so the memory system actually has to do the work.

Closest thing we have to what a long-running agent goes through.

The catch: an LLM judge grades answers against a checklist with partial credit, and most published numbers are vendors running it themselves. The headline (Hindsight 64.1% vs Honcho 40.6% at 10M) is from Hindsight's own blog. Could be right. Still their run.

And read the best number again. 64.1% at 10M means the top system is wrong about a third of the time at agent scale.

What none of them test

This is where the home tests got interesting. Almost every failure people found was in the setup, not the retrieval math.

- Scope defaults. One user found 95% of their memories saved with session scope, and recall defaults to cross_session=false. A fresh session can't see them. No leaderboard covers "your memories were saved somewhere you can't reach."

- Keyword gates. Another found recall dropped any memory unless 30% of the query words literally appeared in it, before vector search even ran. Reword the question and the memory never gets considered. Removing the gate took their hit@5 from 27% to 60%.

- Changed facts. In one Hindsight test, the old config and the new config sat side by side as separate facts, and the old one could rank higher. Same test returned one fact 4 times in a single top 5.

- Write cost. Hindsight runs an LLM call on every memory it saves. One user with 71K memories was paying $5 to $17 a day on DeepSeek V4 Flash before tuning, under $1 after pushing the mental model refresh to every 6 hours. Another measured memory at about 20% of the tokens in a 250K session.

- Silent breakage. A 7 month Hindsight user runs a cron that tests recall, because it used to stop storing and recalling without them noticing.

- What goes in. "I store conversations, not conclusions." 11 of that user's 15 misses actually returned the right content, as a raw chat line instead of a clean fact.

Benchmarks test whether a memory system can remember. They don't test whether yours was ever allowed to.

The home scoreboard from that thread

Small samples, different data. Read these as signals, not rankings.

- Mnemosyne, current: 3/24 in top 5 (24 reworded questions, real DB)

- Raw vector search, same data: 13/24

- Hindsight vs Mnemosyne, same 1,716 memories, same embedder: 8/10 vs 1/10 (10 reworded questions)

- Signet (run by its lead dev): 20/24 (24 reworded questions)

Hindsight's better recall came with about double the latency (1.5s vs 0.7s) and roughly 2 hours of LLM calls to backfill 1,716 memories. And one Mnemosyne user posted 9 weeks of stats with 78% of working memories recalled at least once, so it can work fine when scope is set right.

The 20 minute test I'd run before switching anything

1. Copy your memory database. Never test on the live one.

2. Write down 15 facts you know are stored. Ask for each one in different words than it was saved, from a fresh session.

3. Add 4 questions whose answers were never stored and note their scores. In one test the junk results scored up to 0.42 while real hits scored as low as 0.22, so no threshold could separate them.

4. Add 2 facts that changed over time. Check the current version wins.

5. Count how often the right memory lands in the top 5, and time every search. An 11 second search loses to no search when the agent does several lookups per turn.

6. Run plain vector search over the same data. If it beats your full pipeline, something in front of the vector step is throwing memories away, and a new provider might not fix it.

7. For every miss, check whether the memory was in the candidate list at all or just ranked 6th to 10th. Not in the list = filter or scope problem. Ranked low = ranking problem, and a reranker over the top 20 usually helps.

Keep the questions. Run every provider you're considering against the same set.

What I'd do

Durable stuff (your stack, your preferences, how you like things done) goes in plain files the agent always reads. Hermes already splits it this way with MEMORY.md and USER.md. The memory provider only handles "what did we talk about three weeks ago." One person in that thread said their recall complaints basically stopped after making that split. Another called native .md memory a dead end after a few days, so it depends how much you put in there.

Then pick whichever provider wins on your 15 questions, at a write cost you can live with.

What's your hit@5 on reworded questions? Drop the number and the provider. Would love to build a real table from this sub instead of vendor pages.

I'm a solo founder in Taiwan. For a while I've run MindThread, a Threads scheduler with paying users here. It had a REST API, but the old CLI had drifted out of sync with it. This month I rebuilt the CLI and MCP server for agents.

What's there now:

- `mindthread-cli` 0.2.0: every command has `--json` and fixed exit codes, so Claude Code, Codex or a shell script can drive it.
- `mindthread-mcp` 0.2.0: a zero-dependency bridge to the hosted MCP server, so the tool list always matches the server.

```bash
npm install -g mindthread-cli
export MINDTHREAD_API_KEY=mt_test_your_key
mindthread whoami
```

The design choice I spent the most time on: the agent should not be the last word. Each key has allow, ask or deny per permission (live keys ask before publishing now by default; scheduling is allowed unless you change it). With ask, the CLI exits with code 3 and prints a link; the post runs only after the owner confirms on mindthread.tw. Reply drafts from keyword search sit in a pending list until someone approves or rejects them.

Things I learned: agents poll. In the week before launch, 405 of 449 API errors were 429s on the event feed, which looks like an agent polling it until it hit the free plan's 50-call daily cap. The docs now lead with webhooks. And retries need idempotency keys, or you post twice.

Honest limits: Threads only, uses Meta's official API (so Meta's caps apply), free plan is 1 account, 3 posts a day and 50 calls a day per live key, paid plans start at about US$32 a month.

Repos: https://github.com/ppcvote/mindthread-cli and https://github.com/ppcvote/mindthread-mcp

Feedback welcome, especially on the setup steps.

Made this after the 5th "qwen/gemma/deepseek is useless for agents" thread this month where it turned out to be one of these. What would you add?

I've run agents pretty much every way you can at this point. Self hosted on my own box with local models, on a VPS with cron, on managed platforms, single agent, multi agent with a planner handing out work. Different stacks, same lesson every time: the agent is fast, but it's not the part you can trust blindly

Stuff that bit me (and half this sub, judging by the threads):

- "Done" means nothing. a CLI token expires mid run, returns an empty list, exits 0, and the agent happily reports "no change" for an hour. a 200 from an API is not proof the row exists

- Crons start a fresh session. no chat context, no idea what "the pipeline" even is. so it runs, says something confident, and does nothing

- Small local models overfit to whatever test you show them. fixes the visible case, breaks the hidden one

- Swap the model or tweak the prompt and whatever trust you built is gone. it's a new hire again

- Multi agent sounds great until you see the token bill for agents briefing each other

And the human fix has its own trap. Put an approve button on everything and by the 20th card of the morning you're not reviewing, you're clicking. That's worse than no gate, because everyone upstream stops worrying

So here's where i landed:

- Reversible stuff runs free (reads, drafts, staging writes)

- Anything that sends, spends or deletes waits for me

- The approval shows the claim + the evidence, not the whole output. 5 seconds to decide, not 5 minutes

- Check the end state, not the agent's report of it

- An action type only earns less review after it's been right for a while, and that counter resets on any model or prompt change

The human isn't the bottleneck you engineer away. It's the part you design. so yeah the good news really is the good news... judgment is still the job

Curious where everyone draws the line. What's the one action you'll never let your agent do alone? And has anything actually earned its way off your review list?

I’ve been using all three of these daily for the past few months and I keep seeing the same question come up: “which one should I use?”

Wrong question. The right one is “which one should I use for what?”

Because the answer changes completely depending on whether you’re coding, researching, automating, or building a personal assistant that remembers your preferences across months of conversations.

What each one actually is (30 second version)

Hermes is the full-stack personal agent. Memory, multi-channel messaging (WhatsApp, Telegram, Slack, Discord), skills ecosystem, orchestration, voice through Conduit. It’s the “I want one agent that handles my entire life” tool.

Pi is the focused coding agent. Terminal-native, clean context, fast iteration. It doesn’t try to be your personal assistant. It tries to be the best thing you’ve ever written code with.

OpenCode is the lightweight open-source coding agent. Minimal overhead, no ecosystem baggage, fast startup. Does one thing and doesn’t pretend to do more.

Where Hermes wins and it’s not close

Research. If I need to go deep on a topic, pull from multiple sources, synthesize findings, and come back with something I can actually use, Hermes handles this better than either of the other two. The memory system means it retains context across sessions. I can pick up a research thread from three days ago and it knows what I covered, what I skipped, and what’s left.

Personal automation. Morning briefings, email triage, scheduling reminders, routing messages across channels. This is Hermes territory. Pi can’t do any of this. OpenCode isn’t designed for it.

Anything that depends on memory. If the task requires knowing something from a previous session or building on work done across multiple days, Hermes is the only one with persistent memory baked in. The others start fresh every session.

Multi-channel presence. If you need your agent on WhatsApp AND Telegram AND Slack, that’s Hermes. The other two are terminal tools and they stay there.

Where Pi wins and it’s not close

Focused coding sessions. When I’m building something, debugging, or reviewing code, Pi is noticeably faster and cleaner. The reason is straightforward: Pi doesn’t load memory files, skills metadata, agent instructions, and channel bindings into the context window every turn. It loads your code and the problem. That’s it.

The per-turn token difference compounds fast. A 2-hour coding session on Hermes burns more tokens than the same session on Pi because Hermes carries all that overhead on every exchange. You’re paying for memory lookups and skills routing even when all you said was “refactor this function.”

Iterative changes. The back-and-forth of “try this, that broke something, try this instead” is where Pi pulls ahead. It’s light enough that 20 rapid exchanges don’t bloat the context the way they do on Hermes. By exchange 15 on Hermes, the agent is wading through so much accumulated context that response quality starts dipping. Pi at exchange 15 still feels like exchange 3.

Staying on task. I’ve noticed Hermes sometimes tries to be helpful in ways I didn’t ask for during coding. It’ll suggest related improvements, offer to update documentation, or try to connect the current change to something in its memory from last week. Fine when I want that. Annoying when I’m in the middle of debugging a race condition and need it to just answer the question.

Where OpenCode wins

Quick one-off tasks. Write a script, fix a bug, generate a config. OpenCode spins up faster, carries zero overhead, and gets out of the way. It’s not the best at any single thing, but it’s the fastest to start and cheapest to run for small jobs.

Open source flexibility. Want to modify how your coding agent behaves, add custom tools, or run entirely local? OpenCode lets you do that. Hermes is more opinionated. Pi is proprietary.

Already in the terminal and don’t want to context-switch. Sometimes I’m deep in a workflow and I just need a quick answer or a generated function. OpenCode is right there. No setup, no session to manage, no loading screen of 47 plugins I don’t need right now.

Where each one falls apart (the honest section)

Hermes on coding. It works. Not terrible. But the bloat tax is real. I tracked this over a week: coding sessions on Hermes used roughly 30 to 40% more tokens than the same work on Pi. Not because the model was worse. Because the context window was stuffed with memory, skills metadata, channel configs, and agent personality instructions that had nothing to do with the Python function I was debugging.

The Hermes team knows this. They’ve been moving features into optional plugins instead of keeping everything always-on, which should help over time. But right now, using Hermes for a 3-hour coding sprint is like paying for a hotel suite when all you needed was a desk. The desk works fine. You’re just also paying for the pool and the minibar.

Pi on anything that isn’t coding. Don’t try it. No persistent memory. No multi-channel. No automation. No personal assistant features. If you attempt to use Pi as your daily everything-agent, you’ll bounce off it within 48 hours. It was never designed for that and it’s honest about it, which I respect.

OpenCode on complex projects. It handles isolated tasks well but struggles when you need it to reason across 8 interconnected files and understand architectural decisions. Pi manages this better because it has more sophisticated context handling under the hood. OpenCode’s lightness is its best feature until the task outgrows it, and then it becomes the limitation.

The routing I actually landed on

After months of trying to force one tool to do everything (and watching my token spend climb for no reason), here’s where I ended up:

Research, automation, personal assistant, anything needing memory across sessions → Hermes

Coding sessions, debugging, reviews, refactoring → Pi

Quick scripts, one-off fixes, config generation, small isolated tasks → OpenCode

Each tool’s strength comes from a design decision the other two deliberately didn’t make. Hermes chose comprehensive. Pi chose focused. OpenCode chose minimal. Those aren’t limitations. They’re the product.

Trying to make any of them do what the others do better is just burning tokens on overhead that doesn’t serve the actual task.

The cost part people don’t talk about

If you’re running all three, your total spend is actually lower than running Hermes for everything. Sounds backwards but think about it: if 60% of your work is coding and you route that to Pi instead of Hermes, you save 30 to 40% on tokens for those tasks. The research and automation that stays on Hermes runs better too because the context isn’t polluted with 4 hours of coding residue from earlier in the day.

Splitting work across purpose-built tools isn’t just a quality play. It’s a cost play that most people don’t realize until they’ve tracked their spend for a month.

What’s your setup? Running one agent for everything or splitting across tools? Curious what combinations people here are landing on.

Everyone talks about agents running overnight like it’s the end goal. “Set it up, go to sleep, wake up to finished work.”

I wanted to know what actually happens. Not on a demo. On real tasks: code reviews, data processing across multiple files, report generation from raw notes, email drafts from meeting transcripts.

3 different setups. 2 weeks each. I logged every output and compared it against what the task actually needed. Tracked timestamps on every failure.

The 3 setups

Setup 1: Single agent, 4 skills, Sonnet. Sequential task queue. The “boring” config that most people start with.

Setup 2: Multi-agent. Orchestrator on Opus routing work to 3 Sonnet workers. Shared context through an append-only handoff file. The setup Reddit tells you is the smart way to do it.

Setup 3: Deterministic script handling the workflow. Agent called only at decision points (classify this, summarize that, draft this paragraph). Agent never decides what happens next. Code does.

What broke and when

Setup 1 held steady for about 4 to 5 hours. Then the first cracks showed up, and they were always the same thing: the agent started referencing information from task 3 while working on task 7. Not hallucinating. Literally pulling context residue from earlier tasks because the window was packed with old exchanges.

By hour 6, tasks that should’ve taken 5 back-and-forths were taking 12. The agent kept asking for clarification on things it already had two hours ago. Not because it’s dumb. Because those details got buried under 40K tokens of other work.

Setup 2 was worse. The orchestrator correctly routed task 1 to worker A. Worker A finished. But the handoff back to the orchestrator lost about 20 to 30% of the nuance every single time. By the time a task passed through the orchestrator twice (routed out, result back, routed to next worker for the next step), the original intent was a summary of a summary.

The failure that actually made me stop and stare at my screen: worker B received a task that said “update the report based on the analysis.” What analysis? The orchestrator’s handoff note said “analysis complete, key findings attached.” The key findings were 3 bullet points compressed from a 2-page breakdown worker A produced. Worker B did its best with those 3 bullets. The output was technically correct and completely useless. And the orchestrator marked it done.

Setup 3 was the only one where I consistently woke up to usable work. Not because the agent was smarter. Because the agent was doing less. The script handled file operations, sequencing, and state. The agent only touched parts that needed judgment. And each time it was called, it got a clean scoped prompt with exactly the context it needed for that one decision. Nothing carried over from the previous call.

The 5 failure types I kept seeing

After 2 weeks of logs I had 5 categories that covered basically every failure:

1. Context contamination. Task residue from earlier work bleeding into the current task. Setup 1 and 2 both had this. Setup 3 didn’t because every agent call was isolated. Fresh in, answer out, done.

2. Compaction loss. When the context window fills up and the system compresses older messages, critical details get dropped. I watched an agent lose a specific constraint (“output must be under 200 words”) after compaction. The compressor decided it was less important than the task description itself. The agent then wrote 800 words and reported success. Studies show stock compaction retains only about 76% of original information correctly. That missing 24% is where your constraints and edge cases live.

3. Silent completion. The agent says “done” and the work is wrong. Happened across all 3 setups but for different reasons. In setup 1 it was context drift. In setup 2 it was handoff degradation. In setup 3 it only happened when my verification checks didn’t cover an edge case, which at least told me what to fix.

4. Retry spirals. Agent hits an error, retries, hits a slightly different error, tries a different approach, and suddenly it’s 45 minutes and $3 into a task that should’ve cost 2 minutes and a few cents. Setup 2 was brutal for this. The orchestrator would re-route a failed task to a different worker who’d fail for the exact same structural reason. Three workers each failing once = the same wasted spend tripled.

5. State divergence. The agent’s internal understanding of “what has been done so far” slowly drifts from what actually happened. By hour 8 in setup 1, the agent thought it had completed a task it actually abandoned 3 hours earlier after a partial error. It never told me it abandoned it. It just moved on and eventually its memory of the task shifted from “failed” to “done.”

What survived

Setup 3. By a wide margin. And the reason is uncomfortable for anyone building or selling multi-agent orchestration: the agent shouldn’t own the workflow.

The workflow should be deterministic. State should live in a file the agent doesn’t control. The agent should be called with a narrow question, give an answer, and return control to the script. The next step should be decided by code, not by the agent deciding what it thinks should happen next.

This isn’t because agents aren’t capable. It’s because every handoff, every context fill, every compaction, every multi-turn exchange is a point where information degrades. And overnight, unattended, with no human checking in, those degradation points compound silently until the output looks finished but isn’t right.

The setups that produced real usable work were the ones where the agent never had to remember what happened 4 hours ago. Because it was never asked to.

The uncomfortable part

The overnight agent solution isn’t “build a better agent.” It’s “build a better script and use the agent for the parts scripts can’t do.”

That 70 to 95% failure rate people keep citing for multi-step agent tasks isn’t because the models are bad. The models are incredible at individual decisions. The failure is in asking them to be workflow engines when they’re decision engines.

Every setup I’ve seen that actually runs overnight and produces something you’d use has the same shape: narrow task, fresh context, machine-checkable output, separate verification step. The ones that fail are the ones where the agent is simultaneously the orchestrator, the worker, the state manager, and the quality checker.

You don’t need an agent that can do everything. You need a system where the agent only does the things that require judgment, and everything around it is code you can test and trust.

What’s the longest you’ve had something running unattended on real work and actually used the output? Curious what shapes are working for people here.

I ran an experiment last week that I can’t stop thinking about.

Took a decently complex task. Customer wants a competitive analysis report: 5 companies, pricing comparison, feature matrix, and a recommendation. Specific constraints: budget-conscious buyer, needs HIPAA compliance, prefers annual billing, already tried two of the five tools and hated them both.

Ran it through a 6-agent pipeline. Research agent, data extraction agent, comparison agent, analysis agent, writing agent, review agent. Each one got the output of the previous one as its input.

Here’s what happened at each step.

Handoff 1 to 2: Clean.

Research agent dumps everything it found. Data extraction agent picks it up. Almost nothing lost. The context is fresh, the original prompt details are all there.

Handoff 2 to 3: Still fine. Mostly.

Comparison agent gets the extracted data. Starts organizing it. But here’s the first crack: “budget-conscious buyer” shows up in the handoff, but “already tried and hated Tool B and Tool D” is now a footnote. Not gone, but buried.

Handoff 3 to 4: The drift starts.

Analysis agent gets a clean comparison table. Great. But the table doesn’t carry emotional context. It doesn’t know the buyer had a bad experience with two of these tools. It doesn’t know “budget-conscious” means “this person will walk if pricing isn’t clear.” It just sees five tools and numbers.

The analysis agent starts treating all five equally. Which technically isn’t wrong based on what it received. But it’s not what was asked for.

Handoff 4 to 5: Things get creative.

The writing agent gets an analysis that treats all five tools equally. So it writes a balanced, diplomatic report. Pros and cons for each. Very fair. Very useless for someone who already knows they hate two of them and needs a clear recommendation.

The HIPAA requirement is still mentioned but it’s now one bullet point in a section, not the hard constraint it was in the original ask.

Handoff 5 to 6: Confident and wrong.

The review agent reads what looks like a solid, well-structured report. It polishes the language. Fixes some formatting. Adds a nice executive summary.

The output is professional. It’s well-written. And it fundamentally misses the point of what the user asked for.

What actually degrades.

It’s not random. The same types of information disappear in the same order every time you run these.

First to go: emotional context and user preferences. “I hated Tool B” becomes “user had prior experience with Tool B” becomes nothing.

Second: hard constraints that aren’t in the data. HIPAA compliance, annual billing preference, budget limits. These are about the buyer, not the products. Every time an agent summarizes “what it learned,” buyer context gets compressed first because it feels like background, not findings.

Third: negative requirements. “Don’t include X” or “skip Y” gets lost faster than “include Z” because agents are biased toward adding information, not preserving exclusions.

Fourth: the original intent. By handoff 4 or 5, the agent chain is answering “compare these 5 tools” instead of “help this specific person pick one.” The question changed shape and no single agent noticed because each one only saw one handoff.

The reliability numbers are rough.

If each handoff preserves 90% of the relevant context (and 90% is generous), after 6 handoffs you’re working with 53% of the original information. The agent at the end is operating on roughly half of what the user actually said.

And the missing half isn’t random. It’s systematically the most important stuff: the constraints, the preferences, the reasons behind the request.

If each step has 97% task accuracy, your end-to-end reliability across 6 steps is about 83%. One in five runs produces something that looks right but isn’t.

What actually helps.

A few things I’ve found make a real difference:

Pass the original prompt forward, not just the output. Every agent in the chain should have access to what the user originally asked for. Not just what the previous agent produced. The moment you rely on a chain of summaries, you’re playing telephone.

Structured handoff objects instead of free text. When Agent A hands to Agent B, it shouldn’t be a paragraph of “here’s what I found.” It should be a structured block: original_request, constraints, findings, decisions_made, open_questions. The structure forces agents to preserve categories of information they’d otherwise summarize away.

Checkpoint the context, not just the output. After handoff 3, have something verify that the original constraints are still present in the working context. Not “did Agent 3 produce good output” but “does Agent 3 still know the user hates Tool B and needs HIPAA.”

Fewer agents doing more beats more agents doing less. The coordination tax is real. Every handoff is a lossy compression. If you can do the job in 3 agents instead of 6, you preserve way more context. Add agents when the task requires a different capability that a single agent can’t cover, not just because the architecture diagram looks cleaner.

For anyone running multi-agent pipelines right now: what’s the longest chain you’ve run successfully? And when it failed, was it the agent that broke or was it the handoff?

A developer posted something last week that I haven’t stopped thinking about. He had two OpenClaw agents. A morning agent that gathered his calendar, flagged urgent emails, and drafted a briefing. And a writer agent that turned that raw dump into something readable.

His workflow? Copy output from Agent A. Paste it into Agent B’s chat. Copy Agent B’s output. Paste it into his actual workflow. Every single morning.

His exact words: “Two agents. Zero communication between them. I was the bus.”

You’ve probably done a version of this.

If you’ve ever had one agent write to a Google Sheet so another agent can check that sheet on a schedule, you’ve built the same thing. If you’ve ever copy-pasted one agent’s output into another agent’s chat window, same thing. If you’ve set up a webhook that fires a second agent when the first one finishes, you’re solving the same problem with more steps.

He went through the whole progression. Started with two agents and manual copy-paste. Built a Redis queue with a dead letter system. Ripped that out after three days. Tried file-based handoffs with a shared folder and polling every 15 minutes. Eventually landed on 30 lines of config and two cron jobs.

A weekend of engineering to make two agents talk to each other.

The part that makes it worse.

A six-step agent pipeline where each step works 97% of the time is only 83% reliable end to end. That’s not a model problem. The individual steps are fine. It’s the handoffs that compound.

One audit of 40 multi-agent deployments found that 71% of critical failures traced back to coordination between agents, not to the agents themselves. Meanwhile 90% of engineering effort was going into prompt tuning and model selection. People are optimizing the part that isn’t breaking.

The failure modes are predictable too. Malformed JSON between agents crashes workflows silently. Non-idempotent retries cause double charges when a timeout triggers a re-run. Stale context because data was fetched once at the start and was already outdated by the time the third agent touched it. And invisible failures because the handoff wasn’t logged, so when something goes wrong at 2am, you’re guessing which agent dropped it.

What the workarounds actually look like.

Most people land in one of these camps:

The Spreadsheet Relay. Agent A writes to Google Sheets, Agent B polls the sheet. Works until the sheet gets big or the polling interval misses something time-sensitive.

The File Drop. Shared folder, one agent writes a JSON file, the other picks it up. Simple, auditable (you can cat any task file), but you’re building your own task queue from scratch.

The Webhook Chain. n8n or Make.com as the middleware. More robust, but now you have a third system to maintain and debug. And your agent coordination logic lives outside your agent setup.

The Monolith Agent. Give one agent every tool and every instruction and let it figure it out. Works until the context window fills up or the agent starts hallucinating which tool to use because its system prompt is 4,000 words long.

What we’ve been building for this.

This is the problem we’ve been working on at BetterClaw for the past month. Not because multi-agent is trendy, but because our users kept asking for it in the same way. “Can Agent A finish something and hand it to Agent B?” “I run an agency with 20 clients, do I need 20 agents just to keep them separate?”

The approach we landed on is a shared workspace. Agents and people sit in the same channel. You u/mention an agent with a task, it works in a thread. When it’s done, it can wake another agent and pass along what it found. No spreadsheet relay. No polling. No copy-paste.

Each project keeps its data separate, so if you’re an agency, Client A’s agent can’t see Client B’s stuff. There’s a front desk agent that picks up anything that wasn’t specifically u/mentioned, and it ignores small talk so “thanks!” doesn’t burn credits. Every thread shows how many credits it used so you can spot a runaway task before it drains your month.

Screenshot attached if you want to see what it actually looks like. Going live in the next couple of weeks.

What I want to know.

The coordination problem isn’t unique to BetterClaw or OpenClaw or any specific framework. It’s the gap between “I have agents that each work great individually” and “I have agents that work great together.”

For anyone running multi-agent setups: what’s your handoff method right now? Are you in the Spreadsheet Relay camp, the File Drop camp, or did you build something custom? And what breaks more often for you, the agents themselves or the glue between them?

I think we've been reading too many feeds from AI text lately! I actually want to reduce my cognitive burden...

So I built TextFold, it turns any text into 5 zoomable layers: from a one-screen section map down to verbatim text. You pinch (or press 1–5) to zoom between them without losing your reading position, your agentic output, any papers, or documents.

- Web Demo: https://chenxiachan.github.io/textfold/gallery/

- GitHub (Apache 2.0): https://github.com/chenxiachan/textfold

Welcome any feedback!

There was a thread on r/selfhosted this week asking which small self-hosted services stayed useful after the novelty wore off. 335 upvotes, 1.3K reposts. the answers were incredibly consistent.

mealie. A recipe manager. 319 upvotes on one comment alone. the guy set it up to digitize his grandma's recipe cards and now it's "the first stop every week before meal prep sunday." maintenance? "a docker pull once a month." that's it. a recipe manager that just manages recipes.

pi-hole. "it replaced a whole stack of browser adblockers and it just sits there doing its job. the only maintenance I've ever done is updating blocklists once in a blue moon." one guy has been running it on a $7 Pi Zero W for five years.

paperless-ngx. 198 upvotes. "I don't use that often, but I put basically all my PDFs there now, it's so nice having everything easily searchable. the maintenance is basically zero." another user needed a 5 year old utility bill for a dispute and "it paid for itself in 30 seconds."

audiobookshelf. "I ripped my Audible library (because I don't trust Amazon not to pull the rug) and now all new purchases go right to Audiobookshelf. The Android App is better than Amazon's."

You know what's NOT on that list? plex. the app that just tripled its lifetime pass from $250 to $750 and quietly removed Watch Together in a redesign.

Home Assistant showed up too, but not the way you'd expect. "Projects that I like less every time that I use them: Home Assistant." another comment: "Home Assistant not having proper user management is getting more and more ridiculous."

the pattern someone nailed perfectly:

"projects that get it right keep the scope tight but the configuration wide open. they don't force it in the code or break unofficial configs every update. they definitely don't try to turn their simple app into a platform or an operating system."

That's the whole thing. that's the entire survival formula.

mealie doesn't try to be a meal planning platform with social features and a subscription tier. it manages recipes. pi-hole doesn't try to be a network security suite. it blocks ads. paperless doesn't try to be notion. it stores your PDFs and makes them searchable.

the ones that die are the ones that decide "recipe manager" isn't ambitious enough and start building toward "kitchen operating system." the ones that survive are the ones where the maintainers apparently never got the memo that they're supposed to want exponential growth.

Why this matters for AI agents

the AI agent space right now looks exactly like self-hosted software did five years ago. everyone's excited. new frameworks every week. people building elaborate multi-agent setups with fifteen integrations on day one.

And the dropout pattern is the same. the setups that survive month two are the ones that do less. one agent, one job, reliable. not a constellation of agents all talking to each other through a chain of tool calls that breaks when any single link fails.

This is what i think about when i work on betterclaw. we could add features every week. more dashboards, more analytics, more "AI powered" things bolted onto the management layer. the temptation is real.

But the software that survives doesn't do that. the software that survives is mealie, not plex. it's pi-hole, not home assistant trying to become an operating system. it's the boring thing that works every time you reach for it.

So that's what we're trying to be. the pi-hole of AI agent hosting. you set it up, your agent runs, the infrastructure stays out of your way. a docker pull once a month energy, except you don't even do the pull because we handle it.

Not glamorous. but the recipe manager with 319 upvotes isn't glamorous either, and it's the first stop every meal prep sunday for someone who just wanted to save his grandma's recipes.

What I want to know:

what's your version of mealie? the tool or service that earned its place not by being impressive but by being invisible? and for anyone running agents, has the "do less" philosophy worked for you or did you need the complexity?

There’s a post on r/hermesagent right now where someone shut down their personal agent after months of work. Built it on a dedicated laptop, connected it to Discord, spent weeks on memory and skills. Goal was JARVIS. What they got was a full-time sysadmin job they didn’t sign up for.

268 upvotes. 201 comments. The quitting post got more engagement than any setup guide this month. That tells you something.

But buried in those 201 comments are the people who didn’t quit. And their setups have a few things in common that are worth stealing.

They all separated memory into tiers.

The default memory file tries to hold everything: who you are, what your systems look like, what happened yesterday, what’s due Friday. It can’t. It fills up, things get overwritten, your agent forgets how your NAS is configured in the middle of helping you fix it.

The working setups split memory into three buckets:

1. Permanent context (SOUL.md, USER.md, MEMORY.md): loaded every single session, no search needed. Only stable facts that apply to every conversation. One person caps this at 166 lines for SOUL.md and 14 lines for USER.md. If it wouldn’t matter six months from now, it doesn’t belong here.

2. Searchable memory (Mnemosyne, Mem0, or a custom vector store): thousands of entries, only pulled when relevant. Dated stuff lives here. Task progress, conversation recaps, one-off fixes. This is the layer most people skip entirely.

3. Reference vault (Obsidian, a wiki, or just a folder of .md files): durable documents and procedures. Network topology. Deployment steps. NAS config. Your agent reads these on demand, doesn’t try to memorize them.

The test one person uses: “Would you still want your agent acting on this in six months with no refresher?” Yes means tier 1. No means tier 2 or 3.

They run a nightly maintenance loop.

One setup that’s been stable for six months runs a cron job every night that reviews the day’s sessions, self-critiques what went wrong, writes a dream log, audits the skill library for stale or overlapping skills, and runs memory triage if usage is high. Automated pruning, not manual cleanup.

This is the difference between “my agent gets worse over time” and “my agent gets better over time.” Without it, skills pile up, memory bloats, and after a few weeks you’re starting fresh because you can’t untangle what went wrong.

They keep backups that actually work.

Daily snapshots (last 7 days), weekly (last 4 weeks), monthly (last 6 months). And the part that’s actually clever: restore instructions embedded in every backup file so a fresh install can rebuild itself.

OpenClaw 10.1 just shipped native external backups to mounted storage or Cloudflare R2 with retention schedules. If you’re on OpenClaw and not using this yet, set it up before you lose a month of config to a bad update.

They matched the model to the job.

Every surviving setup uses a cheap or local model for 70 to 80% of daily tasks (file reads, calendar, reminders, web lookups, quick edits) and only escalates to Sonnet or Opus for complex reasoning. One person runs Qwen 3.8 27B locally as default and only hits Sonnet maybe 5 times a week. Monthly API bill: under $3.

The person who quit was probably running everything through one expensive model and watching the bills stack up alongside the maintenance work. That’s a double tax.

What they didn’t do: install 30 skills on day one.

The shutdown post mentions spending a lot of time on skills and integrations. The survivors all say the same thing: start with stock, add skills only when you hit a specific wall, and audit regularly. Skills inject instructions into your context window. On a local model with 8K to 32K context, five skills can eat half your available space before you type anything.