No production path reports gateway spend into Grid's tenant_spend GCounter — increment_tenant_spend is only called from tests

[jordigilh]

Context

grid#40 (merged via grid#47) built the Grid-side half of tenant-budget tracking: a budgetPolicy CRD field, a tenant-keyed GCounter, SWIM gossip propagation, and a status.budgetStatus[] signal. #47's own description was explicit that enforcement/reporting is cross-repo:

Enforcement (degrade to a cheaper backend / reject at 100%) is explicitly out of scope here — that's cross-repo, gateway-side praxis-ai policy-filter work.

That's the right call, but checking today, the other half doesn't exist anywhere yet: every call site of GridStateSnapshot::increment_tenant_spend in this repo is inside a #[test] module (swim_runtime.rs, swim/src/node.rs, swim/src/state_broadcast.rs, crdt/src/grid_state.rs). There's no HTTP/gRPC endpoint, no SWIM participation from the gateway side, no anything — a real deployment has no way to actually get spend data into the counter this whole feature is built around.

Why this matters now

The ai-side pieces that would produce this data are in flight in parallel:

• ai#658 / ai#121 (Token Rate Limiting) — computes token-denominated costs at the gateway, but doesn't reference Grid or emit a spend report anywhere in its current design.
• ai#577 (external_metering filter, PR ai#581) — closest existing candidate; already does pre-request balance checks and post-response usage reporting, just to an external billing service, not Grid.
• ai#191 (Agent budget enforcement) — explicitly assumes "gateway-local tracking," consistent with my own design comment on grid#40, but never specifies the wire format to Grid.

Nobody has picked "which filter, which protocol, which payload" for the actual gateway → Grid leg, and no issue currently tracks it.

Scope (proposed, not decided)

• Decide which ai-side filter is the reporter of record (extend ai#577's external_metering? a new filter? something in ai#658's reconciliation path?).
• Define the wire contract: does the gateway join SWIM directly (heavy), or does Grid expose a lightweight report-spend RPC/HTTP endpoint that increments the local site's GCounter slot (lighter, more likely)?
• Payload: tenant ID, amount in cents, site ID — mirrors cost_cents_for_tokens's test shape (operator/src/swim_runtime.rs) which already anticipates scoring::BackendConfig::cost_per_1k_input as the cost basis.

Related

• grid#40 / grid#47 — Grid-side plumbing this depends on (merged)
• grid#48 — open RBAC gap on the same budgetStatus signal
• grid#64 / grid#52 / grid#63 — active follow-on design work on tenant_spend epoch/window semantics
• ai#577, ai#191, ai#658, ai#301 — candidate reporters / parent epics on the ai side

[jordigilh]

Checked for collisions before picking this up. ai#658 (the token-rate-limiting PR this issue names as a candidate reporter) closed 2026-08-20 in the proposal migration to praxis-proxy/enhancements — no longer live, and nothing's replaced it yet.

No direct collision on this issue's scope: an org-wide search for tenant_spend, increment_tenant_spend, and report-spend turns up nothing but this issue. Two adjacent efforts from @nerdalert (opened 2026-08-20) are worth knowing about though: grid#84 (provider-selection contract) and ai#790 (Valkey-backed token quota across gateway replicas, not-for-merge demo groundwork). Both explicitly avoid touching Grid's tenant_spend, so it's a different problem, just flagging since the vocabulary overlaps and it's active in parallel.

One real blocker on the wire-contract choice: grid#75. StateBroadcast.origin_site is self-asserted and unauthenticated — receive_item merges tenant_spend keyed on that unverified field, so any peer holding the shared network key can forge another site's spend today. Both options this issue proposes inherit that:

• "gateway joins SWIM directly" inherits the forgery gap immediately — any gateway could report spend as another site/tenant.
• "lightweight report-spend RPC/HTTP endpoint" sidesteps SWIM, but still needs to authenticate who's reporting, and grid#75 shows that's not solved here yet.

Treating grid#75 as a prerequisite rather than a separate track, so whichever mechanism gets built doesn't start with the same spoofing hole.