open-standards/mesh/mesh-rs/crates
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 9a6c28ff39 mesh-meter: the span meter's fallback window no longer holds its GPU waits
ProcessMeter's docs justified billing an estimated fallback span with this
crate's EstimatorMeter by the host meter's window taking in the span meter's
GPU-rail waits. jouleclaw-energy now reads the host meter inside the GPU
snapshots, so that window is the work's own and the reason no longer holds.
The behaviour is unchanged (an estimated request is still billed by this
crate's estimator over the work's window, as the rest of a partial span is);
the comments now say so instead of describing the old window.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-11 22:23:23 -04:00
..
mesh-conformance mesh: a typed decision is a unit of work this spec could not measure 2026-10-05 07:20:58 -04:00
mesh-core mesh §3.2: the fidelity floor was checked against the route table, not the serve 2026-10-09 02:51:33 -04:00
mesh-engine mesh §3.2: the fidelity floor was checked against the route table, not the serve 2026-10-09 02:51:33 -04:00
mesh-engine-gguf mesh: the gguf engine constructs ServeOutcome too, behind its own feature 2026-10-09 08:51:31 -04:00
mesh-meter mesh-meter: the span meter's fallback window no longer holds its GPU waits 2026-10-11 22:23:23 -04:00
mesh-openai mesh-meter: an estimate of a served span is never 0 µJ nor the meter's waits 2026-10-10 17:58:55 -04:00
mesh-receipt mesh §3.2: the fidelity floor was checked against the route table, not the serve 2026-10-09 02:51:33 -04:00
mesh-router mesh: a typed decision is a unit of work this spec could not measure 2026-10-05 07:20:58 -04:00
mesh-schema mesh §3.2: the fidelity floor was checked against the route table, not the serve 2026-10-09 02:51:33 -04:00