Skip to main content

Understanding the numbers

Exactly what each figure on the dashboards means, and how it's calculated. (First read How RTK works for where the raw numbers come from.)

The three token counts​

Every command reports three numbers:

  • Tokens in — what was actually sent to the AI (the compact output).
  • Tokens out — what the AI replied.
  • Tokens saved — the noise RTK removed before sending (raw output − compact output).

"Consumed" = tokens in + tokens out. "Raw" = consumed + saved (what it would have cost without RTK).

Noise purged & the "% purged" gauge​

  • Noise purged = the sum of tokens saved over the period.
  • % purged = saved ÷ (saved + in + out) = saved ÷ raw. It's the share of the raw token volume that RTK stripped out. A gauge at 84% means 84% of what would have hit the model was noise RTK removed.

LLM cost avoided ($)​

The headline dollar figure estimates what you didn't spend:

  • Cost without RTK — the raw tokens priced at the model's rate.
  • Cost with RTK — the consumed tokens priced at the same rate.
  • Cost avoided = the difference — which works out to your saved tokens, priced at the model's input rate.

Details worth knowing:

  • Pricing comes from a per-model table (e.g. Opus, Fable, Sonnet, GPT-5, Gemini). These per-model rates are approximate — they're used to estimate value, not to bill you. If the model is unknown (or not in the pricing table), a default rate of $3 per 1M input tokens is applied.
  • The estimate uses the input price for all tokens — a deliberate, slightly conservative upper bound (RTK doesn't split input vs output pricing per command).
  • A model selector on the cost figure reprices the same saved tokens across several flagship models, so you can compare "what this would have cost on Opus vs Gemini".

:::note "Savings %" is a token ratio The savings percentage shown next to the cost is the same token ratio as % purged — not cost-avoided ÷ cost-without. Tokens and dollars track each other closely, but the percentage is measured in tokens. :::

Per-command: compression & impact​

On the By command tab:

  • Compression ratio = how much of that command's raw output RTK purged (0–100%). git diff at 85% means 85% of its output was noise.
  • Impact = that command's saved tokens as a percentage of your single highest-saving command. The top command is always 100%; it tells you where the big wins are.

Totals & periods​

  • Total commands = the number of usage events in the window (a straight count).
  • Period selector: daily = last 24 h, weekly = 7 days, monthly = 30 days, quarterly = 90 days (rolling windows).

By developer​

Grouped by the account that ran each command. If pseudonymization is on (the org default is off, but it fails safe to on if unset), developers appear as "Dev 1, Dev 2…"; turn it off in Settings → Privacy to show real names. Commands run under a shared machine token (no personal login) all collapse into a single "Anonymous"/"agent" row — see Sign in.

Consumption chart​

  • Consumed and saved per time bucket (consumed = in + out, saved = tokens saved).
  • The budget line is your monthly token budget (Settings) spread evenly across buckets — the sustainable per-bucket rate that would exactly exhaust the budget over a 30-day month.
  • The forecast is your current run-rate extrapolated to a full 30-day month, so you can see if you're trending over budget.

Savings opportunities (Discover)​

  • Potential savings = tokens you could have saved on commands that ran outside RTK. Newer CLIs report the estimate directly; otherwise a built-in table estimates it (e.g. a bypassed git status ≈ 180 tokens, git diff ≈ 500, cat ≈ 200).
  • Cost saveable = those potential tokens priced at roughly $15 per 1M (an approximate premium-model input rate) — a "leave nothing on the table" figure.

Two honest caveats​

  • Tokens saved is measured and reported by the CLI — the cloud trusts and sums it, it doesn't recompute it. The numbers are as good as your rtk version's measurement.
  • Very long, very high-volume windows are capped at 100,000 events server-side, so a 90-day view on an extremely active org can slightly undercount the tail.