Loved the honesty of this write-up — and the one number that could change its conclusion is the one not measured yet: joules per completed query.
Here is why it might dominate. Your swarm run took 38.3 s against the baseline’s 10.1 s. On ESP32-class nodes that stay Wi-Fi-awake while waiting, the extra energy is mostly time, not tokens: the coordinator and the waiting nodes burn close to their listening draw for the whole window. The 2,935 extra tokens are the visible overhead; the 28 extra seconds could be the expensive part.
For that to hold, waiting draw must be a large share of active draw — usually true for connected nodes that cannot deep-sleep mid-query, but it is exactly what your setup can settle. The check: power both runs from a metered supply, log total joules per query, and split the swarm’s energy into busy time versus waiting time using your own timestamps. If waiting comes in under roughly a fifth of the extra energy, this reading is wrong and tokens really are the cost.
If waiting does dominate, the headline result flips into something stronger: report confidence gained per joule, and let nodes sleep between coordination rounds. A swarm that wins on confidence per joule, measured at the battery, is a result nobody can argue with — and in our own small-robot battery work the delivered energy came in well under the pack’s label, so measuring beats trusting the datasheet.