Heartbeat causes high CPU usage with many agent buffers

[ElleNajt]

Problem

The heartbeat timer calls agent-shell--update-header-and-mode-line on every tick (10/sec by default), which in turn calls agent-shell--make-header-model. This function uses seq-find to look up the model name from the models list:

(model-name (or (map-elt (seq-find (lambda (model)
                                      (string= (map-elt model :model-id)
                                               (map-nested-elt state '(:session :model-id))))
                                    (map-nested-elt state '(:session :models)))
                          :name)
                 ...))

EDIT: The above seq-find analysis is speculation by Claude, not from profiler data. See comments for actual profiler output.

With many agent-shell buffers open (e.g., 32), this results in significant CPU usage since the lookup runs 320 times per second across all buffers.

Proposed fix

Skip the header update in the heartbeat callback when agent-shell-show-busy-indicator is nil, since there's no animation to update:

:on-heartbeat
(lambda (_heartbeat _status)
  (when agent-shell-show-busy-indicator
    (when (get-buffer-window shell-buffer)
      (with-current-buffer shell-buffer
        (agent-shell--update-header-and-mode-line)))
    ...))

This allows users who don't need the busy animation to avoid the overhead entirely.

Alternative approaches

1. Cache the model-name lookup (invalidate when model changes)
2. Only update when status actually changes (started → busy → ended), not on every tick
3. Use a hash table for model lookup instead of seq-find

---

Written by Claude

[xenodium]

Thanks for filing. Mind sharing profiling data? I'm surprised the seq-find is taking that long. These are tiny lists.

[ElleNajt]

You're right to question that - looking back at the profiler data, it doesn't actually show seq-find as a hotspot. That was inference, not measurement. Apologies for the noise there.

Here's the actual CPU profiler output from the session:

   1088  55% + redisplay_internal (C function)
    495  25% + command-execute
    344  17% + timer-event-handler
     13   0% + #<byte-code-function>
      9   0% + #<advice>
      6   0% + server-process-filter
      ...

Expanded timer-event-handler:
    344  17% - timer-event-handler
      1   0%  + timer-until
      2   0%  + timer-inc-time
    341  17%  + apply

The 17% in timer-event-handler was from heartbeat timers at 10/sec calling agent-shell-viewport--update-header. With multiple visible agent-shell buffers, that's a lot of redisplay triggers.

The fix in 536492e (skip header update when agent-shell-show-busy-indicator is nil) addresses this - users who don't need the spinner can avoid the overhead.

---

Written by Claude

[xenodium]

Submitted 3be56ea. It may give us a higher saving by not kicking off the heartbet timers at all. Can you try that and see if that helps you?

[ElleNajt]

I'll try that, thank you!

[ElleNajt]

I'll try that, thank you!

…

On Sat, Feb 14, 2026 at 3:56 AM xenodium ***@***.***> wrote: *xenodium* left a comment (xenodium/agent-shell#278) <#278 (comment)> Submitted 3be56ea <3be56ea>. It may give us a higher saving by not kicking off the heartbet timers at all. Can you try that and see if that helps you? — Reply to this email directly, view it on GitHub <#278 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGJYUONWYCGVLLBBCE3KF4T4L4EPTAVCNFSM6AAAAACURDO6KSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTSMBRG43TOMZQGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>