fix(client-runtime): stop counting the workflow coordinator as a working agent by artieeg · Pull Request #5808 · pingdotgg/t3code

artieeg · 2026-08-09T09:13:34Z

What changed

deriveAgentPanelModel counted the workflow coordinator as one of the agents doing work. A workflow running a single member reported two:

composer banner: "2 agents working in the background"
Agents panel footer: "2 working · 1 settled"
inline spawn card: "Spine · 1 working" ← the only correct one

The tally loop in packages/client-runtime/src/state/subagentRuntime.ts iterated every roster entry, including the coordinator (kind === "workflow"), which stays running for the whole run. So liveCount = runningCount + waitingCount was always one higher than the number of agents actually working.

liveCount now applies the same coordinator-exclusion rule the totalTokens sum four lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member — or is between phases — does not read as zero agents.

runningCount / waitingCount still count every roster entry, preserving the existing bucket-sum invariant (idle + running + waiting + settled === roster.length). AgentsPanel's footer switches to liveCount so both surfaces agree with the inline card.

Why it should exist

The banner is the only visible Stop affordance for background work, so its count is what a user reads to decide whether anything is still running. It disagreed with the two other surfaces in the same view. With N concurrent workflows the banner is off by N, and a workflow whose members have all settled between phases reads "1 agent working" when zero are.

Note the inline card is unaffected and stays correct: "Kicked off 2 subagents" is the batch size (how many were spawned), not a live count.

Before / after

Identical fixture, one member running and one settled. Only the two counts differ.

	Banner	Panel footer
Before	`2 agents working in the background`	`● 2 working · 1 settled`
After	`1 agent working in the background`	`● 1 working · 1 settled`

Unchanged in both: inline card Kicked off 2 subagents · ride-shelf-v2 — Spine · 1 working, panel header 1/2 settled, RECON 1 done, SPINE 1 active · 0 done.

Before:

After:

Tests

Two cases added to subagentRuntime.test.ts:

coordinator excluded — liveCount is 1 while runningCount is 2
memberless coordinator still counts as 1, so a mid-spawn workflow does not read as zero

Verified red/green: with the source change reverted the first test fails expected 2 to be 1; with it applied 48/48 pass. vp lint and tsgo --noEmit clean for both packages.

Scope

3 files, +35 / −5. No behavior change outside the two count readouts.

🤖 Generated with Claude Code

Note

Low Risk
UI-only count logic in client-runtime with targeted tests; no auth, data, or server behavior changes.

Overview
liveCount no longer treats workflow coordinators as working agents when they already have member rows, so the composer banner, panel footer, and inline cards agree (e.g. one running member reads as 1 working, not 2).

In deriveAgentPanelModel, liveCount is computed in the roster loop instead of runningCount + waitingCount. Live agents (running, pending, waiting) count toward liveCount unless they are a workflow coordinator with members—the same rule already used for totalTokens. A coordinator with no members still counts, so mid-spawn or between-phase runs do not show zero.

The Agents panel footer now displays model.liveCount directly. runningCount / waitingCount are unchanged and still sum to roster size with idle and settled.

Tests cover coordinator exclusion vs runningCount, and memberless coordinators still contributing liveCount of 1.

