Estimated vs. invoiced cost
Most cost figures in Plutus come straight from a provider’s own billing API — an invoiced number you could reconcile line-by-line against your bill. A smaller set of figures are estimated: computed from usage data and a rate, because the provider’s billing API doesn’t publish a real dollar figure for that source, or for that particular breakdown of an otherwise-invoiced source.
Estimated figures carry a visible badge next to the number in the Cost Explorer breakdown table. There are two labels:
- Estimated — built from rates the provider itself publishes or returns.
- Estimated (list rates) — built from a list-rate card Plutus maintains. Rates you negotiated with the provider aren’t reflected unless you set them on the connection.
The MCP query_costs tool carries the same information in a cost_basis field on each row. The
field is present only on estimated rows, with the value estimated_from_provider_rates or
estimated_from_static_rates. On invoiced rows it’s null. An assistant summarizing spend can
use it to know which numbers to qualify.
Ways a figure ends up estimated
Section titled “Ways a figure ends up estimated”Plutus multiplies usage by a rate the provider publishes. Hetzner, Databricks, Paperspace, and LambdaLabs are priced this way, using the rate each provider’s own API returns. Snowflake is too, when the connection’s grant can’t read real charged amounts. These figures are labelled Estimated.
The provider supplies its own estimate. DigitalOcean (nightly invoice item estimates), Datadog (its estimated-cost usage endpoint), Kubernetes (OpenCost’s allocation figures), and LiteLLM (the gateway’s per-request pricing) don’t expose a final invoiced figure through the API Plutus reads. Plutus uses the provider’s estimate as given. These are also labelled Estimated, and a month-end invoice total may differ.
Plutus applies its own list-rate card. HuggingFace and Neon are priced against a rate card Plutus maintains. These figures are labelled Estimated (list rates).
In all three cases, every dollar figure from the source is estimated, not just one breakdown of it.
A source is invoiced overall, but one breakdown isn’t. Anthropic publishes a real invoiced Cost Report — daily spend by model, and real per-workspace spend — but has no per-API-key cost endpoint. Plutus prices each key’s real token counts against a published per-model rate card to produce a dollar figure for the Identity breakdown, while the Account and Model breakdowns next to it stay exactly invoiced. Switching the breakdown dimension can switch a number from invoiced to estimated and back, for the same account, same source, same date range — see Anthropic for the specifics.
Rate cards are reviewed, not fixed at connector build time
Section titled “Rate cards are reviewed, not fixed at connector build time”The per-token rate cards for AI providers are checked weekly against LiteLLM’s community-maintained pricing data. A drifted rate fails a scheduled check, which surfaces as a failed run, rather than going stale silently the way a hand-maintained constant would. That check is a prompt to re-verify the rate against the provider’s own pricing page, not an automatic update.
Other rate cards, such as the ones for HuggingFace and Neon, have a freshness deadline instead: a card that hasn’t been re-verified within its window fails the build. Sources priced from provider-supplied rates have no Plutus-maintained card.
A model or SKU with no rate-card entry has its usage counted but left unpriced, rather than guessed at. An estimate that’s honestly incomplete is safer than one that’s confidently wrong.
Budgets and alerts
Section titled “Budgets and alerts”Enforcement (budgets, spend limits, anomaly detection) reads whichever cost figure the row actually carries — an estimated figure is a real number, not a placeholder, and is summed the same way an invoiced one is. There’s no separate “exclude estimated spend” mode.