With 0d78becb a prompt the cache, the KV store or the graph answers is no
longer bracketed by two reads of the meter: it is charged the stage's own
figure plus what a hit on that tier costs on this host, calibrated over a
batch the first time the tier answers. The CLI resolves one prompt a process,
so its hit is always the one that calibrates.
`eoc query` therefore prints, for a hit, an estimate (it printed
`measured(the meter's own cost)` for a cache hit on a live counter, and the
stage's estimate plus that cost for a KV or graph hit), and a `hit` line that
says where the figure came from: the per-hit nanojoules, the batch, what the
meter read over it and over no work; or why the tier has no calibration and
the cost is the stage's own figure. On the build host (M3 Ultra, release):
$ eoc query ping
stage : kv
payload: pong
cost : 53 µJ (estimated)
hit : a kv hit is charged 3357 nJ on this host, on top of the stage's
own figure: process-energy read 6876 µJ over 2048 lookups in one
span (24 µJ over none)
A prompt that falls through to the neural stage prints as before: the echo
backend's 50 J estimate plus what the counter read around the stage, an
estimate; measured only where the stage estimated nothing, which the
existing in-process test pins. `eoc meter`'s `query` line says how the meter
is used.
Tests: the CLI's own path for `ping`, a KV hit and then a cache hit, is an
estimate on every host; where the tier was calibrated the cost is the stage's
figure plus the whole microjoules of the calibrated one, and where it was
not, the stage's figure and a reason this host's meter can give (the stub
holds, the powermetrics stand-in fails its reads). It takes the lock the
burning tests take, since the meter's domain is the whole process. The `hit`
line is pinned on its own.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
3d941db705