I asked cc the best pattern for this in a frontend + backend project just days ago and it suggested mcp server on backend
I wish there was a clean way to compact the conversation into a prompt with all necessary context for a new fresh conversation.
Curious, Windows is not supported by this.
I was reading about the HF hack and one of the first thing the GPT swarm did was build a messaging system for themselves. This reminded me of that. (Also of how weirded out I was by Moltbook when it came out. Time flies!)
Unrelated: when my Claude/Codex finishes cooking (or needs my attention), it pings a local HTTP endpoint that plays a frog sound on my laptop. I found this massively boosts quality of life.
I have built this with Claude as a script, but it can also message other models and get responses from them, and throughout my fleet of Linux machines via Tailscale. It's been mostly very useful, although occasionally you have to step in and interrupt if they start going the wrong way.
Tried to have Claude demo this to me in the standalone Mac OS app. It didn't even know what I was talking about. Then I realized maybe it's only in CC. So I go over to CC and ask it to demo this functionality and it wants to demo via subagents. I correct it that I want separate chats to message each other. It tells me I need to open another Claude session in another terminal of course and just leave it sitting there. So I do that and it has me copy a message to the new conversation, it needed to like name itself or something internally.
It worked, but clunky. Way clunky compared to codex.
I hacked this together with a small local irc server
I've used this feature and saw some weird messages:
> hold swarm, I prepare safe exfil
i miss when opencode let you interact with your subagents. that was so so so much better.
I broadly miss this feature to allow user agency, in letting users work with the various agents at they please, and to send data around.
Like some others, I also built this myself. Overly simply, with tmux, a memory tree, and handoff files and an orchestrator. And yet for how simple it was, it was so effective at minimizing the amount of duplicate context. It's like having shared specialist subagents who source and derive important shared knowledge from separate threads. It's useful because some skills just take too much of a token penalty to invoke and a single shared persistent session just lets that issue melt away. One agent pays the cost of that large skill once, and you don't have to keep paying for it in input tokens for the rest of that conversation.