0.4.29 added a guard against a pool holding one pod twice and asserted, in its
message and in the code, that this was what billed two A40s against a
max_pods=1 configuration. That attribution is not supported.

The $1.18/hr incident was two DISTINCT pod ids, four minutes apart in the
account listing, and its cause was the warm-floor top-up counting only healthy
pods against the cap -- fixed in 0.4.27. The duplicate was a later and separate
observation: a snapshot carrying two rows for one pod id, taken without
recording the model key, so two POOLS reporting one shared pod was never ruled
out. That case `_add_pod` does not address, since it dedupes within a pool.

The guard is kept, because two paths appended pods with no identity check
between them and that is a hazard on its own. What is removed is the claim that
it explains a billing event, and the invented detail of a pool "reporting 2 in
pool, 2 healthy, 2 at cap with 128 pages in flight while the card ran 31" as
though it had been read off that duplicate.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KnfkxBpcZ1v6ypRFFyhrVM