And why Azure Cost Management can't tell you how much of your bill was Genie.
A few weeks ago Databricks turned on pay-as-you-go billing for Genie, and with it something worth paying attention to: every named user now gets 150 DBUs of Genie, free, every month.
I've watched two reactions to that. The first is the fun one — people wiring Genie into their workspace and seeing what it can do. The second is the reflex I want to talk you out of: an admin, cost-conscious and well-meaning, quietly setting the Genie budget to zero — or never enabling it — so nobody can run up a bill. It feels responsible. It's actually the expensive choice, because the thing you just switched off was free, and it was the cheapest experiment your team had access to all month.
This post is about that trade. Not "watch out, Genie costs money" — but "here's what the free allowance is actually worth, here's exactly how to see what you're spending, and here's why locking it to zero costs you more than it saves." Every number here comes off my own workspace — a small golf-league lakehouse I've been building as a personal project — because the receipts are real and they're mine.
First, what a DBU actually is
"150 free DBUs" only really lands once you know what a DBU is — and it's worth a moment, because a DBU is a unit of consumption, not a dollar amount.
A DBU — Databricks Unit — is a unit of consumption, not a unit of currency. It measures how much processing a workload used, the way a kilowatt-hour measures electricity. The dollar value of one DBU isn't fixed. It depends on:
- Which product/SKU you're consuming — Genie inference, a serverless SQL warehouse, and all-purpose compute each price differently.
- Your pricing tier — Standard, Premium, and Enterprise carry different per-DBU rates.
- Your cloud and region — the same SKU costs different amounts across Azure, AWS, and GCP, and across regions within each.
- Your contract — commit discounts and negotiated rates mean two customers can pay very different dollars for the identical DBU.
So there is no single "a DBU is X dollars" answer, and any blog that hands you one (including this one, if I'm not careful) is quietly assuming a tier, a cloud, and a region you may not share. What matters is the skill: **look up the rate that applies to you.** It lives in a system table you can query directly:
SELECT sku_name, pricing.default AS usd_per_dbu
FROM system.billing.list_prices
WHERE sku_name LIKE '%SERVERLESS_REAL_TIME_INFERENCE%' -- the Genie inference SKU family
AND price_end_time IS NULL; -- the current, still-active priceThat returns your SKUs at your list rate — the right starting point, before you even layer in whatever discount your contract carries.
The takeaway isn't a dollar figure. It's the shape of the thing: 150 DBUs a month, per user, is a small, capped amount of Genie — on purpose. Enough for an analyst to ask a few hundred real questions of a governed dataset before anyone has to think about spend. The point of the free tier was never the exact dollar value. It's making it easy for someone to just try.
🛠️ One quirk for the query-minded: the free allowance has its own SKU, GENIE_FREE_USAGE, and it has no row in list_prices — because it's free. So if you ever want to answer "what would my free usage have cost at list price?", you value those DBUs at whatever the equivalent paid SKU costs in your account — join list_prices for your own SKU and tier rather than borrowing anyone else's rate.
What you can actually see (so you can enable it with confidence)
The reason admins reach for a zero budget is rarely stinginess. Usually there's someone in finance or leadership — with an entirely appropriate concern about runaway AI spend — who has asked them to keep a lid on it, and a zero cap is the bluntest way to answer that. The problem is that it's blunt: it can't tell the difference between a genuine risk and a $2 experiment, because the person setting it can't yet see what Genie actually costs. So let's give them something better to point at. The visibility is right there — everything you need is in system.billing.usage, and you need SELECT on two system tables, nothing more.
Here's the one query I keep pinned. It splits Genie usage by user, by surface (where the usage came from), and by tier (free allowance vs. paid), so the whole picture sits in one table — in DBUs, the unit that's the same for everyone:
WITH genie AS (
SELECT
COALESCE(u.identity_metadata.created_by, u.identity_metadata.run_as, 'unknown') AS user,
u.usage_metadata.genie.surface AS surface, -- GENIE_CODE (UI) vs GENIE_AGENTS (API)
CASE WHEN u.sku_name = 'GENIE_FREE_USAGE' THEN 'FREE' ELSE 'PAID' END AS tier,
u.usage_quantity AS dbus -- sum ALL record types — see the note below
FROM system.billing.usage u
WHERE u.billing_origin_product = 'GENIE'
AND u.usage_date BETWEEN DATE'2026-07-01' AND DATE'2026-07-24' -- your window
)
SELECT user, surface, tier,
ROUND(SUM(dbus), 3) AS net_dbus
-- To add dollars, join system.billing.list_prices for YOUR SKU/tier/region
-- (and remember your contract discount) rather than hard-coding a rate.
FROM genie
GROUP BY user, surface, tier
ORDER BY net_dbus DESC;On my golf workspace, July 1–24:
| user | surface | tier | net DBUs |
|---|---|---|---|
| jeff.baart | GENIE_AGENTS | FREE | 27.83 |
| jeff.baart | GENIE_CODE | PAID | 17.00 |
| jeff.baart | GENIE_CODE | FREE | 15.37 |
| (service principal) | GENIE_AGENTS | FREE | 3.63 |
That's three-and-a-bit weeks of me leaning on Genie two different ways. My free allowance did its job — about 40 of my 150 free DBUs used (24 on the agent, 15 on code) — and then, once the code surface ran through its free share, another 17 DBUs quietly landed on the paid tier. That's the system working exactly as intended: free until you've had a real taste, then a gentle, itemized handoff to paid — not a wall, not a surprise. And notice where the paid usage is: all of it on GENIE_CODE, none on the agent. Whatever those DBUs convert to in dollars for your tier and cloud, the point is that you can see the handoff happen, line by line, and decide what to do about it — rather than never letting anyone near it in the first place.
Two surfaces, one allowance — good to know when you read your usage
One thing the table above quietly teaches: Genie usage shows up under more than one surface, and on my workspace there are two.
GENIE_CODE(channelUI) — Genie code, the assistant inside the Databricks UI.GENIE_AGENTS(channelAPI) — a Genie Agent I stood up behind a served endpoint and call over the API.
They're different entry points that draw from the same 150-DBU allowance — which is handy to know when you're reading your usage, because it explains why one person can show up on two lines. The surface field is what tells them apart.
The dashboard the docs give you
If you'd rather not live in the SQL editor, Databricks publishes a proper usage dashboard for exactly this. The Databricks docs walk you through importing it (pick your cloud from the docs switcher): choose a workspace and you get a full breakdown by product, SKU, and custom tags — with cost forecasting and object-level drill-down built in.
I imported it into my golf workspace to see it against real data. The Usage Overview page gives you the same story the queries above tell, minus the typing.
The nice part is what's underneath it. That dashboard is just visuals sitting on top of the same two system tables — system.billing.usage and system.billing.list_prices — you already queried by hand. The dashboard is the convenient front door; the tables are the source of truth, and they're open to anyone with SELECT.
Coming from Azure? Start where you already look
If your first stop for "what is this costing" is the Azure portal, good — start there. Azure Cost Management already shows your Databricks spend the same way it shows everything else: by resource group, by meter, by tag, over time. For "what did this workspace cost over some period," it's the fastest answer and the view your finance team already trusts.
I pulled up my golf resource group next to the Databricks account dashboard for the same window, July 1–24. The first thing to notice is that they agree: Azure showed $204, the Databricks usage total showed $227. Within a couple percent — the lakehouse's own books match the cloud invoice. Good.
Then try to answer one question in each: how much of this was Genie? And here's where the two views part company — not because one is wrong, but because they cut the pie along different lines.
Azure groups by meter. Its bars are named Premium Interactive, Premium Serverless SQL, Premium Serverless Real-time Inference, Premium Anthropic Serving. Those are compute types, not products. There is no "Genie" bar in Azure — because Genie isn't a meter. When Genie calls its model, that usage lands on the shared Serverless Real-time Inference meter, right alongside everything else that does inference.
How shared? Over July 1–24, that single meter on my workspace carried four different products:
| What's on the "Serverless Real-time Inference" meter | DBUs |
|---|---|
| Model Serving | 161.5 |
| Genie | 17.0 |
| Agent Evaluation | 0.04 |
| AI Gateway | 0.01 |
Genie is under 10% of that one meter — a modest slice of a bar that's mostly model serving. In the Azure view it isn't hidden, exactly; it's mixed in with the other three so you can't pull it back out. You can see the meter. You cannot see the Genie inside it.
The Databricks system table can, because it stamps every row with billing_origin_product. That's the column Azure's meter rollup doesn't have — the one that splits a shared compute meter back into the products that rode it. Group by it and Genie steps out of the crowd:
So the two tools are two zoom levels of the same picture. Azure Cost Management is the wide shot your org already checks against the invoice — perfect for "what did the resource group cost." The system tables are the close-up that can answer "how much of that meter was Genie, which user, which surface, free versus paid" — because they keep the raw per-record log that the meter rolls up and throws away.
That's the bridge for anyone arriving from Azure: keep the portal for the questions it's built for, and reach for the system tables the moment the question is about a product riding inside a meter rather than the meter itself.
Or just ask Genie
Here's the part I like best, because it closes the loop. You don't strictly need the SQL editor or the dashboard. If you have access to the billing tables, you can open the Genie assistant right in the Databricks UI and just describe what you want. You don't have to write the SQL — but it helps to point Genie at the right columns, the way you'd brief a sharp analyst:
Using system.billing.usage, summarize my Genie usage this month.
Break it down by usage_metadata.genie.surface (GENIE_CODE vs GENIE_AGENTS)
and by tier where sku_name = 'GENIE_FREE_USAGE' is FREE else PAID.
Sum usage_quantity across all record_types (include retractions).
Filter billing_origin_product = 'GENIE' and usage_date >= date_trunc('MONTH', current_date()).I tried exactly that. Genie wrote the aggregation, ran it, and handed back the same free-vs-paid, surface-by-surface breakdown I'd built by hand — and it even volunteered the reason it went to the raw table: "this required a custom aggregation not present on the dashboard, so I ran it directly against the usage table." The tool you're being asked to budget for is perfectly happy to tell you what it costs.
Genie can only read what you can read. Those billing tables (system.billing.usage, system.billing.list_prices) are locked down by default — on my workspace only account admins hold SELECT. So "just ask Genie" works cleanly for an admin or a FinOps owner who already has billing access. If you want your analysts to self-serve their own Genie spend, an admin has to grant SELECT on those two tables to the right group first. That's a deliberate grant, not a default — which is exactly the kind of governed, visible decision this whole post is arguing for.
One thing to get right in your query
If you do start watching this — good — here's one detail to get right up front, because I learned it the hard way.
Like other products, Genie usage in system.billing.usage can restate itself: an original charge may be followed by a retraction, a negative-quantity row that corrects it. That's the billing system keeping itself accurate. Over July 1–24 my split was:
ORIGINAL: +78.11 DBUs (139 rows)RETRACTION: −17.92 DBUs (38 rows)RESTATEMENT: 0 (2 rows)
The correct net is ~60 DBUs. If you filtered to record_type = 'ORIGINAL' — which looks like the tidy thing to do — you'd report 78 DBUs, about 30% high, because you dropped the corrections. So the tip is simple: sum across all record types. The negatives are meant to be there, and the pinned query above already handles it — so your numbers match reality on the first try.
🛠️ One more field: identity_metadata.created_by gives you the person's email for interactive usage, but agent and API calls run as a service principal, so those rows carry a UUID in run_as instead. That's why a couple of my rows show a UUID, not an address — it's the agent acting on its own identity. (I ran headfirst into that run_as service principal while building the golf agent — the whole permission saga is in Real agents, real edge cases.)
The bigger picture: budgets as guardrails, not walls
Here's the takeaway. Cost governance on Databricks is real and it matters — but the best tool for it is a guardrail, not a wall. A sensible budget with an alert says "tell me if a user blows past their free allowance and starts spending real money." A zero budget says "nobody gets to try." The first one is governance that still lets people work. The second one trades away a lot of upside for a little peace of mind.
And once you can see per-surface, per-user cost like this, you can start reasoning about the more interesting decision: when to lean on the hosted path — Genie code, Genie One, a served agent — versus building something custom for a product or customer-facing outcome. That's a decision worth making with data in front of you, and I'll dig into it properly in an upcoming post. But you can't make it at all if you switched the whole thing off to be safe.
Where we land
- Know what a DBU is. It's a unit of consumption, not currency — its dollar value shifts with your SKU, tier, cloud, region, and contract. Look up your rate in
system.billing.list_prices. The point of the free 150 is that it's enough to be curious with, not its exact dollar value. - See it.
SELECTon two system tables shows you exactly who's using Genie, on which surface, free vs. paid. Visibility is what makes it easy to say yes. - Sum all record types. Retractions are negative on purpose; filtering them out overstates your usage by roughly a quarter.
- Guardrails, not walls. Set a budget with an alert, not a zero cap. You have no idea what problem a curious analyst solves with their free 150 DBUs — don't take the guess away from them.
None of this needs a dashboard you don't have or a permission you can't get. Just the willingness to read your own bill — and the confidence, once you have, to leave the door open.
That service-principal UUID in the table above hints at a bigger question than a billing row can answer: when an agent acts on its own identity, whose permissions is it really using? I'll pull on that thread in a future post.