^{Reviewed by Cursor Bugbot for commit 17a1a6f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

liveCount previously equaled runningCount + waitingCount, which included workflow coordinators even when they duplicate work already counted via their members.
deriveAgentPanelModel now computes liveCount independently: non-workflow agents count if running, pending, or waiting; coordinators only count when they have no members.
The AgentsPanel footer now uses model.liveCount directly instead of summing runningCount + waitingCount.
Behavioral Change: the working-agents count shown in the UI will be lower in workflows where coordinators have active members.

^{Macroscope summarized 17a1a6f.}

coderabbitai · 2026-08-09T09:13:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9cdc43c0-17c7-4470-a9e9-120cebd9b728

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-08-09T09:17:41Z

Approvability

Verdict: Approved be6bf47

A straightforward bug fix that corrects an inflated agent count in the UI by excluding workflow coordinators from the "working" tally. The change follows an existing pattern in the same file, is well-documented in code comments, and includes comprehensive unit tests.

^{You can customize Macroscope's approvability policy. Learn more.}

…ing agent deriveAgentPanelModel tallied liveCount over every agent in the roster, including the workflow coordinator. A workflow running a single member therefore reported two live agents: the composer banner read "2 agents working in the background" and the Agents panel footer read "2 working", while the inline spawn card — which counts members only — correctly read "1 working". liveCount now applies the same coordinator-exclusion rule the totalTokens sum two lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member (or is between phases) does not read as zero agents. runningCount/waitingCount keep counting every roster entry, preserving the bucket-sum invariant; AgentsPanel's footer switches to liveCount so both surfaces agree.

juliusmarminge · 2026-08-15T12:24:15Z

Closing as superseded by #6672, which merged and fixes the same underlying issue (#5807).

Both PRs patch deriveAgentPanelModel's coordinator double-count. #6672's fix is a strict superset of this one: it hoists a single continue that excludes a workflow coordinator (when it has members) from the whole status tally loop — runningCount, waitingCount, idleCount, settledCount, liveCount, and totalTokens — whereas this PR only corrects liveCount and left runningCount/waitingCount still counting the coordinator (relying on the panel switching to liveCount for display).

Rebasing this branch onto current main produces a real conflict in subagentRuntime.ts/subagentRuntime.test.ts against #6672's already-merged fix — confirming the overlap. Thanks for the report and the fix here; #6672 covers it. 🙏

artieeg · 2026-08-09T09:13:34Z

Closes#5807

What changed

deriveAgentPanelModel counted the workflow coordinator as one of the agents doing work. A workflow running a single member reported two:

composer banner: "2 agents working in the background"
Agents panel footer: "2 working · 1 settled"
inline spawn card: "Spine · 1 working" ← the only correct one

The tally loop in packages/client-runtime/src/state/subagentRuntime.ts iterated every roster entry, including the coordinator (kind === "workflow"), which stays running for the whole run. So liveCount = runningCount + waitingCount was always one higher than the number of agents actually working.

liveCount now applies the same coordinator-exclusion rule the totalTokens sum four lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member — or is between phases — does not read as zero agents.

runningCount / waitingCount still count every roster entry, preserving the existing bucket-sum invariant (idle + running + waiting + settled === roster.length). AgentsPanel's footer switches to liveCount so both surfaces agree with the inline card.

Why it should exist

The banner is the only visible Stop affordance for background work, so its count is what a user reads to decide whether anything is still running. It disagreed with the two other surfaces in the same view. With N concurrent workflows the banner is off by N, and a workflow whose members have all settled between phases reads "1 agent working" when zero are.

Note the inline card is unaffected and stays correct: "Kicked off 2 subagents" is the batch size (how many were spawned), not a live count.

Before / after

Identical fixture, one member running and one settled. Only the two counts differ.

	Banner	Panel footer
Before	`2 agents working in the background`	`● 2 working · 1 settled`
After	`1 agent working in the background`	`● 1 working · 1 settled`

Unchanged in both: inline card Kicked off 2 subagents · ride-shelf-v2 — Spine · 1 working, panel header 1/2 settled, RECON 1 done, SPINE 1 active · 0 done.

Before:

After:

Tests

Two cases added to subagentRuntime.test.ts:

coordinator excluded — liveCount is 1 while runningCount is 2
memberless coordinator still counts as 1, so a mid-spawn workflow does not read as zero

Verified red/green: with the source change reverted the first test fails expected 2 to be 1; with it applied 48/48 pass. vp lint and tsgo --noEmit clean for both packages.

Scope

3 files, +35 / −5. No behavior change outside the two count readouts.

🤖 Generated with Claude Code

Note

Low Risk
UI-only count logic in client-runtime with targeted tests; no auth, data, or server behavior changes.

Overview
liveCount no longer treats workflow coordinators as working agents when they already have member rows, so the composer banner, panel footer, and inline cards agree (e.g. one running member reads as 1 working, not 2).

In deriveAgentPanelModel, liveCount is computed in the roster loop instead of runningCount + waitingCount. Live agents (running, pending, waiting) count toward liveCount unless they are a workflow coordinator with members—the same rule already used for totalTokens. A coordinator with no members still counts, so mid-spawn or between-phase runs do not show zero.

The Agents panel footer now displays model.liveCount directly. runningCount / waitingCount are unchanged and still sum to roster size with idle and settled.

Tests cover coordinator exclusion vs runningCount, and memberless coordinators still contributing liveCount of 1.

^{Reviewed by Cursor Bugbot for commit 17a1a6f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

liveCount previously equaled runningCount + waitingCount, which included workflow coordinators even when they duplicate work already counted via their members.
deriveAgentPanelModel now computes liveCount independently: non-workflow agents count if running, pending, or waiting; coordinators only count when they have no members.
The AgentsPanel footer now uses model.liveCount directly instead of summing runningCount + waitingCount.
Behavioral Change: the working-agents count shown in the UI will be lower in workflows where coordinators have active members.

^{Macroscope summarized 17a1a6f.}

coderabbitai · 2026-08-09T09:13:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9cdc43c0-17c7-4470-a9e9-120cebd9b728

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-08-09T09:17:41Z

Approvability

Verdict: Approved be6bf47

A straightforward bug fix that corrects an inflated agent count in the UI by excluding workflow coordinators from the "working" tally. The change follows an existing pattern in the same file, is well-documented in code comments, and includes comprehensive unit tests.

^{You can customize Macroscope's approvability policy. Learn more.}

…ing agent deriveAgentPanelModel tallied liveCount over every agent in the roster, including the workflow coordinator. A workflow running a single member therefore reported two live agents: the composer banner read "2 agents working in the background" and the Agents panel footer read "2 working", while the inline spawn card — which counts members only — correctly read "1 working". liveCount now applies the same coordinator-exclusion rule the totalTokens sum two lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member (or is between phases) does not read as zero agents. runningCount/waitingCount keep counting every roster entry, preserving the bucket-sum invariant; AgentsPanel's footer switches to liveCount so both surfaces agree.

juliusmarminge · 2026-08-15T12:24:15Z

Closing as superseded by #6672, which merged and fixes the same underlying issue (#5807).

Both PRs patch deriveAgentPanelModel's coordinator double-count. #6672's fix is a strict superset of this one: it hoists a single continue that excludes a workflow coordinator (when it has members) from the whole status tally loop — runningCount, waitingCount, idleCount, settledCount, liveCount, and totalTokens — whereas this PR only corrects liveCount and left runningCount/waitingCount still counting the coordinator (relying on the panel switching to liveCount for display).

Rebasing this branch onto current main produces a real conflict in subagentRuntime.ts/subagentRuntime.test.ts against #6672's already-merged fix — confirming the overlap. Thanks for the report and the fix here; #6672 covers it. 🙏

artieeg · 2026-08-09T09:13:34Z

Closes#5807

What changed

deriveAgentPanelModel counted the workflow coordinator as one of the agents doing work. A workflow running a single member reported two:

composer banner: "2 agents working in the background"
Agents panel footer: "2 working · 1 settled"
inline spawn card: "Spine · 1 working" ← the only correct one

The tally loop in packages/client-runtime/src/state/subagentRuntime.ts iterated every roster entry, including the coordinator (kind === "workflow"), which stays running for the whole run. So liveCount = runningCount + waitingCount was always one higher than the number of agents actually working.

liveCount now applies the same coordinator-exclusion rule the totalTokens sum four lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member — or is between phases — does not read as zero agents.

runningCount / waitingCount still count every roster entry, preserving the existing bucket-sum invariant (idle + running + waiting + settled === roster.length). AgentsPanel's footer switches to liveCount so both surfaces agree with the inline card.

Why it should exist

The banner is the only visible Stop affordance for background work, so its count is what a user reads to decide whether anything is still running. It disagreed with the two other surfaces in the same view. With N concurrent workflows the banner is off by N, and a workflow whose members have all settled between phases reads "1 agent working" when zero are.

Note the inline card is unaffected and stays correct: "Kicked off 2 subagents" is the batch size (how many were spawned), not a live count.

Before / after

Identical fixture, one member running and one settled. Only the two counts differ.

	Banner	Panel footer
Before	`2 agents working in the background`	`● 2 working · 1 settled`
After	`1 agent working in the background`	`● 1 working · 1 settled`

Unchanged in both: inline card Kicked off 2 subagents · ride-shelf-v2 — Spine · 1 working, panel header 1/2 settled, RECON 1 done, SPINE 1 active · 0 done.

Before:

After:

Tests

Two cases added to subagentRuntime.test.ts:

coordinator excluded — liveCount is 1 while runningCount is 2
memberless coordinator still counts as 1, so a mid-spawn workflow does not read as zero

Verified red/green: with the source change reverted the first test fails expected 2 to be 1; with it applied 48/48 pass. vp lint and tsgo --noEmit clean for both packages.

Scope

3 files, +35 / −5. No behavior change outside the two count readouts.

🤖 Generated with Claude Code

Note

Low Risk
UI-only count logic in client-runtime with targeted tests; no auth, data, or server behavior changes.

Overview
liveCount no longer treats workflow coordinators as working agents when they already have member rows, so the composer banner, panel footer, and inline cards agree (e.g. one running member reads as 1 working, not 2).

In deriveAgentPanelModel, liveCount is computed in the roster loop instead of runningCount + waitingCount. Live agents (running, pending, waiting) count toward liveCount unless they are a workflow coordinator with members—the same rule already used for totalTokens. A coordinator with no members still counts, so mid-spawn or between-phase runs do not show zero.

The Agents panel footer now displays model.liveCount directly. runningCount / waitingCount are unchanged and still sum to roster size with idle and settled.

Tests cover coordinator exclusion vs runningCount, and memberless coordinators still contributing liveCount of 1.

^{Reviewed by Cursor Bugbot for commit 17a1a6f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

liveCount previously equaled runningCount + waitingCount, which included workflow coordinators even when they duplicate work already counted via their members.
deriveAgentPanelModel now computes liveCount independently: non-workflow agents count if running, pending, or waiting; coordinators only count when they have no members.
The AgentsPanel footer now uses model.liveCount directly instead of summing runningCount + waitingCount.
Behavioral Change: the working-agents count shown in the UI will be lower in workflows where coordinators have active members.

^{Macroscope summarized 17a1a6f.}

coderabbitai · 2026-08-09T09:13:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9cdc43c0-17c7-4470-a9e9-120cebd9b728

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-08-09T09:17:41Z

Approvability

Verdict: Approved be6bf47

A straightforward bug fix that corrects an inflated agent count in the UI by excluding workflow coordinators from the "working" tally. The change follows an existing pattern in the same file, is well-documented in code comments, and includes comprehensive unit tests.

^{You can customize Macroscope's approvability policy. Learn more.}

…ing agent deriveAgentPanelModel tallied liveCount over every agent in the roster, including the workflow coordinator. A workflow running a single member therefore reported two live agents: the composer banner read "2 agents working in the background" and the Agents panel footer read "2 working", while the inline spawn card — which counts members only — correctly read "1 working". liveCount now applies the same coordinator-exclusion rule the totalTokens sum two lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member (or is between phases) does not read as zero agents. runningCount/waitingCount keep counting every roster entry, preserving the bucket-sum invariant; AgentsPanel's footer switches to liveCount so both surfaces agree.

juliusmarminge · 2026-08-15T12:24:15Z

Closing as superseded by #6672, which merged and fixes the same underlying issue (#5807).

Both PRs patch deriveAgentPanelModel's coordinator double-count. #6672's fix is a strict superset of this one: it hoists a single continue that excludes a workflow coordinator (when it has members) from the whole status tally loop — runningCount, waitingCount, idleCount, settledCount, liveCount, and totalTokens — whereas this PR only corrects liveCount and left runningCount/waitingCount still counting the coordinator (relying on the panel switching to liveCount for display).

Rebasing this branch onto current main produces a real conflict in subagentRuntime.ts/subagentRuntime.test.ts against #6672's already-merged fix — confirming the overlap. Thanks for the report and the fix here; #6672 covers it. 🙏

artieeg · 2026-08-09T09:13:34Z

Closes#5807

What changed

deriveAgentPanelModel counted the workflow coordinator as one of the agents doing work. A workflow running a single member reported two:

composer banner: "2 agents working in the background"
Agents panel footer: "2 working · 1 settled"
inline spawn card: "Spine · 1 working" ← the only correct one

The tally loop in packages/client-runtime/src/state/subagentRuntime.ts iterated every roster entry, including the coordinator (kind === "workflow"), which stays running for the whole run. So liveCount = runningCount + waitingCount was always one higher than the number of agents actually working.

liveCount now applies the same coordinator-exclusion rule the totalTokens sum four lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member — or is between phases — does not read as zero agents.

runningCount / waitingCount still count every roster entry, preserving the existing bucket-sum invariant (idle + running + waiting + settled === roster.length). AgentsPanel's footer switches to liveCount so both surfaces agree with the inline card.

Why it should exist

The banner is the only visible Stop affordance for background work, so its count is what a user reads to decide whether anything is still running. It disagreed with the two other surfaces in the same view. With N concurrent workflows the banner is off by N, and a workflow whose members have all settled between phases reads "1 agent working" when zero are.

Note the inline card is unaffected and stays correct: "Kicked off 2 subagents" is the batch size (how many were spawned), not a live count.

Before / after

Identical fixture, one member running and one settled. Only the two counts differ.

	Banner	Panel footer
Before	`2 agents working in the background`	`● 2 working · 1 settled`
After	`1 agent working in the background`	`● 1 working · 1 settled`

Unchanged in both: inline card Kicked off 2 subagents · ride-shelf-v2 — Spine · 1 working, panel header 1/2 settled, RECON 1 done, SPINE 1 active · 0 done.

Before:

After:

Tests

Two cases added to subagentRuntime.test.ts:

coordinator excluded — liveCount is 1 while runningCount is 2
memberless coordinator still counts as 1, so a mid-spawn workflow does not read as zero

Verified red/green: with the source change reverted the first test fails expected 2 to be 1; with it applied 48/48 pass. vp lint and tsgo --noEmit clean for both packages.

Scope

3 files, +35 / −5. No behavior change outside the two count readouts.

🤖 Generated with Claude Code

Note

Low Risk
UI-only count logic in client-runtime with targeted tests; no auth, data, or server behavior changes.

Overview
liveCount no longer treats workflow coordinators as working agents when they already have member rows, so the composer banner, panel footer, and inline cards agree (e.g. one running member reads as 1 working, not 2).

In deriveAgentPanelModel, liveCount is computed in the roster loop instead of runningCount + waitingCount. Live agents (running, pending, waiting) count toward liveCount unless they are a workflow coordinator with members—the same rule already used for totalTokens. A coordinator with no members still counts, so mid-spawn or between-phase runs do not show zero.

The Agents panel footer now displays model.liveCount directly. runningCount / waitingCount are unchanged and still sum to roster size with idle and settled.

Tests cover coordinator exclusion vs runningCount, and memberless coordinators still contributing liveCount of 1.

^{Reviewed by Cursor Bugbot for commit 17a1a6f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

liveCount previously equaled runningCount + waitingCount, which included workflow coordinators even when they duplicate work already counted via their members.
deriveAgentPanelModel now computes liveCount independently: non-workflow agents count if running, pending, or waiting; coordinators only count when they have no members.
The AgentsPanel footer now uses model.liveCount directly instead of summing runningCount + waitingCount.
Behavioral Change: the working-agents count shown in the UI will be lower in workflows where coordinators have active members.

^{Macroscope summarized 17a1a6f.}

coderabbitai · 2026-08-09T09:13:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9cdc43c0-17c7-4470-a9e9-120cebd9b728

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-08-09T09:17:41Z

Approvability

Verdict: Approved be6bf47

A straightforward bug fix that corrects an inflated agent count in the UI by excluding workflow coordinators from the "working" tally. The change follows an existing pattern in the same file, is well-documented in code comments, and includes comprehensive unit tests.

^{You can customize Macroscope's approvability policy. Learn more.}

…ing agent deriveAgentPanelModel tallied liveCount over every agent in the roster, including the workflow coordinator. A workflow running a single member therefore reported two live agents: the composer banner read "2 agents working in the background" and the Agents panel footer read "2 working", while the inline spawn card — which counts members only — correctly read "1 working". liveCount now applies the same coordinator-exclusion rule the totalTokens sum two lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member (or is between phases) does not read as zero agents. runningCount/waitingCount keep counting every roster entry, preserving the bucket-sum invariant; AgentsPanel's footer switches to liveCount so both surfaces agree.

juliusmarminge · 2026-08-15T12:24:15Z

Closing as superseded by #6672, which merged and fixes the same underlying issue (#5807).

Both PRs patch deriveAgentPanelModel's coordinator double-count. #6672's fix is a strict superset of this one: it hoists a single continue that excludes a workflow coordinator (when it has members) from the whole status tally loop — runningCount, waitingCount, idleCount, settledCount, liveCount, and totalTokens — whereas this PR only corrects liveCount and left runningCount/waitingCount still counting the coordinator (relying on the panel switching to liveCount for display).

Rebasing this branch onto current main produces a real conflict in subagentRuntime.ts/subagentRuntime.test.ts against #6672's already-merged fix — confirming the overlap. Thanks for the report and the fix here; #6672 covers it. 🙏

artieeg · 2026-08-09T09:13:34Z

Closes#5807

What changed

deriveAgentPanelModel counted the workflow coordinator as one of the agents doing work. A workflow running a single member reported two:

composer banner: "2 agents working in the background"
Agents panel footer: "2 working · 1 settled"
inline spawn card: "Spine · 1 working" ← the only correct one

The tally loop in packages/client-runtime/src/state/subagentRuntime.ts iterated every roster entry, including the coordinator (kind === "workflow"), which stays running for the whole run. So liveCount = runningCount + waitingCount was always one higher than the number of agents actually working.

liveCount now applies the same coordinator-exclusion rule the totalTokens sum four lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member — or is between phases — does not read as zero agents.

runningCount / waitingCount still count every roster entry, preserving the existing bucket-sum invariant (idle + running + waiting + settled === roster.length). AgentsPanel's footer switches to liveCount so both surfaces agree with the inline card.

Why it should exist

The banner is the only visible Stop affordance for background work, so its count is what a user reads to decide whether anything is still running. It disagreed with the two other surfaces in the same view. With N concurrent workflows the banner is off by N, and a workflow whose members have all settled between phases reads "1 agent working" when zero are.

Note the inline card is unaffected and stays correct: "Kicked off 2 subagents" is the batch size (how many were spawned), not a live count.

Before / after

Identical fixture, one member running and one settled. Only the two counts differ.

	Banner	Panel footer
Before	`2 agents working in the background`	`● 2 working · 1 settled`
After	`1 agent working in the background`	`● 1 working · 1 settled`

Unchanged in both: inline card Kicked off 2 subagents · ride-shelf-v2 — Spine · 1 working, panel header 1/2 settled, RECON 1 done, SPINE 1 active · 0 done.

Before:

After:

Tests

Two cases added to subagentRuntime.test.ts:

coordinator excluded — liveCount is 1 while runningCount is 2
memberless coordinator still counts as 1, so a mid-spawn workflow does not read as zero

Verified red/green: with the source change reverted the first test fails expected 2 to be 1; with it applied 48/48 pass. vp lint and tsgo --noEmit clean for both packages.

Scope

3 files, +35 / −5. No behavior change outside the two count readouts.

🤖 Generated with Claude Code

Note

Low Risk
UI-only count logic in client-runtime with targeted tests; no auth, data, or server behavior changes.

Overview
liveCount no longer treats workflow coordinators as working agents when they already have member rows, so the composer banner, panel footer, and inline cards agree (e.g. one running member reads as 1 working, not 2).

In deriveAgentPanelModel, liveCount is computed in the roster loop instead of runningCount + waitingCount. Live agents (running, pending, waiting) count toward liveCount unless they are a workflow coordinator with members—the same rule already used for totalTokens. A coordinator with no members still counts, so mid-spawn or between-phase runs do not show zero.

The Agents panel footer now displays model.liveCount directly. runningCount / waitingCount are unchanged and still sum to roster size with idle and settled.

Tests cover coordinator exclusion vs runningCount, and memberless coordinators still contributing liveCount of 1.

^{Reviewed by Cursor Bugbot for commit 17a1a6f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

liveCount previously equaled runningCount + waitingCount, which included workflow coordinators even when they duplicate work already counted via their members.
deriveAgentPanelModel now computes liveCount independently: non-workflow agents count if running, pending, or waiting; coordinators only count when they have no members.
The AgentsPanel footer now uses model.liveCount directly instead of summing runningCount + waitingCount.
Behavioral Change: the working-agents count shown in the UI will be lower in workflows where coordinators have active members.

^{Macroscope summarized 17a1a6f.}

coderabbitai · 2026-08-09T09:13:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9cdc43c0-17c7-4470-a9e9-120cebd9b728

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-08-09T09:17:41Z

Approvability

Verdict: Approved be6bf47

A straightforward bug fix that corrects an inflated agent count in the UI by excluding workflow coordinators from the "working" tally. The change follows an existing pattern in the same file, is well-documented in code comments, and includes comprehensive unit tests.

^{You can customize Macroscope's approvability policy. Learn more.}

…ing agent deriveAgentPanelModel tallied liveCount over every agent in the roster, including the workflow coordinator. A workflow running a single member therefore reported two live agents: the composer banner read "2 agents working in the background" and the Agents panel footer read "2 working", while the inline spawn card — which counts members only — correctly read "1 working". liveCount now applies the same coordinator-exclusion rule the totalTokens sum two lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member (or is between phases) does not read as zero agents. runningCount/waitingCount keep counting every roster entry, preserving the bucket-sum invariant; AgentsPanel's footer switches to liveCount so both surfaces agree.

juliusmarminge · 2026-08-15T12:24:15Z

Closing as superseded by #6672, which merged and fixes the same underlying issue (#5807).

Both PRs patch deriveAgentPanelModel's coordinator double-count. #6672's fix is a strict superset of this one: it hoists a single continue that excludes a workflow coordinator (when it has members) from the whole status tally loop — runningCount, waitingCount, idleCount, settledCount, liveCount, and totalTokens — whereas this PR only corrects liveCount and left runningCount/waitingCount still counting the coordinator (relying on the panel switching to liveCount for display).

Rebasing this branch onto current main produces a real conflict in subagentRuntime.ts/subagentRuntime.test.ts against #6672's already-merged fix — confirming the overlap. Thanks for the report and the fix here; #6672 covers it. 🙏

artieeg · 2026-08-09T09:13:34Z

Closes#5807

What changed

deriveAgentPanelModel counted the workflow coordinator as one of the agents doing work. A workflow running a single member reported two:

composer banner: "2 agents working in the background"
Agents panel footer: "2 working · 1 settled"
inline spawn card: "Spine · 1 working" ← the only correct one

The tally loop in packages/client-runtime/src/state/subagentRuntime.ts iterated every roster entry, including the coordinator (kind === "workflow"), which stays running for the whole run. So liveCount = runningCount + waitingCount was always one higher than the number of agents actually working.

liveCount now applies the same coordinator-exclusion rule the totalTokens sum four lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member — or is between phases — does not read as zero agents.

runningCount / waitingCount still count every roster entry, preserving the existing bucket-sum invariant (idle + running + waiting + settled === roster.length). AgentsPanel's footer switches to liveCount so both surfaces agree with the inline card.

Why it should exist

The banner is the only visible Stop affordance for background work, so its count is what a user reads to decide whether anything is still running. It disagreed with the two other surfaces in the same view. With N concurrent workflows the banner is off by N, and a workflow whose members have all settled between phases reads "1 agent working" when zero are.

Note the inline card is unaffected and stays correct: "Kicked off 2 subagents" is the batch size (how many were spawned), not a live count.

Before / after

Identical fixture, one member running and one settled. Only the two counts differ.

	Banner	Panel footer
Before	`2 agents working in the background`	`● 2 working · 1 settled`
After	`1 agent working in the background`	`● 1 working · 1 settled`

Unchanged in both: inline card Kicked off 2 subagents · ride-shelf-v2 — Spine · 1 working, panel header 1/2 settled, RECON 1 done, SPINE 1 active · 0 done.

Before:

After:

Tests

Two cases added to subagentRuntime.test.ts:

coordinator excluded — liveCount is 1 while runningCount is 2
memberless coordinator still counts as 1, so a mid-spawn workflow does not read as zero

Verified red/green: with the source change reverted the first test fails expected 2 to be 1; with it applied 48/48 pass. vp lint and tsgo --noEmit clean for both packages.

Scope

3 files, +35 / −5. No behavior change outside the two count readouts.

🤖 Generated with Claude Code

Note

Low Risk
UI-only count logic in client-runtime with targeted tests; no auth, data, or server behavior changes.

Overview
liveCount no longer treats workflow coordinators as working agents when they already have member rows, so the composer banner, panel footer, and inline cards agree (e.g. one running member reads as 1 working, not 2).

In deriveAgentPanelModel, liveCount is computed in the roster loop instead of runningCount + waitingCount. Live agents (running, pending, waiting) count toward liveCount unless they are a workflow coordinator with members—the same rule already used for totalTokens. A coordinator with no members still counts, so mid-spawn or between-phase runs do not show zero.

The Agents panel footer now displays model.liveCount directly. runningCount / waitingCount are unchanged and still sum to roster size with idle and settled.

Tests cover coordinator exclusion vs runningCount, and memberless coordinators still contributing liveCount of 1.

^{Reviewed by Cursor Bugbot for commit 17a1a6f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

liveCount previously equaled runningCount + waitingCount, which included workflow coordinators even when they duplicate work already counted via their members.
deriveAgentPanelModel now computes liveCount independently: non-workflow agents count if running, pending, or waiting; coordinators only count when they have no members.
The AgentsPanel footer now uses model.liveCount directly instead of summing runningCount + waitingCount.
Behavioral Change: the working-agents count shown in the UI will be lower in workflows where coordinators have active members.

^{Macroscope summarized 17a1a6f.}

coderabbitai · 2026-08-09T09:13:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9cdc43c0-17c7-4470-a9e9-120cebd9b728

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-08-09T09:17:41Z

Approvability

Verdict: Approved be6bf47

A straightforward bug fix that corrects an inflated agent count in the UI by excluding workflow coordinators from the "working" tally. The change follows an existing pattern in the same file, is well-documented in code comments, and includes comprehensive unit tests.

^{You can customize Macroscope's approvability policy. Learn more.}

…ing agent deriveAgentPanelModel tallied liveCount over every agent in the roster, including the workflow coordinator. A workflow running a single member therefore reported two live agents: the composer banner read "2 agents working in the background" and the Agents panel footer read "2 working", while the inline spawn card — which counts members only — correctly read "1 working". liveCount now applies the same coordinator-exclusion rule the totalTokens sum two lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member (or is between phases) does not read as zero agents. runningCount/waitingCount keep counting every roster entry, preserving the bucket-sum invariant; AgentsPanel's footer switches to liveCount so both surfaces agree.

juliusmarminge · 2026-08-15T12:24:15Z

Closing as superseded by #6672, which merged and fixes the same underlying issue (#5807).

Both PRs patch deriveAgentPanelModel's coordinator double-count. #6672's fix is a strict superset of this one: it hoists a single continue that excludes a workflow coordinator (when it has members) from the whole status tally loop — runningCount, waitingCount, idleCount, settledCount, liveCount, and totalTokens — whereas this PR only corrects liveCount and left runningCount/waitingCount still counting the coordinator (relying on the panel switching to liveCount for display).

Rebasing this branch onto current main produces a real conflict in subagentRuntime.ts/subagentRuntime.test.ts against #6672's already-merged fix — confirming the overlap. Thanks for the report and the fix here; #6672 covers it. 🙏

artieeg · 2026-08-09T09:13:34Z

Closes#5807

What changed

deriveAgentPanelModel counted the workflow coordinator as one of the agents doing work. A workflow running a single member reported two:

composer banner: "2 agents working in the background"
Agents panel footer: "2 working · 1 settled"
inline spawn card: "Spine · 1 working" ← the only correct one

The tally loop in packages/client-runtime/src/state/subagentRuntime.ts iterated every roster entry, including the coordinator (kind === "workflow"), which stays running for the whole run. So liveCount = runningCount + waitingCount was always one higher than the number of agents actually working.

liveCount now applies the same coordinator-exclusion rule the totalTokens sum four lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member — or is between phases — does not read as zero agents.

runningCount / waitingCount still count every roster entry, preserving the existing bucket-sum invariant (idle + running + waiting + settled === roster.length). AgentsPanel's footer switches to liveCount so both surfaces agree with the inline card.

Why it should exist

The banner is the only visible Stop affordance for background work, so its count is what a user reads to decide whether anything is still running. It disagreed with the two other surfaces in the same view. With N concurrent workflows the banner is off by N, and a workflow whose members have all settled between phases reads "1 agent working" when zero are.

Note the inline card is unaffected and stays correct: "Kicked off 2 subagents" is the batch size (how many were spawned), not a live count.

Before / after

Identical fixture, one member running and one settled. Only the two counts differ.

	Banner	Panel footer
Before	`2 agents working in the background`	`● 2 working · 1 settled`
After	`1 agent working in the background`	`● 1 working · 1 settled`

Unchanged in both: inline card Kicked off 2 subagents · ride-shelf-v2 — Spine · 1 working, panel header 1/2 settled, RECON 1 done, SPINE 1 active · 0 done.

Before:

After:

Tests

Two cases added to subagentRuntime.test.ts:

coordinator excluded — liveCount is 1 while runningCount is 2
memberless coordinator still counts as 1, so a mid-spawn workflow does not read as zero

Verified red/green: with the source change reverted the first test fails expected 2 to be 1; with it applied 48/48 pass. vp lint and tsgo --noEmit clean for both packages.

Scope

3 files, +35 / −5. No behavior change outside the two count readouts.

🤖 Generated with Claude Code

Note

Low Risk
UI-only count logic in client-runtime with targeted tests; no auth, data, or server behavior changes.

Overview
liveCount no longer treats workflow coordinators as working agents when they already have member rows, so the composer banner, panel footer, and inline cards agree (e.g. one running member reads as 1 working, not 2).

In deriveAgentPanelModel, liveCount is computed in the roster loop instead of runningCount + waitingCount. Live agents (running, pending, waiting) count toward liveCount unless they are a workflow coordinator with members—the same rule already used for totalTokens. A coordinator with no members still counts, so mid-spawn or between-phase runs do not show zero.

The Agents panel footer now displays model.liveCount directly. runningCount / waitingCount are unchanged and still sum to roster size with idle and settled.

Tests cover coordinator exclusion vs runningCount, and memberless coordinators still contributing liveCount of 1.

^{Reviewed by Cursor Bugbot for commit 17a1a6f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

liveCount previously equaled runningCount + waitingCount, which included workflow coordinators even when they duplicate work already counted via their members.
deriveAgentPanelModel now computes liveCount independently: non-workflow agents count if running, pending, or waiting; coordinators only count when they have no members.
The AgentsPanel footer now uses model.liveCount directly instead of summing runningCount + waitingCount.
Behavioral Change: the working-agents count shown in the UI will be lower in workflows where coordinators have active members.

^{Macroscope summarized 17a1a6f.}

coderabbitai · 2026-08-09T09:13:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9cdc43c0-17c7-4470-a9e9-120cebd9b728

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-08-09T09:17:41Z

Approvability

Verdict: Approved be6bf47

A straightforward bug fix that corrects an inflated agent count in the UI by excluding workflow coordinators from the "working" tally. The change follows an existing pattern in the same file, is well-documented in code comments, and includes comprehensive unit tests.

^{You can customize Macroscope's approvability policy. Learn more.}

…ing agent deriveAgentPanelModel tallied liveCount over every agent in the roster, including the workflow coordinator. A workflow running a single member therefore reported two live agents: the composer banner read "2 agents working in the background" and the Agents panel footer read "2 working", while the inline spawn card — which counts members only — correctly read "1 working". liveCount now applies the same coordinator-exclusion rule the totalTokens sum two lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member (or is between phases) does not read as zero agents. runningCount/waitingCount keep counting every roster entry, preserving the bucket-sum invariant; AgentsPanel's footer switches to liveCount so both surfaces agree.

juliusmarminge · 2026-08-15T12:24:15Z

Closing as superseded by #6672, which merged and fixes the same underlying issue (#5807).

Both PRs patch deriveAgentPanelModel's coordinator double-count. #6672's fix is a strict superset of this one: it hoists a single continue that excludes a workflow coordinator (when it has members) from the whole status tally loop — runningCount, waitingCount, idleCount, settledCount, liveCount, and totalTokens — whereas this PR only corrects liveCount and left runningCount/waitingCount still counting the coordinator (relying on the panel switching to liveCount for display).

Rebasing this branch onto current main produces a real conflict in subagentRuntime.ts/subagentRuntime.test.ts against #6672's already-merged fix — confirming the overlap. Thanks for the report and the fix here; #6672 covers it. 🙏

artieeg · 2026-08-09T09:13:34Z

Closes#5807

What changed

deriveAgentPanelModel counted the workflow coordinator as one of the agents doing work. A workflow running a single member reported two:

composer banner: "2 agents working in the background"
Agents panel footer: "2 working · 1 settled"
inline spawn card: "Spine · 1 working" ← the only correct one

The tally loop in packages/client-runtime/src/state/subagentRuntime.ts iterated every roster entry, including the coordinator (kind === "workflow"), which stays running for the whole run. So liveCount = runningCount + waitingCount was always one higher than the number of agents actually working.

liveCount now applies the same coordinator-exclusion rule the totalTokens sum four lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member — or is between phases — does not read as zero agents.

runningCount / waitingCount still count every roster entry, preserving the existing bucket-sum invariant (idle + running + waiting + settled === roster.length). AgentsPanel's footer switches to liveCount so both surfaces agree with the inline card.

Why it should exist

The banner is the only visible Stop affordance for background work, so its count is what a user reads to decide whether anything is still running. It disagreed with the two other surfaces in the same view. With N concurrent workflows the banner is off by N, and a workflow whose members have all settled between phases reads "1 agent working" when zero are.

Note the inline card is unaffected and stays correct: "Kicked off 2 subagents" is the batch size (how many were spawned), not a live count.

Before / after

Identical fixture, one member running and one settled. Only the two counts differ.

	Banner	Panel footer
Before	`2 agents working in the background`	`● 2 working · 1 settled`
After	`1 agent working in the background`	`● 1 working · 1 settled`

Unchanged in both: inline card Kicked off 2 subagents · ride-shelf-v2 — Spine · 1 working, panel header 1/2 settled, RECON 1 done, SPINE 1 active · 0 done.

Before:

After:

Tests

Two cases added to subagentRuntime.test.ts:

coordinator excluded — liveCount is 1 while runningCount is 2
memberless coordinator still counts as 1, so a mid-spawn workflow does not read as zero

Verified red/green: with the source change reverted the first test fails expected 2 to be 1; with it applied 48/48 pass. vp lint and tsgo --noEmit clean for both packages.

Scope

3 files, +35 / −5. No behavior change outside the two count readouts.

🤖 Generated with Claude Code

Note

Low Risk
UI-only count logic in client-runtime with targeted tests; no auth, data, or server behavior changes.

Overview
liveCount no longer treats workflow coordinators as working agents when they already have member rows, so the composer banner, panel footer, and inline cards agree (e.g. one running member reads as 1 working, not 2).

In deriveAgentPanelModel, liveCount is computed in the roster loop instead of runningCount + waitingCount. Live agents (running, pending, waiting) count toward liveCount unless they are a workflow coordinator with members—the same rule already used for totalTokens. A coordinator with no members still counts, so mid-spawn or between-phase runs do not show zero.

The Agents panel footer now displays model.liveCount directly. runningCount / waitingCount are unchanged and still sum to roster size with idle and settled.

Tests cover coordinator exclusion vs runningCount, and memberless coordinators still contributing liveCount of 1.

^{Reviewed by Cursor Bugbot for commit 17a1a6f. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

[!NOTE]

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

liveCount previously equaled runningCount + waitingCount, which included workflow coordinators even when they duplicate work already counted via their members.
deriveAgentPanelModel now computes liveCount independently: non-workflow agents count if running, pending, or waiting; coordinators only count when they have no members.
The AgentsPanel footer now uses model.liveCount directly instead of summing runningCount + waitingCount.
Behavioral Change: the working-agents count shown in the UI will be lower in workflows where coordinators have active members.

^{Macroscope summarized 17a1a6f.}

coderabbitai · 2026-08-09T09:13:43Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 9cdc43c0-17c7-4470-a9e9-120cebd9b728

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

macroscopeapp · 2026-08-09T09:17:41Z

Approvability

Verdict: Approved be6bf47

A straightforward bug fix that corrects an inflated agent count in the UI by excluding workflow coordinators from the "working" tally. The change follows an existing pattern in the same file, is well-documented in code comments, and includes comprehensive unit tests.

^{You can customize Macroscope's approvability policy. Learn more.}

…ing agent deriveAgentPanelModel tallied liveCount over every agent in the roster, including the workflow coordinator. A workflow running a single member therefore reported two live agents: the composer banner read "2 agents working in the background" and the Agents panel footer read "2 working", while the inline spawn card — which counts members only — correctly read "1 working". liveCount now applies the same coordinator-exclusion rule the totalTokens sum two lines below already used: skip a coordinator that has members. A memberless coordinator still counts, so a workflow that has not spawned its first member (or is between phases) does not read as zero agents. runningCount/waitingCount keep counting every roster entry, preserving the bucket-sum invariant; AgentsPanel's footer switches to liveCount so both surfaces agree.

juliusmarminge · 2026-08-15T12:24:15Z

Closing as superseded by #6672, which merged and fixes the same underlying issue (#5807).

Both PRs patch deriveAgentPanelModel's coordinator double-count. #6672's fix is a strict superset of this one: it hoists a single continue that excludes a workflow coordinator (when it has members) from the whole status tally loop — runningCount, waitingCount, idleCount, settledCount, liveCount, and totalTokens — whereas this PR only corrects liveCount and left runningCount/waitingCount still counting the coordinator (relying on the panel switching to liveCount for display).

Rebasing this branch onto current main produces a real conflict in subagentRuntime.ts/subagentRuntime.test.ts against #6672's already-merged fix — confirming the overlap. Thanks for the report and the fix here; #6672 covers it. 🙏

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

macroscopeappBot approved these changes Aug 9, 2026
View reviewed changes

juliusmarminge force-pushed the fix/workflow-coordinator-live-count branch from be6bf47 to 17a1a6fCompare August 15, 2026 10:51

juliusmarminge enabled auto-merge (squash) August 15, 2026 11:31

juliusmarminge closed this Aug 15, 2026

auto-merge was automatically disabled August 15, 2026 12:24
Pull request was closed

ahmadhajji mentioned this pull request Aug 30, 2026
[Bug]: Workflow between phases reports zero working agents — banner, panel footer and badge all read as finished #8720
Open
2 tasks

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

macroscopeappBot approved these changes Aug 9, 2026
View reviewed changes

juliusmarminge force-pushed the fix/workflow-coordinator-live-count branch from be6bf47 to 17a1a6fCompare August 15, 2026 10:51

juliusmarminge enabled auto-merge (squash) August 15, 2026 11:31

juliusmarminge closed this Aug 15, 2026

auto-merge was automatically disabled August 15, 2026 12:24
Pull request was closed

ahmadhajji mentioned this pull request Aug 30, 2026
[Bug]: Workflow between phases reports zero working agents — banner, panel footer and badge all read as finished #8720
Open
2 tasks

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

macroscopeappBot approved these changes Aug 9, 2026
View reviewed changes

juliusmarminge force-pushed the fix/workflow-coordinator-live-count branch from be6bf47 to 17a1a6fCompare August 15, 2026 10:51

juliusmarminge enabled auto-merge (squash) August 15, 2026 11:31

juliusmarminge closed this Aug 15, 2026

auto-merge was automatically disabled August 15, 2026 12:24
Pull request was closed

ahmadhajji mentioned this pull request Aug 30, 2026
[Bug]: Workflow between phases reports zero working agents — banner, panel footer and badge all read as finished #8720
Open
2 tasks

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

macroscopeappBot approved these changes Aug 9, 2026
View reviewed changes

juliusmarminge force-pushed the fix/workflow-coordinator-live-count branch from be6bf47 to 17a1a6fCompare August 15, 2026 10:51

juliusmarminge enabled auto-merge (squash) August 15, 2026 11:31

juliusmarminge closed this Aug 15, 2026

auto-merge was automatically disabled August 15, 2026 12:24
Pull request was closed

ahmadhajji mentioned this pull request Aug 30, 2026
[Bug]: Workflow between phases reports zero working agents — banner, panel footer and badge all read as finished #8720
Open
2 tasks

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

macroscopeappBot approved these changes Aug 9, 2026
View reviewed changes

juliusmarminge force-pushed the fix/workflow-coordinator-live-count branch from be6bf47 to 17a1a6fCompare August 15, 2026 10:51

juliusmarminge enabled auto-merge (squash) August 15, 2026 11:31

juliusmarminge closed this Aug 15, 2026

auto-merge was automatically disabled August 15, 2026 12:24
Pull request was closed

ahmadhajji mentioned this pull request Aug 30, 2026
[Bug]: Workflow between phases reports zero working agents — banner, panel footer and badge all read as finished #8720
Open
2 tasks

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

macroscopeappBot approved these changes Aug 9, 2026
View reviewed changes

juliusmarminge force-pushed the fix/workflow-coordinator-live-count branch from be6bf47 to 17a1a6fCompare August 15, 2026 10:51

juliusmarminge enabled auto-merge (squash) August 15, 2026 11:31

juliusmarminge closed this Aug 15, 2026

auto-merge was automatically disabled August 15, 2026 12:24
Pull request was closed

ahmadhajji mentioned this pull request Aug 30, 2026
[Bug]: Workflow between phases reports zero working agents — banner, panel footer and badge all read as finished #8720
Open
2 tasks

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

macroscopeappBot approved these changes Aug 9, 2026
View reviewed changes

juliusmarminge force-pushed the fix/workflow-coordinator-live-count branch from be6bf47 to 17a1a6fCompare August 15, 2026 10:51

juliusmarminge enabled auto-merge (squash) August 15, 2026 11:31

juliusmarminge closed this Aug 15, 2026

auto-merge was automatically disabled August 15, 2026 12:24
Pull request was closed

ahmadhajji mentioned this pull request Aug 30, 2026
[Bug]: Workflow between phases reports zero working agents — banner, panel footer and badge all read as finished #8720
Open
2 tasks

github-actionsBot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:S 10-29 changed lines (additions + deletions). labels Aug 9, 2026

macroscopeappBot approved these changes Aug 9, 2026
View reviewed changes

juliusmarminge force-pushed the fix/workflow-coordinator-live-count branch from be6bf47 to 17a1a6fCompare August 15, 2026 10:51

juliusmarminge enabled auto-merge (squash) August 15, 2026 11:31

juliusmarminge closed this Aug 15, 2026

auto-merge was automatically disabled August 15, 2026 12:24
Pull request was closed

ahmadhajji mentioned this pull request Aug 30, 2026
[Bug]: Workflow between phases reports zero working agents — banner, panel footer and badge all read as finished #8720
Open
2 tasks

Uh oh!

Conversation

artieeg commented Aug 9, 2026• edited by cursor BotLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Why it should exist

Before / after

Tests

Scope

Fix liveCount in deriveAgentPanelModel to exclude workflow coordinators that have members

Uh oh!

coderabbitaiBot commented Aug 9, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

macroscopeappBot commented Aug 9, 2026

Approvability

Uh oh!

juliusmarminge commented Aug 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

artieeg commented Aug 9, 2026• edited by cursor BotLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Why it should exist

Before / after

Tests

Scope

Fix liveCount in deriveAgentPanelModel to exclude workflow coordinators that have members

Uh oh!

coderabbitaiBot commented Aug 9, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

macroscopeappBot commented Aug 9, 2026

Approvability

Uh oh!

juliusmarminge commented Aug 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

artieeg commented Aug 9, 2026• edited by cursor BotLoading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What changed

Why it should exist

Before / after

Tests

Scope

Fix liveCount in deriveAgentPanelModel to exclude workflow coordinators that have members

Uh oh!

coderabbitaiBot commented Aug 9, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

macroscopeappBot commented Aug 9, 2026

Approvability

Uh oh!

juliusmarminge commented Aug 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

artieeg commented Aug 9, 2026•
edited by cursor Bot
Loading

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

coderabbitaiBot commented Aug 9, 2026•
edited
Loading

artieeg commented Aug 9, 2026•
edited by cursor Bot
Loading

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

coderabbitaiBot commented Aug 9, 2026•
edited
Loading

artieeg commented Aug 9, 2026•
edited by cursor Bot
Loading

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

coderabbitaiBot commented Aug 9, 2026•
edited
Loading

artieeg commented Aug 9, 2026•
edited by cursor Bot
Loading

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

coderabbitaiBot commented Aug 9, 2026•
edited
Loading

artieeg commented Aug 9, 2026•
edited by cursor Bot
Loading

Fix `liveCount` in `deriveAgentPanelModel` to exclude workflow coordinators that have members

coderabbitaiBot commented Aug 9, 2026•
edited
Loading