In a two-worker run (needle run --agent claude --count 2) with four beads queued, needle status reported Total beads processed: 5. Four beads completed, producing four commits.
Event counts over that window:
$ needle logs --since 10m --format json | grep -o '"event_type":"bead[^"]*"' | sort | uniq -c | sort -rn
15 "event_type":"bead.claim.verify_success"
5 "event_type":"bead.claim.verify_started"
5 "event_type":"bead.claim.succeeded"
5 "event_type":"bead.claim.attempted"
4 "event_type":"bead.completed"
1 "event_type":"bead.released"
The counter appears to track bead.claim.succeeded (5) rather than bead.completed (4). One bead was claimed, cleanly released, and re-claimed — visible as revision 7 against revision 3 for the other three.
No bead.orphaned and no race_lost: the release was voluntary and the work was recovered, which is the desired behaviour. Only the reported figure is affected.
Impact: the number overstates throughput whenever a bead is released and re-claimed, so capacity or cost estimates derived from it drift upward.
Suggested: count bead.completed, or report both — e.g. "4 completed / 5 claims".
Separate minor observation from the same data: bead.claim.verify_success = 15 against verify_started = 5, i.e. three successes logged per verification started. Possibly intentional if a verify runs multiple sub-checks — flagging it only in case it isn't.
Environment: needle 0.6.0, bead 0.2.4, Ubuntu 22.04.5 (WSL2).
In a two-worker run (
needle run --agent claude --count 2) with four beads queued,needle statusreportedTotal beads processed: 5. Four beads completed, producing four commits.Event counts over that window:
The counter appears to track
bead.claim.succeeded(5) rather thanbead.completed(4). One bead was claimed, cleanly released, and re-claimed — visible as revision 7 against revision 3 for the other three.No
bead.orphanedand norace_lost: the release was voluntary and the work was recovered, which is the desired behaviour. Only the reported figure is affected.Impact: the number overstates throughput whenever a bead is released and re-claimed, so capacity or cost estimates derived from it drift upward.
Suggested: count
bead.completed, or report both — e.g. "4 completed / 5 claims".Separate minor observation from the same data:
bead.claim.verify_success= 15 againstverify_started= 5, i.e. three successes logged per verification started. Possibly intentional if a verify runs multiple sub-checks — flagging it only in case it isn't.Environment: needle 0.6.0, bead 0.2.4, Ubuntu 22.04.5 (WSL2).