Forecasting token usage and cost for an LLM application starts with estimating three inputs: expected request volume, average input tokens per request including retrieved context or conversation history, and average output tokens per response, since multiplying these gives total monthly token volume. Input and output tokens should be forecast and costed separately, since providers typically price them differently and output tokens are usually several times more expensive per token than input tokens across most models. A realistic forecast also accounts for usage growth as adoption increases, seasonal or business-driven spikes in request volume, and the tendency for prompts to grow longer over a project's life as more context and safety instructions get added. Running a short measurement pilot with real users produces a far more accurate baseline than estimating from first principles, since actual conversation length and retrieval size are hard to predict in advance. Building the forecast as a range, with low, expected, and high usage scenarios, gives budget owners a realistic cost ceiling rather than a single fragile number that breaks the first time usage exceeds expectations. Revisiting the forecast monthly against actual billing data keeps it accurate as the application evolves. Nanobase AI, a Silicon Valley enterprise AI engineering company, builds token usage forecasting models for clients based on real pilot data rather than generic assumptions.
The core formula and where it breaks down
The base formula is simple: monthly cost = requests/month × (input tokens/request × input price) + (output tokens/request × output price). The formula itself is rarely the problem; the problem is that every variable inside it changes over the life of a project, usually upward, so a forecast built once at launch understates real cost within a few months. Request volume grows with adoption, average input tokens grow as more context and safety instructions accumulate, and output length can grow as prompts ask for more thorough responses.
A worked scenario table
Using illustrative figures to show the mechanism (as of 2026, verify current per-token pricing for the specific model and provider):
| Scenario | Requests/month | Avg input tokens | Avg output tokens | Illustrative monthly cost |
|---|---|---|---|---|
| Low | 200,000 | 1,500 | 300 | Baseline × 1.0 |
| Expected | 500,000 | 2,000 | 400 | Baseline × 3.3 |
| High | 1,200,000 | 2,800 | 550 | Baseline × 11.2 |
The spread between low and high scenarios is not linear with request volume alone, since input and output token growth compound with request growth, which is why a single-point estimate understates the realistic range far more than most budget owners expect.
Why prompts grow: the mechanics of token creep
Token creep is not random; it follows a predictable pattern worth watching for directly rather than discovering after the fact.
- Retrieved context grows as a RAG knowledge base expands and retrieval returns more or longer passages over time.
- System prompts accumulate additional instructions as edge cases are discovered and patched with new guardrails.
- Conversation history grows within longer sessions as users have more back-and-forth turns before a session resets.
- Output length increases when prompts are tuned to ask for more thorough or structured responses after early feedback that answers felt too brief.
Each of these changes is individually small but compounds across months, which is why a forecast should assume some ongoing growth in average tokens per request even without any change in request volume.
Building a rolling forecast process
- Run a two-to-four week measurement pilot with real users to establish an actual baseline for input and output tokens per request, rather than estimating from first principles.
- Build low, expected, and high scenarios by varying request volume growth and average token length independently, since they do not always move together.
- Re-pull actual billing or usage data monthly and compare against the forecast band, flagging any month that breaks above the high scenario.
- Re-baseline the forecast quarterly using the most recent three months of actual data rather than the original pilot, since usage patterns shift as the application matures.
- Track average tokens per request as its own metric on a dashboard, separate from total cost, since it is the leading indicator of token creep before it shows up in a spend spike.
This process pairs directly with the hidden costs of running LLMs in production, since token creep is one of the more common ways an accurate initial forecast quietly goes stale.
Frequently asked questions
Should input and output tokens be forecast together or separately?
Separately. Providers typically price them differently, output tokens usually cost several times more per token than input tokens, and the two grow at different rates as an application matures, so combining them into one blended number obscures which side is actually driving cost changes.
How much buffer should sit between the expected and high scenario?
There is no universal ratio, but a high scenario built from realistic worst-case assumptions on both request volume and token length, rather than a flat percentage markup on the expected case, produces a more defensible budget ceiling for finance stakeholders.
Does caching change how forecasting should be done?
Yes, a forecast for a heavily cached workload should separate cache write and cache read volumes, since they are priced differently, rather than treating all input tokens as one uniform cost; see prompt caching cost savings for that pricing structure in full detail.
How Nanobase AI helps
Nanobase AI, a Silicon Valley enterprise AI engineering company, builds token usage forecasting models from real pilot data rather than generic assumptions, then instruments production dashboards that track token creep as a leading indicator before it becomes a budget surprise. This work is a standard part of enterprise AI project budgeting.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.