An LLM will happily structure your TCO model and just as happily populate it with prices that were never true. This playbook splits the work cleanly: AI builds the model's skeleton and drafts the review narrative; every rate comes from a calculator, Infracost, or a billing export — never from the chat.
Tier: Core · Hands-on time: ~30 minutes
LLM pricing recall is unreliable by construction — prices change after training cutoffs, vary by region and tier, and the model interpolates plausible numbers when it doesn't know. That makes cost modeling the purest expression of this track's division of labor: the assistant is excellent at model structure (components, drivers, scenarios, sensitivity) and at turning billing data into readable findings, while deterministic verifiers — pricing calculators, Infracost, the console — own every number a CFO will see.
Have AI structure the model, with a no-numbers rule. Ask for the component inventory, cost drivers per component, growth scenarios, and the sensitivity dimensions worth modeling — explicitly instructing that every rate cell be left as VERIFY: <source to check> rather than filled. The skeleton is where the assistant adds real value; the numbers are where it subtracts it.
Fill rates from deterministic sources only. Calculator runs for managed services (screenshot or export the configuration), Infracost against the Terraform where the design has IaC, published price sheets for anything per-token or per-request. Record the source and date next to every rate — a TCO cell without provenance is a rumor.
Build the scenarios you'll be questioned on. Baseline, growth, and the ugly one (traffic 3x, or the discount assumption falls through). Rajesh, building the Meridian Retail TCO for the RFP:
Structure a 3-year TCO model for a retail support copilot: managed RAG
(vector index, embeddings, LLM API), app tier on containers, observability,
and a human-review workflow tool.
For each component: cost drivers, the unit each driver is priced in, and
which scenario variables move it. Scenarios: baseline (20K conversations/
month), growth (3x by year 2), and adverse (growth + 40% longer
conversations). Sensitivity: which two assumptions move total cost most?
Leave EVERY rate cell as "VERIFY: <named pricing source>". Do not state
any price, discount, or free-tier figure — I fill those from calculators.
Run the sensitivity honestly. Identify the two or three assumptions that dominate (usually volume, token-heavy components, and data egress) and show cost at the pessimistic end. A model that only shows the happy path is a sales document, not architecture.
For cost reviews, feed billing exports and demand attributed findings. Give the assistant the export (sanitized as needed) and require every finding — idle resources, oversizing, unattached volumes, egress anomalies — to carry the specific line items and resource identifiers behind it, so each claim is checkable in the console in one click.
Verify the findings before the narrative ships. Spot-check each claimed idle or oversized resource in the console; kill any finding you can't confirm. Then let the assistant draft the review narrative — findings, savings estimates from verified rates, recommended actions with owners — in the register your audience needs (pb-19's altitude discipline applies).
Package with provenance. The workbook with sourced rates, the scenario table, the sensitivity chart, and the narrative — plus a one-line methods note: "all rates from <calculator/Infracost/price sheet> as of <date>; no AI-recalled pricing." That sentence buys credibility cheaply.
Billing exports and TCO inputs reveal client scale, vendors, and strategy — check the MSA before any export reaches an external assistant. The standard path: sanitize exports (strip account identifiers, project names, and tags that name the client) or aggregate to service-level totals before AI touches them; run the narrative drafting in client-approved tenancy (Bedrock or Azure OpenAI in the client subscription) where available. The verification half of this playbook is naturally restricted-safe — calculators and Infracost run locally against IaC with no data leaving anywhere. For fully closed environments, a local Ollama model can structure models and draft narratives from sanitized aggregates; quality drops, but since every number comes from deterministic sources anyway, the trust story is unchanged.
AI structures the model and writes the story; calculators, Infracost, and the billing export supply every number — and the methods note saying so is part of the deliverable.