Token burn rate dashboard
Knowing how many tokens you used yesterday is interesting; knowing what that implies for your monthly bill and your cost per user is what actually drives decisions. This dashboard turns a daily token count into a forward forecast and a unit-economics figure, so you can see whether your AI feature is sustainable before the invoice arrives.
What burn rate tells you
“Token burn rate” is the speed at which your application spends on language model inference, expressed as daily cost. A dashboard view matters because LLM bills can spike quickly as usage grows: a feature that costs $10/day at 1,000 users costs $500/day at 50,000 users, even if nothing else changes. Catching the slope early — while it is still within budget — is the difference between a managed rollout and a surprise invoice.
The cost-per-user figure is equally important. It tells you whether your pricing model covers your inference costs. If each active user costs $0.80 per month in tokens and you charge $5/month, you have comfortable margin. If they cost $4.50 per month, you may need to optimize prompts, route to cheaper models, or adjust pricing before scaling further.
How it works
You enter your average daily prompt and completion tokens. The dashboard prices each at the selected model’s per-million-token rate — output tokens usually cost several times more than input — to compute a daily burn. It then projects that across a 7-day week and a 30-day month. Finally, dividing projected monthly spend by your active user count yields an average cost per user, the number that tells you whether your pricing covers your inference.
daily_burn = (prompt_tokens / 1M × input_price) + (completion_tokens / 1M × output_price)
monthly_cost = daily_burn × 30
cost_per_user = monthly_cost / active_users
Reading the output/input ratio
Most providers charge more for output tokens than input tokens — often 3–5× more. This means the ratio of your completion tokens to prompt tokens has an outsized effect on cost. A few patterns to watch for:
- Completion-heavy workloads (long generated responses, creative writing, detailed code): output cost dominates. Reducing
max_tokensor shortening generated responses has a bigger impact than trimming your system prompt. - Prompt-heavy workloads (large documents, RAG with long retrieved chunks, detailed system prompts sent on every call): input cost dominates. Chunking better, caching common prompt prefixes, or summarizing context reduces this.
- Balanced workloads (conversational chat with moderate back-and-forth): optimizing either side helps roughly equally.
Tips for accurate forecasting
- Pull real numbers. Most providers expose daily token usage in their dashboard — use those rather than guessing, then sanity-check the forecast.
- Cost per user is an average. Segment power users separately if a small cohort drives most of the spend — they may need a higher tier or a rate limit.
- Prices are editable estimates. Confirm current per-million-token rates in your provider dashboard before committing a budget.
- Add a 20% buffer. Real usage tends to creep upward as users discover more of the product; a 20% overhead on your projection is a reasonable safety margin.