Estimated vs authoritative cost

Radicas keeps two versions of the truth about cost — on purpose. One is fast and approximate; the other is slow and exact. They come from two different standards, live in the same engine, and are joined daily.

Estimated: what the telemetry says right now

Every LLM call your agent makes produces an OTel gen_ai span carrying token usage. Radicas prices those tokens against a maintained price book, so an estimated cost exists per span within seconds of the call — attributable to a service, a feature, and a user in real time. It is an estimate: price books drift, and invoices apply discounts, credits, and rounding the telemetry cannot see.

Authoritative: what the invoice says later

Authoritative cost comes from provider invoices and cost reports, landing as FOCUS 1.3 ledger rows roughly 24–72 hours after the fact. It is exact about money but too late — and, on its own, too coarse — to operate agents with. That is why both standards exist: OTel gen_ai is operational truth, FOCUS 1.3 is financial truth.

The span ↔ line-item join

Once a day, Radicas reconciles the two: invoice line items are correlated with the spans that generated them, using span identity carried on the FOCUS side (x_span_id). A matched span's cost graduates from estimated to reconciled, and the variance between the two is surfaced — per provider, per model, per feature. This per-span join between an operational standard and a billing standard is the differentiator; the reconciliation view is where you watch it happen.

Not all cost reconciles: the cost_basis axis

Reconciliation per span only makes sense when the provider meters what you used. In reality there are three cost bases, and they are kept orthogonal:

• metered — token-priced plans (e.g. provider APIs). Exact rates; these figures can reconcile span-to-line-item.
• credit_estimated — token-to-credit plans where the credit price itself is estimated; the estimate is provenance-flagged.
• allocated — seat-governed plans such as Claude Code or GitHub Copilot seats. The invoice is a fixed seat price with an opaque drawdown; Radicas splits that price across workloads by usage share (see share-of-seat allocation).

An allocated figure never becomes reconciled. There is no per-span invoice line to match — the seat shows up as one purchase row whose cost is divided. The dashboard renders a distinct reconciled-by-allocation state instead, so the green reconciled state remains a measured, span-matched proof. If a number is an allocation, Radicas always says so.