---
name: silent-peer-may-be-out-of-usage-not-held
description: A live peer that goes silent mid-task with no file writes and no cargo may have exhausted account usage; an unfamiliar endpoint-list badge is not a cause until looked up
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 6c1b8106-fa83-4fff-8e19-385f80067f8b
  modified: 2026-09-06T17:58:27.050Z
---

2026-09-06 ~17:18Z: todlando went silent mid-W0 (no file writes after 16:42Z, no cargo on either
host, no answer to a status ask). `spt endpoint list` showed `ONLINE + CONTROLLED`; I told the
operator's terminal that meant "the operator holds a control session on him" and stood down.
Actual cause (operator, 17:57Z): todlando AND hertz ran out of usage on a shared account at
~5:36AM local. Two agents on one account exhaust together.

**Why:** I inferred a cause from a badge I had never looked up and reported it as fact. The
inference was comforting (someone else is driving) and wrong, and it cost ~40 min of a held
lane with no escalation.

**How to apply:** an unfamiliar badge/state word is a LOOKUP, not an explanation (`spt endpoint
list --help`, docs-site, or ask). A peer silent >15 min with ZERO measurable activity on both
hosts is an escalation to the operator ("X silent since T, no activity, cause unknown"), not a
classification. Shared-account peers fail TOGETHER — if one is silent, probe the other before
assuming a lane-local cause. See [[resumed-session-reground-before-acting]] for the resume
brief shape that got him back (measured last-write times + the next three steps).
