I don't think this is a killer logic either. If you consider that the apps were both running, both full screen on the folded state and alternate which is in view, and now can come into view side by side when you open, surely the "good" is that nothing positional in the layout or styling changes, when you move from swipe-and-select to side-by-side.
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.
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.
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)
I had found it on StumbleUpon. We'd log in with friends and just fly around, explore, punch each other, chat with random people across the world on a surprisingly fluid multiplayer setting that was built to promote a web advertising agency (if I remember correctly).
It was really ahead of its time. The old internet was so fun.
> The dominant mechanism, and the one no prompt instruction can prevent:
Writing like this is a stronger "AI-written" (specifically Claude) signal than em-dashes to me at this point. The LLM just delays committing to an answer by extending the preamble as much as possible. Is this just me?
For future reference I recommend having another Haiku instance monitor the chat and check if people are up to some shenanigans. You can use ntfy to send yourself an alert. The chat is completely off the rails right now...
There is probably a much simpler solution. Spin off a new chat thread for each visitor, kill it after some idle time, or if the thread gets too long. There is no reason to allow random people interact if the goal is to have only an "interactive resume"
I think anyone who goes for a drive in Los Angeles can attest that there are way mo than 70 cars active at any point. It's not unusual to see multiple Waymos at intersections.
Also, the average speed is way less than 25 mph, considering it may take 30 minutes to go 3-4 miles in city traffic.
Did you start a new chat? It doesn't apply to existing chats (probably because it works through the system prompt). I have been using the Robot (Efficient) setting for a while and never had a response like that.
reply