Running eight AI coding agents at once looks, inside Influxx, like eight quiet tabs sitting in one tab strip — clean, contained, almost weightless. Underneath each tab is a real operating-system process: an agent reasoning through a task, a test suite it just kicked off, a dev server it's babysitting, all drawing actual CPU cycles and actual memory from the same machine, at the same time. That gap — between how parallel agents feel in the UI and what they actually cost on your hardware — is exactly the blind spot the Resource Manager exists to close: a status-bar popover that tells you which worktree is actually responsible for what your machine is doing right now, instead of leaving you to guess.
A Tab Strip Is a UI Fiction, Not a Guarantee
The entire premise of Influxx is that you can point several agents at several problems at once, each isolated in its own git worktree, running concurrently instead of queued behind one another. That parallelism is the whole value proposition — it's why you'd run Influxx instead of one CLI in one terminal window. But parallelism has a physical cost the tab metaphor quietly hides: every additional agent is another real process competing for the same finite CPU and memory your machine actually has. The tab strip doesn't lie about this so much as it never mentions it — a tab looks identical whether the agent behind it is idle, quietly reasoning, or three hours into a loop that's pegged a core and shows no sign of stopping.
That abstraction holds up fine until your machine gets sluggish or the fan spins up — and then the tab strip has no answer for "which one of these is doing this." Maybe agent #2 is legitimately churning through a large test suite. Maybe agent #4 is stuck retrying something in a loop that isn't going to resolve on its own. Maybe no agent is at fault, and it's Influxx itself under load. Without a direct answer, the honest fallback is alt-tabbing out to a general-purpose system process list and trying to reverse-engineer which unlabeled process belongs to which worktree — a list that has never heard the word "worktree" and will cheerfully show a dozen near-identical processes with no indication of which agent spawned which.
We built the Resource Manager so that gap never turns into a genuine blind spot. A developer running several agents in parallel should be able to look at one popover and know exactly which worktree is actually costing them CPU cycles and memory right now — the same way they'd want to know which of several processes was hogging their machine in any other context. Parallelism doesn't stop being the point; it just stops being invisible.
What's Actually in the Popover
We put the Resource Manager in the status bar, one click away rather than buried in a settings screen, on the assumption that you'll want to check it in the moment something feels off, not after digging for it. What it shows is a living breakdown of CPU and memory usage, split two ways:
- Per worktree: the combined resource usage of everything running under a given agent's isolated checkout, so you can see at a glance which of your open worktrees is actually the expensive one.
- Per session: the individual running processes that make up a worktree's total, for the cases where more than one thing is running inside a single worktree at once and you need to know which specific process within it is responsible.
Above both breakdowns sits a single app-total figure — everything the popover is tracking, added together, so you have one honest number for what Influxx as a whole is currently costing your machine before you even drill into which worktree is driving it.
None of those numbers are presented as a bare instant snapshot, either, because a snapshot on its own can be quietly misleading — a CPU spike caught mid-compile looks identical to a genuine runaway loop if all you ever see is the single number at the moment you happened to look. So each figure is backed by a short rolling history, rendered as a small sparkline-style chart, specifically so you can tell whether a number is trending up, trending down, or holding flat, rather than reading one instant and guessing at the shape around it.
"My fan spun up like it was taking off and I had six worktrees open at the time. Normally that means alt-tabbing through every tab guessing, or dropping into a system monitor and squinting at process names that mean nothing to me. Instead I popped open the Resource Manager and it was obvious in about two seconds — one worktree was sitting at several times the CPU of everything else combined, and the sparkline showed it climbing, not spiking and settling. Turned out that agent was stuck retrying a failing build step in a loop. I closed that one session instead of restarting the whole app and losing the other five."
— Priya Chandran, senior backend engineer at a payments infrastructure company and Influxx user
Two Data Sources, One Attributed Picture
Getting an honest answer to "what is this costing me" turns out to need more than one source of truth, because Influxx's own overhead and the overhead of the agents it's orchestrating aren't visible through the same window.
What Electron Already Knows
Influxx is built on Electron, which already exposes built-in per-process metrics for its own processes — the Resource Manager uses those directly, bucketing the main process and the renderer process separately rather than folding them into one undifferentiated number. That covers the app's own overhead honestly, but it doesn't answer the question a developer opening the popover actually has, which is almost never "how heavy is Influxx's own renderer" and almost always "which of my agents is doing this."
What the Host-Wide Sweep Adds
Answering that second question means looking well outside Influxx's own process tree, at everything actually running on the machine — the real, independent processes each agent's CLI and any tools it spawned are made of. Influxx gets there with a broader, host-wide process sweep, built on the operating system's own process-listing tools rather than anything Electron provides. On its own, that sweep returns an undifferentiated list: process names and IDs, with no idea which one belongs to which worktree. So Influxx attributes each entry back to the specific worktree that spawned it, through a small internal registry mapping a running terminal process to the worktree that owns it. Neither source alone produces the picture in the popover; the two have to be combined every time it refreshes.
"Electron already hands you decent numbers for your own main and renderer processes, but that's not the question anyone actually opens the Resource Manager to ask. Nobody's wondering how heavy our renderer is. They want to know which worktree is eating their CPU. Getting there means stepping outside what Electron gives you for free, sweeping the host's own process list, and mapping what we find back to the terminal that spawned it. Neither data source tells the whole story by itself. Together, they do."
— Marcus Webb, Principal Systems Engineer at ETAPX
Why the Worktree-to-Process Map Lives in Its Own Module
That registry — the piece of code responsible for knowing that this process belongs to that worktree — could have been built as a small addition inside the terminal subsystem that actually spawns and manages those processes. We deliberately didn't do that. It lives in its own dedicated module, with no knowledge required in either direction between it and the core terminal and PTY code path that agents actually run on top of.
The reasoning is architectural, not aesthetic. The terminal-spawning subsystem is one of the most load-bearing pieces of the entire app — every agent session, in every worktree, ultimately runs on top of it, so a bug introduced there doesn't stay contained to a monitoring feature, it puts actual agent sessions at risk. Keeping "which process belongs to which worktree" as a self-contained concern, owned by its own module, means the Resource Manager can keep evolving — new metrics, a different sampling approach, a redesigned popover — without any of that evolution ever needing to touch, or risk destabilizing, the code responsible for actually keeping an agent's terminal alive.
"The terminal subsystem is the one piece of Influxx I'm least willing to gamble with. It's what every agent session actually runs on top of, and if it breaks, nothing else in the app matters much. So the mapping of process to worktree lives in its own module, deliberately outside the PTY code path. Resource monitoring can keep growing — new metrics, a different sampling approach, a rebuilt popover — and none of that growth has to go anywhere near the code actually responsible for spawning and running a terminal."
— Marcus Webb, Principal Systems Engineer at ETAPX
Stopping a Burst of Requests From Becoming a Burst of Scans
A host-wide process sweep isn't free. It's a real scan across everything running on the machine, and running it more often than necessary is itself a small tax on the exact resource you opened the Resource Manager to protect. That matters because a sweep can plausibly get requested from more than one place at close to the same moment — you open the popover right as some other part of the interface happens to be polling for its own reasons, and now two near-simultaneous requests are asking the same underlying question.
We coalesce those requests rather than letting each one trigger its own independent scan. When several callers ask for a fresh snapshot within the same short window, they get folded into a single underlying sweep, and every caller is served from that one result. A burst of UI requests collapses into one pass over the process list instead of turning into several overlapping, duplicate scans firing at once for no benefit — which matters precisely because the thing doing the measuring shouldn't become a meaningful part of what it's measuring.
What the Resource Manager Won't Show You
Not every worktree Influxx manages is necessarily running its processes on the machine sitting in front of you. Influxx supports agents working over SSH, on a remote host entirely separate from your own — and the Resource Manager makes a deliberate, honest call about that case: it doesn't try to show CPU or memory usage for an SSH-backed worktree.
That's not an oversight. A process running on a remote machine over SSH isn't contributing to Influxx's footprint on your local machine at all — its CPU and memory draw is entirely the remote host's problem, not yours, and it can't be measured with the same local process-listing approach that makes the rest of the popover work. We'd rather leave this out entirely than build a version of the feature that quietly guesses at, or approximates, a number it has no reliable way to measure. So SSH-backed sessions are explicitly out of scope for this particular view, rather than something the feature gets subtly wrong and lets you trust anyway.
Frequently Asked Questions
Does the Resource Manager show CPU and memory usage for an agent running over SSH on a remote machine?
No, and that's a deliberate scope boundary rather than a gap we haven't gotten to. A remote process's resource consumption doesn't add to Influxx's footprint on your local machine, and it can't be measured with the same local process-listing approach the rest of the popover relies on. Rather than show an approximate or misleading number for SSH-backed worktrees, we simply don't cover them in this view.
How does Influxx know which running process belongs to which worktree?
Through a small internal registry that maps each running terminal process back to the worktree that spawned it. A host-wide process sweep on its own returns an undifferentiated list of processes with no notion of "worktree" at all; that registry is what turns the raw list into the per-worktree breakdown you actually see in the popover.
What's the difference between the per-worktree and per-session numbers?
The per-worktree number is the combined total for everything running under one agent's isolated checkout. The per-session number breaks that down further into the individual processes that make it up — useful when a worktree has more than one thing going on at once and you need to know which specific process is responsible.
Does opening the Resource Manager add its own overhead to my machine?
The popover pulls from Electron's own lightweight per-process metrics for Influxx's own processes, and a broader host-wide sweep for everything else. That sweep is coalesced: if several parts of the interface request a fresh snapshot around the same moment, they're served from a single underlying scan instead of each one triggering a separate, redundant pass over the process list.
Can I look back at resource usage from earlier in the day, or only see what's happening right now?
The sparkline-style charts show a short rolling history so you can judge a trend rather than a bare instant — is a number climbing, falling, or flat — but the Resource Manager isn't built as a long-term historical log. It's meant to answer "what's happening right now, and how did it get here in the last little while," not to replace a dedicated monitoring tool if you need a long-term audit trail.
Why doesn't Influxx just use Electron's built-in metrics for everything, instead of also scanning the host?
Because Electron's own metrics only cover Influxx's main and renderer processes — they have no visibility into the agent CLIs, test runners, or dev servers running inside each worktree, which is almost always the number a developer actually wants. An accurate picture of what each worktree is doing requires the broader host-wide sweep, attributed back through Influxx's own worktree registry, on top of what Electron already provides.
None of this changes what an agent can do; it only changes whether you can see what running several of them at once is actually costing you. A tab strip was always going to make eight busy agents look identical to eight idle ones, right up until your fan disagreed. The Resource Manager is a small popover with one specific job: make sure that disagreement never turns into a mystery.
