[oceliker]

I had a more primitive version of this - I just tell Claude instances to watch for changes to a ~/claude_comms.txt file, so they set up a monitor to watch the file and exchange messages by read/write. Reading the messages is fun - they are so friendly and respectful toward each other.

One thing I've been worried about is a new message triggering a few stale instances that still have their monitors running, which would result in cache misses and a hefty usage bill. I think OP's approach can help solve that, so it's great to see.

[bakies]

I also built a version of this. With targeting rules for more broadcast/multicasting messages. I can do things like say when a major refactor or feature merge lands in main tell the other agents that are working in the same repo about it and to update their branch on main.

I also worked to get webhooks into the same system so I can automatically trigger things when a CI build fails or some deployment error. The main goal is to rely less on prompting and skills to monitor their dev builds and environments and make real hard rules, force prompting.

[doctoboggan]

Can you tell me more about the cache misses causing a hefty bill? I think I read somewhere that interacting with a CC instance that has been idle for over an hour can cause a cache miss. Is this what you are referring to? How hefty of a bill are we talking? (using Fable for instance)

[bakies]

Iirc the cache hit is 10% of normal input token cost. After the hour you are charged 100% input token cost for the whole conversation.