How it works
A walkthrough of the whole tool -- how you model an application, how the cost math actually works, where pricing comes from, and what you hand off to Finance at the end.
A walkthrough of the whole tool -- how you model an application, how the cost math actually works, where pricing comes from, and what you hand off to Finance at the end.
You build an Application as a top-to-bottom tree of function points -- each one is an AI inference call, a speech-to-text transcription, a two-way voice conversation, a non-AI step (a lookup, a business rule, a webhook -- optionally with its own flat $ cost and a real-world completion rate), or a decision point that branches into child workflows, either by AI classification or a deterministic business rule. The tree mirrors how the application actually runs: a step's call volume can be tied to the app's own base volume, to an upstream step, or set independently, so changing one number cascades correctly through everything downstream of it.
The full workflow -- Demo: AI Newsroom Assistant, a 4-turn chained AI conversation, a rule-based decision point, and a separate batch-mode step, all costed live
Every AI step gets a live per-call and monthly cost breakdown -- expressed as a low/expected/high range, not a single number, because that's the honest shape of the answer. The goal isn't to fake precision, it's to make that range as grounded in real billing mechanics as possible, instead of a flat "tokens × price" guess:
Every field on that step maps to one of those mechanics directly -- nothing is hidden. Volume picks how this step's daily call count is derived (the app's own volume, another step's resolved volume, or a manual number). Prompt sets whether this step chains off an earlier one and its average input/output tokens -- paste your prompt and get a free tiktoken estimate instantly, or click through to an exact live count straight from Anthropic's or Google's own token-counting API, side by side for comparison. Non-AI steps with a real flat cost (a courier fee, a per-page OCR charge) get their own simpler per-transaction line instead of token math that doesn't apply -- with a Cost Notes field for capturing how that number was derived, and the same Continuation % attrition modeling an AI step gets. Model is a live Rate Card lookup, not a hardcoded price. Extended Price Factors is where extended thinking, prompt caching, cacheable share %, execution mode (Standard/Batch/Flex/Priority), error/retry rate, and continuation % all live -- and the Cost Ledger below updates every one of those numbers live as you change any lever above it.
The full AI inference call editor -- every option in one place, from volume sourcing to the complete Cost Ledger
The Rate Card -- the shared catalog of every model's price, cache terms, Batch/Flex/Priority tier support -- is live-sourced from LiteLLM's community-maintained pricing data: roughly 1,400 models across ~25 providers, refreshed automatically once a day. No one has to notice a vendor changed a price and go update a spreadsheet -- and because the catalog keeps itself current, the cost model built on top of it stays current too, without anyone having to remember to come back and re-check a number. A modality toggle above the catalog switches between AI chat pricing, per-minute speech-to-text pricing, and combined text+audio voice-conversation pricing, so each function point type only ever prices against its own matching rate.
On top of that shared baseline, you can layer your own per-field overrides -- an Enterprise-negotiated rate, a different cache TTL, whatever your actual contract says -- without affecting anyone else's numbers, and without losing the benefit of future catalog refreshes on any field you haven't personally overridden.
A live catalog is exactly the wrong thing for a forecast you're trying to hold still, though -- a price moving underneath an already-built budget, with no record of what it was actually built against, defeats the point of budgeting at all. So the first time an application uses a given model, that model's pricing is pinned to the application itself as a full snapshot -- every calculation for that app, on screen and in the Excel export alike, resolves against its own frozen copy from then on, not whatever the shared catalog says today. Nothing changes out from under a forecast silently; when you're ready, one click refreshes a pinned model back to the live Rate Card.
The Rate Card -- live catalog + per-user pricing overrides, filtered to Anthropic's chat models
"Export to Excel" doesn't dump static numbers -- it writes a real multi-tab workbook (Assumptions, Summary, Variance, and one tab per costed function point) with genuine live Excel formulas. Change an assumed volume or a rate-card price directly in the spreadsheet, and the whole model recalculates in front of you, the same way it would in the app. The Variance tab exists for exactly this reason -- track budget against actual spend as it comes in, and revisit the model as real usage tells you more, instead of filing the estimate away as a one-time number.
The Cost Report -- the same low/expected/high range this page keeps mentioning, not a single number
I built Preflight for AI after a handful of discussions with engineering teams and finance teams, which surfaced a real gap between the people designing AI-powered applications and the people who have to budget for them. Engineers reason in tokens and model calls; Finance needs something real to plan around before a single line of code ships. When you're sitting with product and engineering teams walking through requirements, capturing every function point, model choice, and volume assumption in one place Preflight for AI isn't just documentation, it stores that information in a JSON document that drives the cost model itself, automatically, with nothing lost in translation between that conversation and what Finance sees.
This tool is my attempt at a bridge between the two worlds. It doesn't pretend to hand Finance one precise number -- AI cost modeling still rests on real assumptions, and the honest output is a range, not a point estimate. What it does do is ground that range in how these systems actually get billed, and stay a living model you can come back to and re-evaluate as those assumptions change, instead of a one-time guess.
-- Louis