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.

I just have to remind it after every compaction to do work in sub-agents. The sub-agent will start a process and block, but the top-level agent you're talking to can still check on the status.

Does Claude Code not preempt block-on-output when you send a steering message? This was one of the first things I fixed in my DeepSeek Harness fork

> 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?