On-chain settlement drift is not an LLM cost-tracking problem

Metering has one ledger. Reconciliation has two.

An LLM token-cost tool reads a single source of truth — the provider's own usage API — and presents it back to you, sliced by call, by key, by agent tag. There's nothing to reconcile because there's nothing to disagree with: the provider's number is the number. That's why this category can be built well with straightforward metering and dashboarding, and why tools aimed at it (the thread we referenced elsewhere flagged useagentledger.com and agentixlabs.com as examples) can do a solid job without touching a blockchain.

An on-chain agent-wallet payment has two records that are supposed to match and sometimes don't: the transaction the chain actually confirmed, and the payment your system expected to happen given the x402 request that triggered it. Reconciliation is checking those two against each other and flagging where they diverge. That's a structurally different job than reading one authoritative ledger.

The three drift patterns that show up in practice

Double-charges: an x402-gated request times out or errors after the payment already cleared, the caller's retry logic doesn't know that, and it pays again. On a token-cost dashboard this doesn't exist as a category — a duplicate API call just looks like two calls. On-chain, it's two near-identical-amount transfers to the same recipient in a short window, and it's only visible if you're watching transfer patterns, not just totals against a budget ceiling.

Missed settlements: an x402 negotiation completes off-chain — the 402 challenge, the price, the retry-with-proof — but the on-chain transfer never gets seen, whether because it silently failed or because the polling that's supposed to catch it lagged behind. A token-cost tool has no equivalent failure mode, because the provider's usage record and the billing event are the same write.

Mis-attribution: two agents sharing one wallet means every outbound transfer from that address gets the same attribution label, whichever agent name got attached to the wallet. A token-cost tool sidesteps this because API keys are naturally per-caller in a way wallets aren't unless you enforce one-wallet-per-agent yourself.

Why you can't bolt this onto a metering tool

None of these three patterns are things a token-cost dashboard is failing to catch by oversight — they don't exist in that tool's data model at all. There's no transaction hash to check independently, no chain-timestamp-versus-request-timestamp join to attempt, no concept of "settlement" separate from "the API call happened." Adding on-chain drift detection to a metering tool means adding a chain-read path, an attribution layer keyed on wallet address instead of API key, and pattern detection for a failure class metering tools were never built to see. That's a different product, not a feature flag.

What this means for your fleet

If your spend question is "which model call was expensive," you want a token-cost tracker. If your spend question is "did this on-chain payment settle the way it should have, once, to the right agent," that's settlement reconciliation, and it needs to read the chain directly, not a provider's billing API. AgentCap is built for the second question — wallet-level attribution plus drift detection for double-charges, missed settlements, and mis-attribution across Base and Solana USDC transfers.