| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
All checks were successful
wai-quantum WebGPU member / does this change touch it (pull_request) Successful in 6s
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 14s
jouleclaw public surface must stay documented / Public-surface audit (jouleclaw-rs) (pull_request) Successful in 49s
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 54s
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m13s
wai-quantum WebGPU member / member · software Vulkan (linux) (pull_request) Successful in 1m49s
standards workspaces build + test / jouleclaw-rs (-nodebug, jouleclaw/jouleclaw-rs, -p jouleclaw-energy --features rapl,nvml, jouleclaw-rs, linux-arm64, -C target-feature=+fp16) (pull_request) Successful in 2m56s
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 3m30s
wai-quantum WebGPU member / shader checks · browser build · wasip2 inertness (pull_request) Successful in 3m24s
energy meters on real hardware / sink decode table · per-task energy and the GPU rail on macOS (pull_request) Successful in 2m16s
wai-quantum WebGPU member / member · Metal (macos) (pull_request) Successful in 2m46s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 1m42s
wai-quantum WebGPU member / member · integrated GPU, Vulkan (framework-128gb) (pull_request) Successful in 7m42s
wai-quantum WebGPU member / member · browser WebGPU (macos) (pull_request) Successful in 3m52s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 6m56s
wai-quantum WebGPU member / member · DX12 and Vulkan (cbio-windows) (pull_request) Successful in 11m48s
energy meters on real hardware / RAPL and NVML on jetson-hub (pull_request) Successful in 35s
energy meters on real hardware / sink decode table · RAPL on jetson-hub (NVML surveyed) (pull_request) Successful in 2m23s
wai-quantum WebGPU member / member · GPU, Vulkan (thor) (pull_request) Successful in 24m54s
wai-quantum WebGPU member / member · GPU, Vulkan (jetson-hub) (pull_request) Successful in 17m32s
A counter declares the smallest window over which its readings are not noise (min_window_ns: about 10 ms for RAPL and IOReport, 100 ms for NVML; 2 s for a Mac's SMC power integral). Across a shorter span its delta is whatever its updates and quantization gave, often zero or a whole update period, yet mesh graded it at the counter's grade: a few-millisecond request could be sealed HwShunt at 0 µJ, or ModelBased at a power reading's extrapolation. - SPEC 3.3: a span shorter than the minimum window of the counter that would grade it MUST NOT be graded HwShunt or ModelBased from that counter; it is an estimate of the request, and SHOULD be billed by an estimator that resolves the span's own length, so a short request is never billed zero. - HwMeter opens its own window (Meter::open_span), which Session uses: it times the span, and one shorter than the backend's floor (HwMeter::min_window) is billed this crate's EstimatorMeter over the span's own length, graded Estimator with no measured_uj, as a span across a failed read is. Past the floor the counter's figure stands, graded as before. min_window is zero where the bridge already bills by its estimator. - ProcessMeter: where ProcessSpanMeter falls back to the host meter, a span shorter than the host meter's floor is billed the same way. Spans its own CPU and GPU counters metered are not the host meter's and are unaffected. - jouleclaw-energy: ProcessSpanMeter::fallback_min_window, the active fallback meter's min_window_ns, so a caller can apply the rule. Additive. Each span is timed from after its opening read to before its closing one, a little shorter than the counter's own window, so a span at the floor is judged short rather than long. Tests: under a 50 ms floor a 20 ms span is Estimator at the estimator's figure for 20 ms, and a 60 ms span keeps the counter's figure and grade (HwShunt and ModelBased); the bridge's minimum window is its counter's until a failed read, then zero; a host-meter fallback span under the host floor is an estimate, past it the host figure stands, and a span this process's own counters metered keeps its grade. Linux x86_64: mesh-meter (default, hw-meter-rapl), mesh-core (hw-meter-rapl) and mesh-conformance pass; clippy clean. macOS (M3 Ultra): mesh-meter and mesh-core with hw-meter-apple pass, including a real in-process serve sealed HwShunt; clippy clean for mesh-meter and jouleclaw-energy. Co-Authored-By: Claude Opus 5.5 <[email protected]> |
||
| .. | ||
| conformance/v1 | ||
| mesh-rs | ||
| tools/joules-per-decision | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| LICENSE-SPEC | ||
| README.md | ||
| SPEC.md | ||
Mesh
Energy-accounted inference serving & routing. One of the Transaction Science open standards.
Mesh treats every inference as a metered transaction. A request declares a joule ceiling and a fidelity floor; the mesh routes it to the cheapest-sufficient model on the cheapest-sufficient backend, serves it under an energy meter, and seals a receipt whose headline figure is microjoules per accepted output token — measured at the meter, not estimated from a price list.
The serving shelf reports dollars per token and tokens per second. Mesh reports the number that is physical, comparable across hardware, and impossible to inflate: the joule.
- Spec:
SPEC.md(CC-BY-4.0) - Reference code:
mesh-rs/(Apache-2.0) - Conformance vectors:
conformance/v1/
The shape
ServeRequest ──▶ route (cheapest-sufficient) ──▶ authorise (JCP grant)
│
▼
meter + debit ◀── serve (engine) ──▶ tokens
│
▼
sealed JCR-1 receipt: µJ / accepted token
Four roles — caller, router, engine, steward — and four phases
per serve: route, authorise, meter, seal. The grant is decided by JCP's own
runtime before any work runs, so its expiry, caveats and remaining budget bind
here as at any JCP enforcement point, and the metered joules are debited
against it afterwards. A grant is spent only by its issuer, who signs each
presentation for one request, and only at the steward it was issued to; each
decision is journalled before the work, so a restart gives no budget back. See
SPEC.md §2.
The reference workspace
mesh-rs/ is a pure-Rust reference implementation:
| Crate | What it is |
|---|---|
mesh-schema |
wire types — ServeRequest, Fidelity, two-part Energy, RouteDecision, ServeOutcome |
mesh-router |
energy-weighted cheapest-sufficient routing with a full candidate audit |
mesh-engine |
the ServingEngine interface + a deterministic, weights-free ReferenceEngine |
mesh-engine-gguf |
a real backend (behind gguf): wraps the family's pure-Rust GGUF/Metal inference substrate so the mesh routes and meters actual model tokens |
mesh-meter |
the meter window; an always-available estimator + an optional bridge to the family hardware meter (RAPL / NVML / Apple) behind hw-meter, and ProcessMeter: this process's own CPU and GPU energy for an engine that runs in process, measured when a span covers the whole request |
mesh-receipt |
the mesh/1 receipt, JCR-1 sealing (det-CBOR + COSE_Sign1), and a hash-chained log |
mesh-core |
the orchestration that ties route → authorise → meter → seal together |
mesh-conformance |
the deterministic reference scenario, its checks, and the gen-vectors bin |
Mesh rides on JCP (a serve request is authorised by a JCP grant;
receipts seal in JCR-1), dispatches to runtimes such as
JouleClaw, and routes across compute described by
EOC and isolated by Sandbox. It introduces no new
cryptography (see SPEC.md §9).
Run it
cd mesh-rs
# all crates green
cargo test --workspace
cargo clippy --workspace --all-targets
# end-to-end: mint a JCP grant, serve, print the sealed receipt
cargo run -p mesh-core --example demo
# on Linux/RAPL or a CUDA/NVML box, meter real silicon (HwShunt provenance, where
# the counter is live; a counter that is not live falls back to the estimator)
cargo run -p mesh-core --example demo --features hw-meter-rapl
# regenerate the published conformance vectors
cargo run -p mesh-conformance --bin gen-vectors -- ../conformance/v1
# serve a REAL model end-to-end through Mesh (Falcon-H1 0.5B), seal the receipt
cargo run --release -p mesh-engine-gguf --features gguf --bin serve_falcon -- \
/path/to/falcon-h1-0.5b-instruct 12 "The capital of France is"
The serve_falcon run demonstrates the whole standard on real model tokens:
a JCP grant authorises each request (an underfunded grant is refused before any
decode runs), the cheapest-sufficient backend is chosen, the decode is metered,
and a mesh/1 receipt is sealed and hash-chained across the session — e.g.
prompt "The capital of France is" → " Paris. It is known for its historical landmarks", prompt "Photosynthesis is the process by which" → " plants convert sunlight into chemical energy in the form of", with both seals verifying
and the chain's prev-links intact.
The demo prints the route (every backend weighed, with the reason each was kept or rejected), the honest energy provenance, and the wedge metric — then verifies the sealed envelope under the steward key.
Status
v0.1.0-draft.1. Reference workspace builds and tests green (mesh-schema,
mesh-router, mesh-engine, mesh-meter, mesh-receipt, mesh-core,
mesh-conformance); cargo clippy --all-targets warning-free; published vectors
in conformance/v1/. The reference engine is deterministic and
weights-free; production backends implement the same ServingEngine interface —
mesh-engine-gguf (behind gguf) is a real one over the family's pure-Rust
GGUF/Metal substrate, kept out of the default build so it needs no weights.