"What will this AI feature cost us next quarter?" deserves a range, not a number. This playbook builds the pre-launch scenario model — adoption curves times tokens-per-interaction times model mix times cache hit rate — with explicit uncertainty bands and a monthly reconciliation ritual against gateway actuals.
Tier: Advanced · Hands-on time: ~35 minutes
The motivating statistic is uncomfortable: per the State of FinOps 2026 coverage, 73% of AI projects blow their budget — and the single biggest lever in the practitioner cost literature is model selection, with roughly a 50x cost spread reported between frontier and small models for the same task. Point forecasts fail here structurally, because launch cost is a product of four quantities you don't yet know. The honest artifact is a banded forecast with named assumptions and a review loop, which is also the artifact a CFO can actually govern against.
Decompose the forecast into its four factors. Monthly cost ≈ active users × interactions per user × tokens per interaction × effective cost per token — where the last factor bundles model mix and cache hit rate. Write each factor's current best estimate, its source, and your confidence in it. The decomposition is what makes disagreement productive: stakeholders argue about a factor, not a total.
Band each factor, don't point-estimate it. For each factor set low/expected/high with a one-line justification: adoption from comparable launches (or wide bands with "no comparable" declared), tokens-per-interaction from pb-42's measured profile plus a drift allowance (users write longer prompts than beta testers), cache hit rate degraded from bench results (production traffic is messier), model mix at design intent and at "escalation runs hot."
Build the scenario engine with AI structuring, sheet computing. Sameer, forecasting a document-summarization feature for the GCC's parent org:
Structure a launch cost forecast spreadsheet for an internal document-
summarization feature. Factors and bands (attached): eligible users
8,000; adoption 15/35/60% over 3 months; 2.4 interactions/user/week
(band ±50%); measured 5.2K input / 700 output tokens per interaction
(drift band +30%); two-tier model mix, 80/20 small-to-large intended
(band: 60/40 if escalation runs hot); prefix cache 40/55/70% hit.
Produce: the formula chain from factors to monthly cost; a scenario
grid (pessimistic/expected/optimistic per month for 6 months); which
two factors dominate the spread between pessimistic and expected; and
the assumption-log table (factor, band, source, owner, review date).
No currency rates — token prices come from my pb-42 model. Compute
nothing yourself; emit formulas for the spreadsheet.
Present the band, defend the band. The deliverable to finance is the range with its drivers: "₹X–₹Y monthly by month 3; the spread is 70% adoption uncertainty, 30% token drift." Resist the pressure to collapse to one number — offer the expected case for planning and the pessimistic case for the budget guardrail, and propose a spend alert at the band's upper edge.
Wire the guardrails before launch. Budget alerts at expected and pessimistic thresholds in the gateway or billing tooling, plus the pb-45 degradation ladder as the pre-agreed response if the pessimistic band breaks — "what we do if this runs hot" is part of the forecast package, not an incident-day improvisation.
Reconcile monthly, factor by factor. Pull gateway actuals and attribute variance to factors: adoption faster? tokens longer? cache colder? mix hotter? Update the bands and log the change. Three reconciliations in, the model is calibrated to reality — which is the actual goal; the launch forecast was just the ante.
Feed the deltas back into design. If token drift or mix-escalation dominates variance, that is a pb-47 cost-stack or routing finding, not merely a forecasting note. The forecast loop is how cost architecture learns.
Adoption data, user counts, and spend forecasts are commercially sensitive — under client MSAs, sanitize before external assistants see them (relative bands and orders of magnitude usually suffice for structuring). Run the scaffolding in client-approved tenancy where available; the spreadsheet itself is client work product and lives in their environment. Gateway actuals for reconciliation stay inside the client boundary — design the monthly reconciliation as a report the client's own tooling produces, which you review. Fully offline, a local Ollama model structures the scenario grid adequately; the forecast's quality never depended on the assistant anyway, but on the bands and the reconciliation ritual.
Forecast as four banded factors with named owners, present the range with its drivers, wire the alerts before launch, and reconcile monthly — a calibrated band beats a confident number every time the 73% statistic comes looking.