Lakemeter and the End of the Cost Conversation Nobody Could Win

There is a meeting that repeats itself in every enterprise that has started building on a data platform. A team has designed something good. The architecture is sound, the governance story holds, the use case has a sponsor. Then somebody from finance asks the only question that has ever stopped a project: what will this cost us per month at full volume. The room goes quiet, because the honest answer is that nobody knows. Somebody promises a number by Friday. On Friday a spreadsheet appears. Nobody can reproduce it, nobody can audit the assumptions inside it, and nobody quite trusts it, so the decision is made on confidence rather than arithmetic.

That is not a finance problem. It is an engineering problem wearing a finance costume. The reason nobody can produce the number is that the number depends on a dozen assumptions that live in engineers' heads: how many jobs, how often, how much data scanned, which compute type, which region, which discount tier, how many concurrent users, how many tokens per request. Every one of those assumptions is knowable. What was missing was a shared place to write them down in a form that another person could open, disagree with, and correct.

Databricks Labs has now published that place. Lakemeter is an open source cost estimation tool that runs as a Databricks App with built in single sign on, and its stated purpose is to create, manage, and export transparent sizing estimates for supported workloads. The word doing the work in that sentence is transparent. Not accurate, not authoritative, not final. Transparent. That is the correct ambition, and it is worth understanding why.

Strip away the framing and Lakemeter is a workload sizing calculator with an unusually serious attitude toward its own inputs. It gives you workload specific forms, so you are not filling in a generic template but answering the questions that actually drive spend for the workload in front of you. It produces a full cost breakdown with stock keeping unit level detail, discount calculations, and virtual machine pricing, and it exports the whole thing to Excel so the estimate can travel into the places where budget decisions are genuinely made. It carries a stock keeping unit explorer and a Foundation Model API token view, so pricing is something you can inspect rather than something you look up in a screenshot from last quarter. And it handles cloud, region, and pricing options, because the same design costs different amounts in different places.

It also includes an assistant. You describe your workload in ordinary language, the assistant proposes a set of usage assumptions, and you review that suggestion and accept it with one click if it is reasonable. Read that flow carefully, because it is a small masterclass in agent design. The model does not set the budget. It does not commit the estimate. It drafts the assumptions and hands them to a human who has the authority and the context to approve or reject them. That is the shape we argue for throughout the Control chapters, and specifically in Chapter 17 on why human review still matters and Chapter 14 on the difference between controlling access and controlling action.

The implementation choices are equally telling. The frontend is React and TypeScript, the backend is FastAPI, the database is Lakebase, which is managed PostgreSQL on Databricks, the intelligence is Claude through the Foundation Model APIs, and the hosting is Databricks Apps with managed compute and single sign on. Installation is a single script that provisions Lakebase, loads pricing data, and deploys the app in roughly fifteen minutes. A cost tool that takes a quarter to deploy will never be used. A cost tool that takes an afternoon becomes part of how designs get reviewed.

We built the 4 C's framework in Chapter 4 because enterprise AI keeps failing in four recognizable ways: the system does not know what the business means, nobody can constrain what it does, nobody can predict what it costs, and nobody can leave the vendor that runs it. Context, Control, Cost, and Choice. Of those four, Cost is the one teams treat as somebody else's department, and it is the one that quietly kills more agentic projects than any technical limitation.

The failure mode is specific. An agentic system does not fail its budget on the day it launches. It fails on the day it succeeds. A pilot that answers forty questions a day for one team costs almost nothing, so nobody instruments it. Then the pilot works, and it answers four thousand questions a day for eleven teams, and each of those answers pulls a retrieval pass, a reasoning pass, two or three tool calls, and a context window stuffed with far more material than the question required. The cost curve is not linear in usage, because context per call grows with ambition. That is the argument of Chapter 18 on the hidden cost of agentic AI, and it is why Chapter 36 treats the token budget as a design artifact rather than an accounting outcome.

So a tool that forces the assumptions into the open before the build is not a procurement convenience. It is the first half of the instrument the discipline has been missing. Lakemeter gives you a shared estimate. What it cannot give you, and what no external tool can, is the second half: a measurement of what your agent actually spends per answer once real people start asking real questions.

The walkthrough at the top of this essay is the fastest way to see how the estimate is assembled, because a cost model is much easier to trust once you have watched somebody build one in front of you. Pay less attention to the totals and more attention to the input fields. Every field is a decision that somebody on your team is currently making silently.

When you watch, keep a running list of the assumptions you would argue with. That list is more valuable than the estimate. It tells you exactly which parts of your own design are undocumented, and undocumented assumptions are where budget surprises come from.

The most useful thing an estimate does is not predict the future. It is to give two people something specific to disagree about. When the number lives in one engineer's head, a finance partner can only accept it or doubt it. When the number is a set of named assumptions with a visible calculation on top, the finance partner can point at the row that says four hundred concurrent users and say that the real figure is closer to sixty. Now the conversation is about a fact rather than about credibility, and the estimate improves in ten minutes rather than in three meetings.

This is why the Excel export matters more than it appears to. Budget decisions do not get made in application interfaces. They get made in spreadsheets that get attached to emails and pasted into slides. A cost tool that cannot leave its own front door will lose to whatever the finance team already uses. A cost tool that exports a full breakdown with stock keeping unit detail intact becomes the source that other spreadsheets cite.

