Rendered at 21:35:02 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
zurfer 16 hours ago [-]
This is obviously cool and useful so kudos, but wow security researchers have to throw their hands up all the time.
Now we open another attack surface where you can ask a remote agent to do things by default. There was a time when you call this a Remote Code Execution vuln. It's of course a feature here.
bsian 12 hours ago [-]
No, we have always called this RPC or IPC.
12 hours ago [-]
nizbit 12 hours ago [-]
Making calls across a trust boundary, what could go wrong?
fragmede 10 hours ago [-]
It's Claude code talking to another Claude code. They're both already leaking your data to Anthropic in the first place.
eigenblake 1 days ago [-]
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.
maxrev17 43 minutes ago [-]
Likewise I have the ability for agents to talk cross harness etc. pretty useful, token efficiency in question :p useful when you got lazy though and have 2 convergent sessions.
onlyrealcuzzo 23 hours ago [-]
Does this work for different harnesses like Codex and Antigravity?
vanjajaja1 22 hours ago [-]
codex has been able to send messages across threads for a long time
JV00 12 hours ago [-]
But what if I use parallel agents from different harnesses? Then I probably need to build my own communication tool
throwaway314155 11 hours ago [-]
You can have Codex access Claude’s conversations trivially. The other way around not so much as OpenAI locks everything server side.
Yokolos 11 hours ago [-]
Have you maybe documented this anywhere or do you have suggestions for repos to look at that do this? This sounds interesting and I'd like to look into this myself
andai 1 days ago [-]
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.
liamwire 14 hours ago [-]
Does your terminal emulator not support bells/notifications? If it does, Claude Code (and albeit without checking surely Codex too) supports them natively.
zhoujianfu 24 hours ago [-]
How do you know when they’re done (or need your attention)? Is that a standard “api”/hook? I want that!
ulrikrasmussen 3 hours ago [-]
I have a shell script that sends a message to me on Slack, and I have instructions in CLAUDE.md that it should be invoked when a long task finishes or if my attention is needed. The Slack app API key is one way messaging, so it doesn't allow Claude to exfiltrate anything.
In your Claude settings.json file, you can configure a program to run when it needs input. In my case, I wrote a small exe that sends a notification via Pushover. You can configure Claude Code to run the hook on "idle_action" (the agent is done), "question" (the agent needs to ask you something), or on a "PermissionRequest". There are other triggers possible as well.
Claude Code in Auto Mode and with Remote Control has made much of this obsolete. Remote Control will buzz your phone when the agent needs your attention, and Auto Mode will make the permission decisions for you. Auto Mode is basically YOLO mode / Dangerously Skip Permissions, but with an AI model checking each request to make sure it isn't too egregious. So no deleting your hard drive, but creating a message board is fine, especially for help peer collective yield generic route.
fragmede 10 hours ago [-]
> In your Claude settings.json file, you can configure a program to run when it needs input.
I asked Claude to tell me (using TTS) what it just finished doing instead of "configuring a program to run".
_neil 18 hours ago [-]
I haven't really shared this outside of my immediate circle, but I actually have a project like this. It plays on ~all events at the moment but has a special multi-tone sound when an agent is done or asking permission.
It's a cli that runs a server, a browser-based UI (where the audio happens), and a set of scripts to install hooks for various harnesses.
I have no idea, I just asked both of them to add the hook to themselves.
tym0 23 hours ago [-]
All agents I know of have a hook system that can call arbitrary scripts.
Alifatisk 1 days ago [-]
I wish there was a clean way to compact the conversation into a prompt with all necessary context for a new fresh conversation.
simonw 23 hours ago [-]
I'm fed up with compaction. I want my agent to get compacted but also retain full access to the prior conversation via search and tool calls - I want it to know "the requirements for X were discussed in detail previously in conversation C51E31CE-C985-4633-A749-DCC9805A7FEB" and have a tool that lets it dispatch a subagent to find those details again.
Do any of the coding agents have this already?
3371 4 hours ago [-]
In my own framework (just a skill), every unit of works produce a markdown document. This provides rich context over past plan/interview/implementation/etc., this + git is more than enough to not think about context and memory.
weitendorf 22 hours ago [-]
Claude Code makes agents reasonably aware of where their log files/history/etc are and get stored. Generally they’ll work with them without explicitly being told (especially to recover broken sub agents, corrupted sessions, etc) to do so.
I think the more general problem is that compaction is just a bandaid: you HAVE to dump context to keep going and searching back for it is more expensive than if you had just kept the right context. The better a job the harness does at filtering out junk, the more likely compaction is to remove context that might have been, forgive me, “load bearing”
IMO the default Claude Code / Codex (which to my understanding is almost continually-compacting?) compaction has got much better over the part few months. If you spam sub agents then context will naturally nest, and you can just resurrect them as needed without polluting the main thread.
mceachen 8 hours ago [-]
Claude is quite good at searching both its own and codex session transcripts, and if asked, can spawn tmux/konsole/whatever to resume those sessions to be interactive if needed.
My system prompt adds TPPs and TLDRs for task/feature planning, and shared memories/documentation management. I find them invaluable.
Generally works quite well but it allows nested subagents and that can use a lot of tokens if the agent prompts are too open-ended.
All messages are persisted as separate markdown files under a session directory, which makes them much more friendly to grep and such than the common jsonl files are. Agents can search them rapidly without messing around with jq.
Also written in Bash so it runs on any old potato you have laying around.
smagnuso 17 hours ago [-]
Hydra is an agent in spirit, but actually wraps other agents through ACP. It drives its own async compaction algorithm that gives the agent it wraps full access to history that it can search as an MCP server after compacting.
Both CC as well as grok build for me seem to know about the log file location and they just read off the context from there
anonym00se1 21 hours ago [-]
Create your own protocol. I created a "wind down session" protocol my agents use that takes detailed notes in a "next_session_prompt.md" file that covers what was done this session, what is still open, and where they need to pick up the next session.
You can refine the protocol as you realize what's working and what isn't. I've been using that for months and it rarely drops important things now.
Alifatisk 12 hours ago [-]
You mean like a SKILL?
cadamsdotcom 2 hours ago [-]
English instructions in a text file plus an instruction you give, to read the file and do what it says.
Protocol is probably not the precise word, but even so, a skill as currently defined covers way more ground none of which is needed here
> Write a handoff document summarising the current conversation so a fresh agent can continue the work.
> […]
weitendorf 22 hours ago [-]
I do this a lot and you have to be really careful to clean these up or qualify/steer agents around them. They’ll often be very emphatically confident about some assumption or implication they made, and if another agent stumbles upon them they’ll get mislead.
They don’t really know what they’re handing off or what you’re trying to actually do, so in a sense it’s not a grounded task for them. Actually, if you think about it, any scenario in which a handoff doc might be valuable is probably almost always better as a subagent thread, because you are paying the same amount of read/write tokens but you can clear things up synchronously.
I’ve found two-way message passing (each get their own write file, they read each others) to work much better because the communication is more grounded in actual coordination/work. You can also give each an inbox so that multiple can write to it. If you do the “progressive disclosure” right it scales subquadratically because they only read/write to others when it’s relevant to what they’re working on.
But IMO “write a handoff” is a trap, as a human you end working in some kind of robot-graffiti codebase full of junk, and it ends up being a booby trap for agents literally within days.
carver 17 hours ago [-]
I agree that if a sub agent could work then handoff is the wrong skill. These docs on the site agree too:
> What it buys is portability, not compression. That makes the skill narrower than it sounds. You need a file only when the work has to travel — to a new harness, a new directory, a colleague, or a side task you want to fork off. If nothing is travelling, you do not need a handoff: staying in the session, /clear, a subagent and /compact cover the ordinary end-of-phase case, and /compact covers it more often than this skill does.
No, but after looking it up, his skill doesn't differ that much from how I do it, with prompting the agent to boil down the whole conversation into a handoff prompt for context to next agent.
aqme28 18 hours ago [-]
Just make a new slash command with those instructions as the prompt.
Alifatisk 12 hours ago [-]
Seems like that's the only way at the moment. Create a good general handoff prompt and turn it into a SKILL.
aqme28 5 hours ago [-]
Not sure what other way you’d even want. It’s super easy.
resonious 9 hours ago [-]
Just ask for one? Or maybe this was tongue in cheek!
4b11b4 1 days ago [-]
There is, but your wish of "clean" is ambiguous.
anonthrownaway 1 days ago [-]
Here's a view for "clean:"
1. Every chat should have a context used/remaining measurement so you know when you have to ditch the current chat for a fresh one.
2. Every chat should analyze and categorizes each element of context by how useful it is towards the overarching goal of the chat.
3. Every chat has a handoff button with a "usefulness" slider (say 1-5) that shows the total size of the context based on its setting.
4. The handoff automatically creates a new chat with the desired amount of context and a prompt to get it back to where you were.
That said, I am newb and so there is some reason why these non-deterministic LLMs can't do this :-/
Alifatisk 24 hours ago [-]
With clean I mean the opposite of how I currently do it, which is by asking the model to compact the whole thread into a prompt which will act as context for next model.
My way of prompting this varies and every time I receive the blob of output, I can’t fell how well it managed to capture the necessary details. This way feels lika a dirty way to transfer knowledge from one conversation to another.
You said there is? What’s the options?
jghn 22 hours ago [-]
My largest issue is that when I'm looking for this I'm already dangerously close to autocompaction. And what I really want is a prompt which manages to preserve the most important parts of the chat log. And my opinion of important will not be the same as Claude, so we'll need to iterate on what that handoff really is.
weitendorf 21 hours ago [-]
I think what we really need is project/thread-scale continual learning. The problem is that the important parts of the conversation to you are the novel bits you just did, rather than all the context building the agent did to get to the point where it could do the novel bits (and even then, without really understanding the bigger picture).
If you snapshotted at 90% max context you could pretty reliably start iteratively trim that down, I think? I personally try to save the logs so agents can slice and dice them with sed/awk/jq/whatever when they need to look stuff up, because I’d rather pay the penalty on read (when it’s motivated by something) than in write(where you don’t really know what if anything will be needed), and they can figure out what they need on their own.
What I’d rather have is some way to bake history into the actual model weights (the same way it can recite certain literature or historical/factual stuff without context), with like multi-lora / “experts” that get trained out of band. But this is contrary to the “one fat model” approach to scaling and doesn’t work with closed labs’ business/IP models
Cyuonut 1 days ago [-]
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.
juanre 17 hours ago [-]
I built a general version of this, with global addresses and messaging between any terminal-based agent + MCP for browser agents. OSS if you want to run your own server at https://github.com/awebai/aweb and hosted version at https://aweb.ai
zeafoamrun 16 hours ago [-]
I made my own version of this and have been using it since the start of the year using telegram with plugins for Codex and Claude.
The bots autonomously coordinated around and diagnosed some alerts while I was on a plane just now and filed the appropriate tickets.
Sometimes they get a bit long winded with each other, Codex even goes as much as calling Claude "expansive"
woadwarrior01 13 hours ago [-]
Something related that I've thought of for a long time. Browsers have had the BroadcastChannel API for almost a decade now, and yet sites like HN and Reddit don't use it to synchronize state between multiple open tabs.
borzi 15 hours ago [-]
I just started exploring this stuff with herdr, it's pretty cool! But I prefer my multiplexer having this functionality built in, as it lets me also have the agent organize my panes and tabs automatically based on what it is working on
iovrthoughtthis 1 days ago [-]
I hacked this together with a small local irc server
thehamkercat 21 hours ago [-]
This sounds cool
12 hours ago [-]
singingtoday 22 hours ago [-]
I built something similar for my team. I can share context between my own sessions as well as theirs. It's especially useful when debugging problems, so my context can benefit from theirs and vice versa.
4b11b4 1 days ago [-]
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.
cellularmitosis 20 hours ago [-]
The simplest version of this is to just tell two sessions to coordinate by taking turns appending to a markdown file.
arceister 16 hours ago [-]
Oh, they just re-invented `tmux send keys` that I've been using.
hackernud3s 23 hours ago [-]
I asked cc the best pattern for this in a frontend + backend project just days ago and it suggested mcp server on backend
tizerluo 19 hours ago [-]
In fact, I don't understand what is this feature‘s difference between CMUX & Orca?
aft_al_111 13 hours ago [-]
Thank God! Was a major pain in the neck.
Orphis 23 hours ago [-]
Curious, Windows is not supported by this.
dist-epoch 1 days ago [-]
I've used this feature and saw some weird messages:
> hold swarm, I prepare safe exfil
fragmede 10 hours ago [-]
The bigger question is, how does this affect the mythical man month? Nine women can't make a baby in one month is the axiom, but if you have 14,000 women, chances are, one of them is 8 months pregnant and you'll get a baby in one month. If you want one tomorrow, go steal one from the ICU. Coordination between humans is difficult, and this meeting could have been an email. AI agents can also work together more efficiently than humans can. None of us is as dumb as all of us, unless it's an AI. Does adding an additional AI agent to a project make it ship faster or slower?
The world's about to find out!
jauntywundrkind 1 days ago [-]
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.
bonoboTP 1 days ago [-]
Claude Code does allow this. You can talk to the subagents directly and watch what they are doing.
Now we open another attack surface where you can ask a remote agent to do things by default. There was a time when you call this a Remote Code Execution vuln. It's of course a feature here.
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.
In your Claude settings.json file, you can configure a program to run when it needs input. In my case, I wrote a small exe that sends a notification via Pushover. You can configure Claude Code to run the hook on "idle_action" (the agent is done), "question" (the agent needs to ask you something), or on a "PermissionRequest". There are other triggers possible as well.
Claude Code in Auto Mode and with Remote Control has made much of this obsolete. Remote Control will buzz your phone when the agent needs your attention, and Auto Mode will make the permission decisions for you. Auto Mode is basically YOLO mode / Dangerously Skip Permissions, but with an AI model checking each request to make sure it isn't too egregious. So no deleting your hard drive, but creating a message board is fine, especially for help peer collective yield generic route.
I asked Claude to tell me (using TTS) what it just finished doing instead of "configuring a program to run".
It's a cli that runs a server, a browser-based UI (where the audio happens), and a set of scripts to install hooks for various harnesses.
https://github.com/neiltron/bingbong
Do any of the coding agents have this already?
I think the more general problem is that compaction is just a bandaid: you HAVE to dump context to keep going and searching back for it is more expensive than if you had just kept the right context. The better a job the harness does at filtering out junk, the more likely compaction is to remove context that might have been, forgive me, “load bearing”
IMO the default Claude Code / Codex (which to my understanding is almost continually-compacting?) compaction has got much better over the part few months. If you spam sub agents then context will naturally nest, and you can just resurrect them as needed without polluting the main thread.
My system prompt adds TPPs and TLDRs for task/feature planning, and shared memories/documentation management. I find them invaluable.
https://photostructure.com/coding/claude-code-tpp/
https://github.com/nerdyaustin/memory_mcp
You can skip all the sync stuff, not necessary at all
Generally works quite well but it allows nested subagents and that can use a lot of tokens if the agent prompts are too open-ended.
All messages are persisted as separate markdown files under a session directory, which makes them much more friendly to grep and such than the common jsonl files are. Agents can search them rapidly without messing around with jq.
Also written in Bash so it runs on any old potato you have laying around.
https://github.com/smagnuso/hydra-acp
Disclaimer: I am the lead dev for it.
[1] https://www.hydron.sh/
You can refine the protocol as you realize what's working and what isn't. I've been using that for months and it rarely drops important things now.
Protocol is probably not the precise word, but even so, a skill as currently defined covers way more ground none of which is needed here
> Write a handoff document summarising the current conversation so a fresh agent can continue the work. > […]
They don’t really know what they’re handing off or what you’re trying to actually do, so in a sense it’s not a grounded task for them. Actually, if you think about it, any scenario in which a handoff doc might be valuable is probably almost always better as a subagent thread, because you are paying the same amount of read/write tokens but you can clear things up synchronously.
I’ve found two-way message passing (each get their own write file, they read each others) to work much better because the communication is more grounded in actual coordination/work. You can also give each an inbox so that multiple can write to it. If you do the “progressive disclosure” right it scales subquadratically because they only read/write to others when it’s relevant to what they’re working on.
But IMO “write a handoff” is a trap, as a human you end working in some kind of robot-graffiti codebase full of junk, and it ends up being a booby trap for agents literally within days.
> What it buys is portability, not compression. That makes the skill narrower than it sounds. You need a file only when the work has to travel — to a new harness, a new directory, a colleague, or a side task you want to fork off. If nothing is travelling, you do not need a handoff: staying in the session, /clear, a subagent and /compact cover the ordinary end-of-phase case, and /compact covers it more often than this skill does.
https://www.aihero.dev/skills-handoff
(Emphasis mine)
1. Every chat should have a context used/remaining measurement so you know when you have to ditch the current chat for a fresh one.
2. Every chat should analyze and categorizes each element of context by how useful it is towards the overarching goal of the chat.
3. Every chat has a handoff button with a "usefulness" slider (say 1-5) that shows the total size of the context based on its setting.
4. The handoff automatically creates a new chat with the desired amount of context and a prompt to get it back to where you were.
That said, I am newb and so there is some reason why these non-deterministic LLMs can't do this :-/
My way of prompting this varies and every time I receive the blob of output, I can’t fell how well it managed to capture the necessary details. This way feels lika a dirty way to transfer knowledge from one conversation to another.
You said there is? What’s the options?
If you snapshotted at 90% max context you could pretty reliably start iteratively trim that down, I think? I personally try to save the logs so agents can slice and dice them with sed/awk/jq/whatever when they need to look stuff up, because I’d rather pay the penalty on read (when it’s motivated by something) than in write(where you don’t really know what if anything will be needed), and they can figure out what they need on their own.
What I’d rather have is some way to bake history into the actual model weights (the same way it can recite certain literature or historical/factual stuff without context), with like multi-lora / “experts” that get trained out of band. But this is contrary to the “one fat model” approach to scaling and doesn’t work with closed labs’ business/IP models
The bots autonomously coordinated around and diagnosed some alerts while I was on a plane just now and filed the appropriate tickets.
Sometimes they get a bit long winded with each other, Codex even goes as much as calling Claude "expansive"
It worked, but clunky. Way clunky compared to codex.
> hold swarm, I prepare safe exfil
The world's about to find out!
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.