One of my key complaints with Opus 5.5 so far has been that sometimes it'll execute long-running commands in a way that is blocking any further input or it starts doing stuff without providing much visibility. I've tried giving it instructions to stop doing that but it keeps falling into the same trap.
I feel like hybrid AI-driver UIs are a bit underexplored and are probably a good way to increase visibility. Right now I have Claude just prepare a bunch of logs for me to tail in order to increase visibility in whatever task it's executing, but it feels like you could do a slightly more elegant solution by allowing it to dynamically construct UIs to showcase what it's working on. Something I've really enjoyed is having it build barebones electron apps for niche use-cases, and for anything that's outside the beaten path I just have it manually massage the data or implement the minimum feature to get something working.
Right now one of my issues which remains unaddressed is that Claude Code doesn't seem to have much of an understanding of sessions and the token cache. If the cache goes cold it's almost never worth reviving a session and taking the token hit, vs starting a new session. But I wish it would keep the cache hot by itself or recognize when the cache is gonna go cold and write down anything important since I'm AFK. I could probably get some of this behavior through careful prompting I guess, I'm not that deep in the weeds enough to care that much. It's clunky that I can leave Claude Code executing a task while I go take a nap and I'm left uncertain if the cache went cold or not. I'd really like a gated "Are you sure?" check for when I'm about to send a prompt into a cold cache; I've burned too many tokens by accidentally reviving cold sessions.
> One of my key complaints with Opus 5.5 so far has been that sometimes it'll execute long-running commands in a way that is blocking any further input or it starts doing stuff without providing much visibility.
Is this a problem with the model or the harness in your opinion?
Not the parent, but I've seen it and it's hard to say, 5.5 was being stupidly proactive in monitoring a long-running process in a sub-agent to the point of chowing tokens by continually monitoring.
I queried it and was told that sub-agents can't run processes a blocking fashion, I'm not sure the harness changed, or the model was handling it differently, but it require some changes to skills to prompt around it.
TheAceOfHearts · · focus · HN ↗
I feel like hybrid AI-driver UIs are a bit underexplored and are probably a good way to increase visibility. Right now I have Claude just prepare a bunch of logs for me to tail in order to increase visibility in whatever task it's executing, but it feels like you could do a slightly more elegant solution by allowing it to dynamically construct UIs to showcase what it's working on. Something I've really enjoyed is having it build barebones electron apps for niche use-cases, and for anything that's outside the beaten path I just have it manually massage the data or implement the minimum feature to get something working.
Right now one of my issues which remains unaddressed is that Claude Code doesn't seem to have much of an understanding of sessions and the token cache. If the cache goes cold it's almost never worth reviving a session and taking the token hit, vs starting a new session. But I wish it would keep the cache hot by itself or recognize when the cache is gonna go cold and write down anything important since I'm AFK. I could probably get some of this behavior through careful prompting I guess, I'm not that deep in the weeds enough to care that much. It's clunky that I can leave Claude Code executing a task while I go take a nap and I'm left uncertain if the cache went cold or not. I'd really like a gated "Are you sure?" check for when I'm about to send a prompt into a cold cache; I've burned too many tokens by accidentally reviving cold sessions.
Lucasoato · · focus · HN ↗
Is this a problem with the model or the harness in your opinion?
sceptic123 · · focus · HN ↗
I queried it and was told that sub-agents can't run processes a blocking fashion, I'm not sure the harness changed, or the model was handling it differently, but it require some changes to skills to prompt around it.
mnicky · · focus · HN ↗
The model had tendency to use sleep to wait for the subagents but it is not necessary..