It is also why we treat cost literacy as a career skill rather than a platform skill. Chapter 28 is about speaking the language of business and AI in the same sentence, and there is no faster way to earn a seat in an architecture decision than to be the engineer who can say what the design will cost and show the working. Chapter 27 makes the broader case: the skills that will outlast the tools are the ones that connect a technical choice to a business consequence.

Traditional platform cost accounting measures resources. Compute hours, storage, units consumed, queries run. Those are the right units for a warehouse. They are the wrong units for an agent, because an agent's output is not a query result. It is an answer that somebody either acts on or does not. Two agents can consume identical compute and deliver wildly different value, because one of them produces answers people trust and the other produces answers people quietly verify by hand.

So the unit we argue for in Chapter 20 is cost per trusted answer, and the tradeoff triangle in Chapter 21 is what makes it tractable: quality, speed, and cost move together, and you do not get to optimize all three. An answer that arrives in eight seconds for a fraction of a cent and gets checked manually every time is not cheap. It is expensive in a currency your platform bill does not track, which is human attention. A verified answer that costs ten times as much per call and eliminates the manual check is, in most enterprises, the cheaper design.

This reframing is what turns a cost estimate from a defensive exercise into a design tool. Once cost per trusted answer is the unit, cheaper stops meaning smaller and starts meaning better targeted. Which is exactly what Chapter 19 argues: not every task needs the best model, and the discipline is in knowing which tasks do.

If you want to bring an agentic workload into a sizing conversation, you need to know where the money actually goes, because it is rarely where teams assume. The first hiding place is the context window. Every token you send in is paid for on every call, and the easiest way to inflate a bill is to retrieve generously and let the window absorb whatever comes back. Chapter 35 on retrieval mechanics is largely a cost chapter in disguise: better chunking and reranking mean you send less material and get better answers, which is the rare case where quality and cost move in the same direction.

The second hiding place is the retry. A system that fails cleanly and retries is a system that pays twice, and if the retry includes a larger context window it pays considerably more than twice. Retries are usually a symptom of missing grounding rather than a symptom of a weak model, which is why we put so much weight on the context layer in Chapter 5 and on business meaning in Chapter 6.

The third hiding place is the handoff. Multi agent designs multiply cost at the seams, because each agent re establishes context that the previous agent already had. Every handoff is an opportunity to pay again for knowledge the system already possessed. Chapter 34 is about designing those seams deliberately, and Chapter 10 explains why durable institutional memory is the structural fix rather than a larger window.

Lakemeter is published under the Databricks Labs umbrella with the source in the open, third party notices declared, and a documentation site alongside it. That has an obvious practical benefit, which is that you can read the pricing logic instead of trusting it. It has a less obvious strategic benefit, which is that your cost model is now yours. You can fork it, extend it to workloads it does not yet cover, wire it into your own approval flow, and keep the assumptions when the platform changes underneath you.

That is the fourth C at work. Chapter 22 is about the danger of lock in, and one of the sharpest forms of lock in is having no independent way to model what an alternative would cost. If the only entity that can tell you what your workload costs is the entity billing you for it, you do not have a negotiating position. You have a subscription. Chapter 23 makes the broader argument for open formats and open interfaces, and an open cost model belongs on that list next to open table formats and open protocols.

There is a caveat worth stating plainly. Lakemeter is a Databricks Labs project, which means it is a serious, well built tool that is not a supported product. Treat it as an instrument that your team maintains, not as a vendor guarantee. That is a reasonable trade for transparency, and it is the same trade you make every time you choose an open component over a closed one. Chapter 25 calls this being platform independent while remaining platform aware.

Start with one workload you are already arguing about. Install Lakemeter with the provided script, build the estimate for that workload, and deliberately do not aim for accuracy on the first pass. Aim for completeness of assumptions. The goal of the first estimate is to surface every input your design depends on, including the ones your team has never written down. Export it, and take it to the person who owns the budget.

Then build the half that Lakemeter cannot give you. Instrument the workload so you can compute cost per answer in production: tokens in, tokens out, retrieval calls, tool calls, retries, and a quality signal that tells you whether the answer was accepted. Without that last field you are measuring spend rather than value. Chapter 32 gives you a readiness assessment that includes exactly these questions, and Chapter 31 walks through standing up the context layer that makes the measurement meaningful.

Finally, close the loop. Feed the measured numbers back into the estimate and see how wrong you were. Do that three times and something changes in how your team designs: cost stops being a review gate you survive at the end and becomes a constraint you design against from the beginning. That is the behavioral shift Chapter 20 is really about, and no tool produces it on your behalf. The tool only makes it possible.

It would be easy to read a sizing calculator as a small piece of news. A labs project, a nice interface, an Excel button. But look at what it implies about the direction of this platform era. The tools are moving from generating capability to accounting for capability. Evaluation tooling made answer quality visible. Governance tooling made agent action visible. Lakemeter makes cost visible before the money is spent. Each of those is the same movement: turning something that used to live in one person's judgment into something the whole organization can inspect.

That movement is the actual advantage. Not the model, which everyone rents from the same handful of providers. Not the interface, which is copied in a fortnight. The advantage is the accumulated set of things your organization can see clearly and therefore reason about together: what the business means, what agents are allowed to do, what each answer costs, and how easily you could leave. Four things. We wrote thirty six chapters about them because each one takes real work.

Lakemeter does not solve Cost. It does something more useful for a discipline this young: it removes the excuse. The number is now estimable before you build and measurable after. Which means from here on, a team that cannot say what its agentic system costs per trusted answer has made a choice rather than encountered a limitation.