Before the live agent I built for an energy company ever made a real call to a large language model, the whole build had already been tested end to end — at a cost of exactly zero credits. Every test ran against a mock: a stand-in component that returns predictable answers instead of calling the real, metered service. Only when the behaviour was proven did I enable the real path, and by then I had written down an estimate of what one run should consume and how often runs would happen.
That order of operations — understand the cost, then turn on the meter — is what this post is about. Because with Data Cloud and Salesforce’s AI features, you are not buying a license and using it as much as you like. You are running a meter.
A cloud bill, not a site license
Most of the Salesforce world we grew up in is licensed per user: you pay for a seat, and the person in that seat can click all day at no extra charge. Data Cloud and the AI features around it work differently. They are consumption-based: usage is metered in credits, a shared currency that different operations draw down at different rates. Bringing data in, querying it, invoking AI features — each of these consumes, and each consumes at its own rate.
You will notice I am not quoting a single rate, and that is deliberate. Exact rates and bundles depend on your contract, and they change over time. The only reliable numbers live in two places: your own org’s consumption dashboards, and your own contract. Any number I printed here would be stale by the time you read it, so I will not print one. Verify in your org — that phrase will come back more than once today.
What does not go stale is the mindset:
Treat credits like a cloud bill, not a site license. The question is never “do we have this feature?” It is “what does one run cost, and how often does it run?”
If you have worked with any pay-as-you-go cloud provider, this is familiar territory. If your whole Salesforce life has been per-seat licensing, it is a genuine shift — and it is worth sitting with before you build anything.
The multiplication nobody does
Here is where budgets actually go wrong, and it is rarely where people expect.
A single AI call is usually not the problem. Someone demos a feature, it consumes a little, everyone nods. The trouble starts when that call gets wired into something that repeats: a loop inside an agent conversation, a trigger — automation that fires every time a record changes — or a scheduled job that runs every hour whether anyone is watching or not.
The expensive mistake is not one big call. It is a small call on a schedule nobody remembers. Cost per run multiplied by frequency is simple arithmetic, but the frequency side is where the surprises hide. A call that feels cheap once becomes a very different proposition at “every update on a busy object” or “hourly, forever.”
So before you wire any metered feature into a loop, a trigger, or a schedule, ask two questions out loud: what does this consume per run, and how often will it run? If you cannot answer both, you are not ready to enable it. This is not caution for its own sake — it is the same discipline you already apply to governor limits (the platform’s hard caps on things like queries and CPU time per transaction), just with money attached.
Mock first, meter late
In my own builds — the practice I documented while building that energy-company agent — the language model sits behind a single gateway seam: one class that every model call in the system must pass through. Behind that seam sit two implementations. One is the real, metered call. The other is a mock that returns deterministic answers — the same input always produces the same output, and nothing is consumed.
That one seam buys three things.
First, the entire test suite runs at zero credits. I can run it as often as I like, in any sandbox, and the meter never moves. Development speed and cost control stop being enemies.
Second, deterministic fallbacks come almost for free. When the model is unavailable — or the budget says no — the system can degrade to a rule-based answer instead of failing. A fallback you tested is a feature; a fallback you improvised at midnight is an incident.
Third, and this is the habit I most want to hand you: the metered path is enabled late, and before the first real call I stamp an estimate — this feature, this expected consumption per run, this expected frequency. The estimate will be imperfect. That is fine. An imperfect estimate you wrote down beats a perfect number you never looked for, because now your first week of real dashboard data has something to be compared against.
Check the zero-credit shelf first
There is a question that comes before all of the above: do you need the metered path at all?
A surprising amount of useful work consumes nothing. Static and configuration analysis — ordinary code that reads your org’s setup as data and checks it against rules — costs no credits. SOQL, the Salesforce Object Query Language you already use to query records, runs over data you already have. Deterministic scoring — plain arithmetic over fields, no model involved — costs nothing either.
Earlier this month I wrote about a configuration-linting check that found real issues in real config, and it consumed zero credits, because it is just code reading metadata. Not every problem needs a model. My rule of thumb: reach for the zero-credit shelf first, and let the metered call earn its place by doing something the deterministic version genuinely cannot.
Four habits for the pilot phase
If you are piloting Data Cloud or an AI feature right now, here is the routine I would set up in week one.
- Find your consumption dashboard and look at it weekly. Not monthly — weekly, at least during the pilot. If you are not sure where your org reports consumption, ask your admin or your account team; where it lives can vary, so verify in your org.
- Measure one feature in a sandbox. Note consumption before enabling it, exercise it deliberately, and look again. One clean before-and-after teaches you more than any documentation page.
- Batch or cache grounding queries where freshness allows. Grounding means fetching your data to give the model as context. If the underlying data changes daily, fetching it fresh on every single run is consumption with no benefit — cache it, and refresh on a schedule that matches reality.
- Give every automation its own budget line, and alert on it. You already treat governor limits as something to monitor and alarm on. Treat credit consumption exactly the same way: an internal budget per automation, and a notification when it is exceeded.
Your next step
Let me close by saying plainly what this post is not. Cost governance is not stinginess, and it is not a reason to avoid the metered features — some of them are worth every credit.
A feature you can price per run is a feature you can keep.
When someone eventually asks whether the AI feature is worth it — and someone always asks — you want to answer with numbers from your own dashboard, not a shrug. That is what cost governance actually buys: it makes the valuable calls defensible, and defensible features survive budget season.
Your next step is small: this week, find the consumption dashboard in your org and simply read it. No changes, no decisions — just learn what your org is consuming today and which operations are doing the consuming. Once that number is familiar, every build decision that follows gets easier, because you will be asking the right question from the start: not “can we turn this on?” but “what does one run cost, and how often does it run?”