1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
//! OSS metering — pipeline-observed cost data captured to local SQLite.
//!
//! The OSS bitrouter binary uses this module as its sole settlement
//! recorder. It is **not** a shared library plugin: a closed cloud product
//! (or any deployment with its own billing pipeline) writes its own
//! `SettlementRecorder` impl against the SDK trait and skips this entirely.
//!
//! What the module does, end-to-end:
//!
//! 1. [`MeteringRecorder`] is a `SettlementRecorder` registered on the LM
//! pipeline. After every request (success or failure) it computes the
//! estimated micro-USD from the configured [`PricingTable`] and the
//! pipeline-observed token counts, then writes a row to the `requests`
//! table via [`MeteringStore`].
//! 2. [`MeteringStore`] owns the `requests` table — the single writer is
//! the recorder, the readers are the `policy` and `auth` modules in
//! the binary (no SDK trait between them, just a concrete type).
//!
//! This module does not charge anyone. The `estimated_charge_micro_usd`
//! column is what we'd bill *if* we were billing — it's read by the
//! policy module's `max_spend_micro_usd` enforcement, surfaced by
//! `bitrouter spend` (future work), and consumed by closed-source
//! billing plugins via their own recorder.
pub use RequestMetric;
pub use ;
pub use MeteringRecorder;
pub use ;
/// Render micro-USD for the agent-facing cost surfaces (`status --agent`
/// spend recap, the MCP tool-result footer, the `spawn` exit summary):
/// two decimals normally, four when the amount would otherwise round to
/// nothing.