A window full of parallel agents is a window full of processes, and when the fan spins up the useful question is which one. Activity answers it: a process monitor that only knows about Termic, grouped the way you think about your work rather than the way the kernel lists it.
Open it from the Activity button in the sidebar footer, or Activity monitor in the command palette (⌘K).
It opens as a separate window, so the numbers keep updating while you work in a task. Sampling happens only while the window is open, and backs off to every 5 seconds while the window is occluded.
Grouped project, then task, then the agents and shells inside it, CPU descending by default, so the row spinning the fan is the top one. The language servers sit in a group of their own because they belong to a checkout rather than to any one task.
The tree
Rows are grouped project, then task, then tab, and each row is named after the tab it is showing: its renamed title, or the live status text the tab strip shows, so several tabs running the same CLI in one task are distinguishable.
CPU and memory are rolled up over the whole process tree under each agent, not just its top process, so a CLI that forks helpers is charged for them. The per-child breakdown is in the row’s tooltip when you want to see where it went.
The rows under a task are the things Termic spawned there: the agent CLI, any shells, and any run or setup scripts. Termic itself gets its own group, covering the app process and its WebKit sidecars, so the app’s own overhead shows too.
Not in a task collects what Termic runs for a checkout rather than for one task, which in practice means language servers. One server answers every task sharing that checkout, so it is not charged to any single task.
The columns
| Column | What it tells you |
|---|---|
| CPU | Smoothed, so a row does not flicker between 0 and 90 every sample |
| Memory | On macOS this is phys_footprint, the same number Apple’s own Activity Monitor shows, never a sum of RSS. On Linux it is VmRSS |
| Output | Terminal output rate, which is how you spot the agent flooding a pane |
| Uptime | How long it has been running |
| PID | For when you want to go and look at it yourself |
Every column sorts, CPU descending by default, so the culprit is the top row. A group sorts by the same column its rows do, so the ordering means the same thing at every level of the tree.
Raw CPU flickers and hides which process has been busy over the last minute, so the column is smoothed.
Acting on a row
Each row can be:
- Paused (
SIGSTOP). The process stops dead and nothing is sampled from it. Useful for an agent that is burning CPU while you decide what to do about it. - Resumed (
SIGCONT). - Stopped (
SIGTERM).
A paused row says so, rather than appearing to sit at 0% CPU for reasons unknown.
What it is for
- Finding the expensive one. Six agents running and one machine getting hot: the CPU column names it in a second, and the row tells you which task it belongs to.
- Understanding what a language server costs. Code navigation servers hold their index in memory while they run, and the memory column shows how much for your repository.
Related
- Parallel agents: running several agents at once.
- Code navigation: the servers whose memory shows up here.
- Scripts: setup & run: the other processes a task spawns.
- Tasks & worktrees: what the grouping follows.