Docs/Cost & tokens

View as Markdown

Cost & tokens

How Cadence prices a session, and what "projected" vs "estimated" cost means.

Four token buckets, not one price

AI coding agents don’t charge a single flat rate per token. Cadence prices each session using four separately-priced token buckets:

  • Input tokens - what you sent the model
  • Output tokens - what it generated back
  • Cache-read tokens - cheaper re-reads of context the model has already seen
  • Cache-write tokens - the (usually pricier) cost of writing new context into cache

Getting this right matters: a session that looks expensive by raw token count can be cheap in practice if most of it was cache reads, and vice versa. This is why “how much did this PR cost?” isn’t a question you can answer by eyeballing a transcript - it’s exactly what Cadence computes for you.

Projected vs. estimated cost

Cadence shows two related numbers:

  • Projected cost is a live estimate, shown while a session is still active or freshly finished.
  • Estimated cost is the settled figure once all the accounting for that session is final.

Both are framed as “equivalent API cost” - what the session would have cost at standard per-token API pricing - regardless of whether you’re actually paying per-token or via a flat subscription. If you’re on a subscription plan, Cadence will say so explicitly rather than implying you were billed per token.

Sessions that run unusually expensive relative to your normal pattern are flagged (for example, a session using more than 3x your typical token volume), so outliers are easy to spot instead of getting lost in an average.

Where cost shows up

Per-session cost is visible wherever Cadence shows you a session - the desktop app’s local session detail view, and via cadence session view/cadence session list --json in the CLI. Because sessions are linked to the commits and PRs they produced, that same cost figure applies to a specific pull request, not just an average across your work.

Pricing tables

Token pricing is kept in sync with model/provider pricing centrally, so cost figures stay accurate as providers change their rates - you shouldn’t need to update anything on your end for pricing changes to show up correctly.