Cloud Bills Took a Decade to Get FinOps. AI Bills Won't Get That Long.

Watch what happened this month. Databricks moved Genie to pay-as-you-go. Every user gets a small free allowance, then the meter runs. And notice what shipped the same day: budgets, alerts, per-user spending limits. Not a follow-up release. Not "coming in Q4." The governance shipped with the meter. That detail is the whole story, and it took the industry ten years of cloud pain to learn it. Let me show you the pattern — and then let's compute the numbers your CFO is going to ask you for, before they ask. The three acts (every computing wave repeats them) I teach my MBA students that every computing wave walks through the same three acts. Act one: adoption without meters. Everyone experiments, nobody measures. Engineering spins up assistants, agents, RAG pipelines. The spend is small, distributed, and invisible — a rounding error across forty cost centers. Act two: the invoice. Some team discovers their AI assistant spend rivals their warehouse spend. This is the quarter someone screenshots the bill and posts it in the leadership channel. Every company gets exactly one of these moments, and it sets the tone for everything after. Act three: governance. Budgets, showback, unit economics. The discipline gets a name, then a foundation, then a job title. Cloud took ten years to walk that arc. FinOps became a practice around 2015, a foundation in 2019, a line on job postings after that. AI spend is compressing the same arc into quarters — and the platforms know it. That's why Databricks shipped cost controls with the meter, not after it. Vendors learned from the cloud era that metering without governance creates churn, not revenue. The skill isn't cutting the bill Here's what I tell the class: the skill isn't cutting the bill. It's knowing your unit economics before the invoice teaches them to you. Three numbers. If you can't name them today, act two is already on your calendar: Cost per query Cost per agent run Cost per answered question (not the same thing — see below) They're not hard to compute. They're just not computed. Here's the whole calculation, by hand, so nothing is hidden: # Unit economics of an AI assistant — the three numbers your CFO will ask for. # Prices per 1M tokens; swap in your model's actual rates. PRICE_IN, PRICE_OUT = 3.00, 15.00 # $/1M tokens, input and output def query_cost(tokens_in: int, tokens_out: int) -> float: return tokens_in / 1e6 * PRICE_IN + tokens_out / 1e6 * PRICE_OUT # A typical RAG query: system prompt + retrieved chunks + question in, # a few hundred tokens of answer out. tin, tout = 6_000, 500 per_query = query_cost(tin, tout) print(f"Cost per query: ${per_query:.4f}") # An agent run is not one query. It's a loop: plan, call tools, read results, retry. steps_per_run = 9 per_agent_run = per_query * steps_per_run print(f"Cost per agent run: ${per_agent_run:.4f}") # And 'answered question' carries the failure tax: reruns, abandoned sessions, # answers wrong enough that a human redid the work. success_rate = 0.72 per_answered = per_agent_run / success_rate print(f"Cost per answered q: ${per_answered:.4f}") # Now scale it to a company. users, queries_per_user_day, workdays = 800, 12, 22 monthly = users * queries_per_user_day * workdays * per_answered print(f"\nMonthly, 800 users: ${monthly:,.0f}") Enter fullscreen mode Exit fullscreen mode Cost per query: $0.0255 Cost per agent run: $0.2295 Cost per answered q: $0.3188 Monthly, 800 users: $67,320 Enter fullscreen mode Exit fullscreen mode Read that progression again, because it's where every AI budget surprise lives. The per-query number looks like nothing — two and a half cents, who cares. Multiply by the agent loop and the failure tax, scale to the org, and "who cares" is $67K a month. Nobody lied. The meter just compounds faster than intuition does. Plain: the gap between "cost per query" and "cost per answered question" is where act two happens. The number that changes behavior isn't the total Act-three governance is not a bigger spreadsheet. It's attribution — showback per team, per feature, per user, so the meter changes decisions instead of just documenting them. The minimum viable version is a log line: import json, time from datetime import datetime, timezone def metered_call(client, team: str, feature: str, **kwargs): """Wrap every LLM call. Attribution is a logging decision, not a platform purchase.""" t0 = time.monotonic() resp = client.messages.create(**kwargs) usage = resp.usage cost = usage.input_tokens / 1e6 * PRICE_IN + usage.output_tokens / 1e6 * PRICE_OUT print(json.dumps({ "ts": datetime.now(timezone.utc).isoformat(), "team": team, "feature": feature, "tokens_in": usage.input_tokens, "tokens_out": usage.output_tokens, "cost_usd": round(cost, 6), "latency_s": round(time.monotonic() - t0, 2), })) return resp Enter fullscreen mode Exit fullscreen mode That's it. Pipe those lines into the warehouse you already have, group by team and feature, and you have showback on day one — before any vendor sells you a FinOps-for-AI platform. When I rebuilt cost visibility on a Databricks AI pipeline this way, the spend went from $14K/month to $5.8K/month — and most of the reduction came not from optimization heroics but from attribution making waste visible: retry loops nobody owned, a dev environment calling the production model, one feature quietly responsible for 60% of the tokens. You can't fix what isn't attributed to anyone. Notice the resolution here, because it's the same as always: this is a data problem before it's an AI problem. Cost per answered question is a pipeline metric — it lives in your event logs, your usage tables, your warehouse. Teams that already treat their platform telemetry as a first-class dataset will walk into act three early. Teams that don't will get walked there by an invoice. The principle: every abstraction eventually sends an invoice. AI is just sending it faster. What was the first AI line item that made someone at your company ask "wait — how much?" I'm Vinicius Fagundes — principal data engineer, independent consultant, and MBA lecturer in São Paulo. I write about data pipelines and the economics that run on top of them, and take on a few platform projects per quarter through vf-insights.com.