"How much does my LLM app cost per month?" is the wrong question and the right question at the same time. It is wrong because the answer is your traffic — which you have not plugged in yet. It is right because a planned number, with the three assumptions named so you can replace them, is what a budget review actually needs. This is that number-range for three archetypes, with worked math and the variables that move each bar.
Two rate facts anchor every estimate below (live rates move, so verify against the catalog before you commit): a mid-tier output-heavy class at roughly $3/M input and $15/M output list price — output runs 3-5x input — and cached prefix reads at roughly 10% of the input price. A front-tier class is several times higher; a low class several times lower. The method is identical across them.
Archetype 1: the support chatbot
Profile: tier-1 deflection at real volume. Average request, 1,500 input tokens (system plus the topical context fetched per request — no persistent memory) and 300 output. Ten thousand requests a month. Mix: 70% of requests on the low class (routing, FAQ), 30% on the mid class (anything that touches a tool).
Estimate:
- Low class: 7,000 requests x (1,500 x $1/M + 300 x $4/M) = 7,000 x $0.0027 = about $19.
- Mid class: 3,000 requests x (1,500 x $3/M + 300 x $15/M) = 3,000 x $0.009 = about $27.
- Total, about $46, plus 10-20% headroom for retries and failover — plan at $60 per month.
The variables that move this bar: the context you fetch per request (it is the input — trim it and the whole bar falls), the mix split (moving ten percent of traffic from low to mid nearly doubles that slice's per-request cost), and retries (a retry re-sends the same context at full input).
Archetype 2: the RAG assistant
Profile: product, support, or legal documents. Average request, 8,000 input (retrieved chunks plus a short thread plus system) and 500 output. Twenty thousand requests a month, mid class, stable system prefix cached.
One request at list: 8,000 x $3/M + 500 x $15/M = $0.024 + $0.0075 = $0.0315. Twenty thousand of those: about $630, plus headroom — plan at roughly $750 per month.
The variables that move this bar are different here. Retrieval quality decides the input size (fewer, better chunks beat more, louder chunks — the input price multiplies them all), and the cache is worth what it is re-read: a one-shot RAG request applies the cache to the system prefix only, a modest saving; a multi-turn thread over the same retrieved set is where the re-read share climbs and the bar drops fastest. Compute the per-request cost at your mix before comparing vendors on headline rates.
Archetype 3: the coding agent
Profile: an in-product agent — code review help, refactoring assist, test generation. One task is about fifteen steps; each step carries a growing context, about 6,000 input and 800 output on average across the run. Tiering: 80% of steps on the low class, 20% on the mid. One thousand five hundred tasks a month, no cross-run cache, no batch, about ten percent of runs involve a retry.
One run: roughly 90K input and 12K output across the steps. Split by tier — the low-class share (72K in / 9.6K out): about $0.11; the mid-class share (18K in / 2.4K out): about $0.09. A run is about $0.20. Fifteen hundred runs: about $300, plus retry headroom — plan at roughly $350 per month, and treat that as the floor under a productive month, because agent spend is super-linear in task difficulty, not in request count.
The variables that move this bar are the four the agent-bill anatomy runs through: the tier per step class, the context budget and cache on the stable prefix, batch rates for latency-tolerant sub-steps, and stop conditions that bound rework. One of them, on the order of a quarter, moves this archetype's bar more than any model-switch.
What moves all the bars (and by how much)
- The output share of the mix. At 3-5x the input price, halving average output — concise answers, capped plans, smaller verification passes — cuts the per-request bar by more than switching to a cheaper input rate usually does.
- Cache hit rate. Multi-turn and agent work can be 50%+ re-read prefix; every ten points of hit rate is about a dime of the input bar. Cache the stable prefix and keep it engaged — engagement is an ops metric, not a model attribute.
- Retry and failover headroom. Plan 10-20%. Retries duplicate context at full input; a failover adds one duplicate replay of the largest context in the run.
- Batch share. Anything with a 24-hour SLA tolerance runs at roughly half price. The metric to compute: the fraction of your step volume that could live at that SLA.
Sanity-check it against your traffic
Replace the three inputs of each archetype — volume, request shape, mix — with your numbers, and the math becomes your budget. Two checks before you trust it: pull last month's actual usage (any provider console or your own log) and see which bar the reality pushed; then recompute at 2x volume — a bill that scales linearly is a healthy bill, and one that scales super-linearly is a context-replay or retry pathology wearing a traffic costume.
Live per-token rates by model class are in the model catalog — the numbers above are rounded list prices on a mid and a low class, and movement is part of the math. A per-key ledger to turn the sanity checks into a habit is in the docs; a key to run your own numbers against is at signup.