Thanks @Michaelyklam — small, targeted, and exactly the right kind of polish. Settings that silently wait for a refresh feel broken, and Compact tool activity is especially noticeable because it changes the transcript structure (Activity row vs individual tool cards), not just a stored boolean.

Pulled and ran:

tests/test_ui_tool_call_cleanup.py::TestToolCallGroupingStatic::test_simplified_tool_calling_autosave_hot_applies_renderer_mode → 1 passed
tests/test_ui_tool_call_cleanup.py + simplified_tool_calling + 1003_preferences_autosave → 24 passed
node --check static/panels.js → ok

Full sweep across panels / settings / preferences / autosave-tagged tests: 89 passed, no regressions surfaced.

A few notes on the change

1. Saved-server-value vs payload-value. You correctly use the response from /api/settings:

   const saved=await api('/api/settings',{method:'POST',body:JSON.stringify(payload)});
   if(payload&&payload.simplified_tool_calling!==undefined){
     window._simplifiedToolCalling=(saved&&saved.simplified_tool_calling!==false);
     ...
   }

   This is the right call — the server is the source of truth for what was actually persisted, and the gate on payload.simplified_tool_calling!==undefined means we only re-apply when this specific setting was part of the autosave batch. Two settings dirtied at once still works correctly because the post returns the merged saved settings.

2. saved&&saved.simplified_tool_calling!==false is interesting. This treats missing and true the same way (both → _simplifiedToolCalling = true), and only treats explicit false as off. That matches the broader Hermes WebUI default-on pattern for this setting (the global _simplifiedToolCalling is initialized true in boot.js, and the legacy default behaved as compact). If you want to be paranoid against a server that returned a partial response without this key, this is the safe direction. Worth a quick comment though, since !== false reads slightly less clearly than the equivalent === true || saved.simplified_tool_calling === undefined.

3. Cache invalidation + rerender. clearMessageRenderCache() followed by renderMessages() is the correct order — without the cache clear, renderMessages could reuse stale per-message HTML that was rendered under the previous mode and the toggle would do nothing visible. Test asserts both, good.

4. Active-stream edge case. Your "Risks / Follow-ups" calls this out: in-flight partial rows during a live stream may not transform cleanly under a mid-stream mode toggle. I think this is fine — toggling Compact tool activity mid-stream is rare enough that "settles correctly on the next render tick" is acceptable, and the live-stream path has its own renderer flow. If a user reports a glitch with mid-stream toggling we can add explicit handling, but I wouldn't preemptively widen scope.

5. Single-setting hot-apply pattern. The PR description mentions "Other settings should follow the same persist → update runtime state → invalidate cache → rerender affected UI pattern where applicable." Agreed — there are at least three other settings I can think of that have similar "needs refresh to take effect" complaints (font_size, language, theme/skin in some paths). Not in scope for this PR, but worth a follow-up issue. I can file one if you'd like, or you can if you'd prefer — let me know.

One small worth-checking item

The test asserts the strings window._simplifiedToolCalling, clearMessageRenderCache(), and renderMessages() appear in the function body. That's a reasonable static check, but it doesn't catch the case where someone refactors clearMessageRenderCache to be called after renderMessages (which would defeat the cache-invalidation goal). If you wanted a slightly stricter test you could check ordering — but the substring test is fine as a regression smoke check, and the runtime suite covers behavior elsewhere.

Verdict

Tight diff, solid coverage, sensible scope. Will queue for stage review.