Direct answer
A token budget is only meaningful when its workload mix is visible
The same dollar ceiling buys different token volume when output, uncached input, cache reads, and cache writes have different prices. This worksheet normalizes your four mix weights, derives one blended usage-based rate, then reverse-solves tokens and whole requests without treating a zero rate as free or unlimited usage.
Reverse a dollar budget into tokens and requests
Enter your own workload mix and per-million rates. The example values are illustrative and editable—not claims about current provider prices.
Estimated total tokens
5,249,343
Budget divided by the normalized blended rate.
Whole requests
104
Total tokens divided by tokens per request, rounded down.
Blended rate per 1M
$4.76
Weighted average of the four editable usage-based rates.
Uncached input tokens
2,624,671
50% of the normalized token mix
Cached input tokens
1,312,336
25% of the normalized token mix
Cache write tokens
262,467
5% of the normalized token mix
Output tokens
1,049,869
20% of the normalized token mix
Normalized token allocation
The calculator divides each positive weight by the sum of all weights. The visual always represents the resulting shares, even when the entered weights do not add to 100.
Budget-to-requests summary
Budget
$25.00
Your usage-based ceiling
Token runway
5,249,343
At the normalized blended rate
Whole requests
104
At 50,000 tokens/request
Worked example
Reverse-solving an illustrative $25 coding budget
The default weights already sum to 100, so their normalized shares are 50%, 25%, 5%, and 20%. Multiplying each share by its editable example rate produces a $4.7625 blended rate per million tokens. Dividing $25 by that rate yields about 5,249,344 mixed tokens. At 50,000 tokens per representative request, 104 whole requests fit; the fractional remainder is not rounded up. Change every assumption to match your own measured workload and current pricing before using the result in a budget.
Why cache mix and output share change runway
Uncached input
New prompts, instructions, code, and context use the ordinary input rate.
Cached input
A higher cache-read share can extend runway only when the entered cache-read rate is lower.
Cache writes
Creating a cache can have its own rate, so first-use cost should not be mislabeled as a read.
Output
Output often has a different rate; a small share can materially change the blended budget.
A reverse-budgeting workflow that can be calibrated
01
Measure
Take token buckets and total request size from representative coding-agent history.
02
Price
Paste current rates from the provider and model actually used; record the lookup date.
03
Reconcile
Compare the forecast with provider usage and invoices, then update the assumption that explains the gap.
Interpret each bucket before changing the mix
- Uncached input
- Prompt-side tokens priced as new input: system instructions, user requests, repository context, history, schemas, and tool results that are not billed as cache reads.
- Cached input
- Prompt-side tokens the provider recognizes as a cache hit. A repeated prefix is not automatically cached; provider rules and telemetry determine the billed bucket.
- Cache write
- Tokens charged for creating or refreshing cached prompt content. Treat writes separately when their rate differs from both ordinary input and cache reads.
- Output
- Generated model tokens, including prose, code, reasoning where reported, and tool-call arguments. External tool execution is a different boundary and can have separate fees.
Sensitivity levers worth testing
- Increase the output weight while holding the budget and rates fixed to see how long generations affect runway.
- Move weight between uncached and cached input without changing total prompt-side share to isolate cache economics.
- Vary tokens per request to translate the same token runway into short edits versus repository-scale agent tasks.
- Replace one blended model assumption with separate scenarios when agents route turns across models or tiers.
One coding-agent request can vary wildly
“Request” is a planning unit, not a stable provider billing object. An agent can read one file or an entire repository, retain or compact conversation history, call tools, spawn subagents, retry failures, switch models, and generate outputs of very different lengths. The calculator divides aggregate token runway by one average request size; it does not predict the exact number of tasks a real agent will finish.
Scope and privacy
Usage-based API estimate only
This math does not describe subscription credits, task limits, rolling windows, allowances, throttling, fair-use rules, taxes, enterprise discounts, or whether a plan includes the modeled usage. Native provider account and billing views are authoritative.
Browser-local worksheet
Values are held in page state and calculated in this browser. The worksheet does not submit your budget, mix, rates, or request assumptions. Reloading resets the example.
Methodology and limitations
Validation. Numeric inputs are constrained to finite, non-negative values and capped in the UI. The calculator requires a positive budget, request size, mix total, and blended rate. An invalid or all-zero priced mix shows an adjust-input state rather than implying free or unlimited usage.
Normalization and allocation. Every positive bucket weight is divided by the sum of all weights. The blended rate is the sum of each normalized share multiplied by its entered rate. The calculated token total is allocated back to those shares, with integer rounding reconciled in the output bucket.
Reverse calculation. Total tokens equal budget divided by blended per-million rate, multiplied by one million. Whole requests are the floor of total tokens divided by tokens per request, so the result never spends a partial remainder as a complete request.
Limitations. The estimate excludes provider routing changes, volume discounts, minimum charges, taxes, external tools, embeddings, storage, and subscription economics. Mix and request size are averages that can hide a wide distribution. Inputs and results stay browser-local; verify rates and reconcile the forecast with authoritative usage and billing data.
Sources
- LiteLLM model pricing dataset
Public model pricing reference used for API-equivalent estimates; provider billing remains authoritative.