Features, users, and allocation

Cost data is only useful if it maps to something you can act on. Radicas attributes every unit of spend along two axes — feature and user — and extends that attribution to spend that providers never meter, such as coding-assistant seats.

Feature tagging with radicas.feature

radicas.init(feature="flight-pricing") stamps radicas.feature onto every span the process emits. A feature is a product capability — the thing you would put on a pricing page — not a service or a repository. Because the tag rides the span tree, every LLM call and tool call rolls up to its feature, and estimated cost aggregates per feature automatically. This is what powers the profitability view: cost per feature against the value that feature generates.

User context

Spans can also carry user identity (user.id), attributing usage to the end user or developer who triggered it. Per-user attribution answers its own questions — who drives spend, which accounts are heavy — and it is the backbone of seat allocation below, where a person's usage share determines their slice of a seat's cost.

Rate cards: how providers actually bill

Providers bill in three distinct models, and Radicas keeps a rate-card layer describing all of them:

• Metered token — exact currency per token (provider APIs). Directly reconcilable.
• Token-to-credit — tokens convert to credits via a published rate card, but the credit price itself may be unpublished; where Radicas estimates it, the figure is provenance-flagged as estimated.
• Seat pool — a fixed seat price with an opaque, multi-factor allowance (Claude Code, ChatGPT seats, GitHub Copilot). The drawdown unit is not reconstructable from tokens.

Rate cards are effective-dated because provider pricing changes month to month; keeping them current is part of the product.

Share-of-seat allocation

Seat costs are allocated, never metered. Each workload gets a weight — its token-cost-equivalent (tce): the workload's exact tokens priced at standard API rates, cache-aware. A seat's cost is then split in proportion: a workload's allocated cost is the seat price multiplied by its share of the window's total tce. The weight is honest about what it is — a usage share, not a cost measurement — so allocated figures carry cost_basis = allocated and are never rendered as reconciled. Where providers publish aggregate usage reports (Claude Code analytics, Copilot usage), those arrive later as invoice-side anchors that tighten the allocation — joined by user, model, and day, never per span.

Rate cards and seats are managed in the allocation view.