Overview
Every time the platform uses an AI model β the Robot replying to a customer, a dashboard being generated, the onboarding briefing, the quality judge, the copilot, a voice call β that can create a cost in US dollars. When both measurement and price are confirmed, the Brain's Usage tab gathers those records and answers the question that comes up every time the invoice arrives: what did THIS account spend, and on what.
Each priced amount is a recorded measurement, not an estimate. But finalizing an event only confirms that it was persisted; it does not by itself prove that usage measurement or pricing is complete. A missing line, invalid measurement, or not-yet-confirmed price never becomes zero or βno spendβ; the screen treats it as incomplete or unknown information.
Prerequisites
- The Brain module must be enabled on the account.
- You must be an administrator. This is the only Brain read restricted to administrators, for a simple reason: invoice information is not support information. An agent reading the inbox does not need to read the bill.
- The AI service must be reachable. If it is not, the screen shows an error. An incomplete or unknown response is also identified as such β never as zero.
Step by step
- Open Brain in the sidebar.
- Go to the Usage tab.
- Pick the period in the top right: 7, 30 or 90 days. The window IS the question: changing the period reloads the numbers.
- Read top to bottom:
- the four cards summarise the whole period β cost, calls, tokens and cached tokens β and each one carries underneath the average that is usually the next question: cost per day, calls per day, tokens per call and how much of the prompt came from cache (that is the provider's discount: when the percentage drops, the bill rises without the volume moving);
- the chart shows spend day by day, with the scale on the left, dates along the bottom, the peak day highlighted and, in the footer, how many days of the period actually had spend β a nearly flat line reading "3 of 90 days with spend" is information, not an empty chart;
- the lists below break the same total down by surface, by model and by Robot, each row with its share of the total, its call count and its cost per call;
- the Per conversation section lists the most expensive conversations of the period, each with a link that opens the conversation, its cost, how many turns it had and its cost per turn.
- Use the filter bar at the top to cross the questions: surface, model, Robot and conversation. The filters combine, and they redo the read β they do not hide rows on screen, they change the query. Filtering by one Robot and watching the total drop is the confirmation that this Robot accounts for that share.
Amounts below one cent are shown with the decimals they need (for example US$ 0.004933). A model
call costs fractions of a cent: rounding to two decimals would print US$ 0.00, which reads as
"nothing was measured".
Per conversation
Until now this screen answered "what did the account spend". Per conversation answers "what did THIS conversation cost" β the question that comes up when one conversation drags on, or when someone wants to know whether a particular case turned out expensive.
A conversation's cost includes what it spent outside the reply turn: transcribing the audio the customer sent, the audio the Robot replied with, the voice call. Those used to land in a row that could not be linked back to the conversation that caused them.
Sub-agents and delegation. When a Robot delegates to a sub-agent, the sub-agent's tokens are already counted on the caller's turn. The screen shows the delegation so you know it happened, but its cost is not added again β adding it would count the same tokens twice and inflate exactly the number this screen exists to make trustworthy.
For new measurements, if a delegated model request has no confirmed completion or part of its price is unknown, the breakdown shows a Measured subtotal containing only the known floor. Complete cost remains unconfirmed; if no priced portion is known, no amount is shown. This also applies to the breakdown by conversation, without adding delegation to the total again. Records from before this version retain the measurement from their time, with their previous display; ConversaLabs does not recalculate history. A scan-limit notice means only that the breakdown could not read every record, a different situation from incomplete measurement.
Unpriced surfaces
Not everything that consumes AI arrives with both a valid measurement and a confirmed price table.
Audio transcription is billed per second, speech synthesis per character, image and video per unit. If
audio transcription (ASR) has no valid, durable measurement, the ASR field stays without a value
(unknown) instead of showing zero. If the unit was measured but its price is not yet confirmed, the
surface appears counted and labelled as unpriced: cost_priced=false means βmeasured, but
unpricedβ, never US$ 0.00. It remains in its own unit ("3,412 characters synthesized"), and
never as US$ 0.00.
The distinction is the whole point: US$ 0.00 reads as "this was free". An unpriced surface reads as
"this consumed something, and the platform does not yet know what it cost". In those cases, the priced
subtotal is explicitly partial β or unavailable when there is no line with a confirmed price β and
must not be mistaken for the whole invoice. Technically, cost_usd represents complete cost only; when
measurement is incomplete, it is null. measured_subtotal_usd is an optional subtotal that shows
only the floor that was actually measured and priced. total_is_floor=true, measurement_complete,
incomplete_observed, and unpriced_reason explain why that subtotal is not a final cost.
Settings & options
There is nothing to configure here: the tab is read-only. What moves the numbers is usage β how many conversations the Robot handles, how many dashboards get generated, whether the quality judge is sampling turns, and which model each Robot uses.
To change a Robot's model (and therefore its cost per call), use the Robots screen. To change who grades quality, use the Brain's surface assignment.
Use cases
- Closing the month. You get the provider's invoice and want to know how much of it is this account.
- Finding where the money goes. Almost always the answer is "customer replies" β it is the surface that runs most often. When it is not, that is worth a look: a dashboard generated over and over, or a judge pointed at an expensive model, shows up immediately in the by-surface list.
- Comparing Robots. The per-Robot breakdown shows which one consumes most, which usually reflects conversation volume rather than waste β but sometimes reflects an expensive model chosen without need.
- Seeing the cache work. Cached tokens are billed at a discount. A high number there means the system prompt is stable and being reused; a sharp drop usually means something in the prompt changed.
- Investigating an expensive conversation. The Per conversation section sorts by cost. Opening the most expensive one and checking its turn count separates two different causes: a long conversation (many cheap turns) and a heavy one (few expensive turns, usually a large model or a lot of context).
- Finding the cost of voice. Filter by the audio surfaces to see how much transcription and synthesis the account consumed β in seconds and characters, since no dollar price exists for them.
Tips, limits & best practices
- Values are in US dollars. That is the currency the provider bills in and the measurement was taken in. Converting here would invent an exchange rate the platform never observed.
- The by-model breakdown is partial, and the screen says so. Customer replies are measured without recording which model replied, so their cost lands in the total, in the by-surface list and in the daily chart, but not in the by-model list. When that happens, a line states how much of the total the list covers. Adding up only the by-model list and taking it for the whole bill is exactly the mistake that line exists to prevent.
- βNo spendβ requires positive proof.
no_usageappears only when the lifecycle confirms zero operations. A missing line, expired line, invalid measurement, TTL, error, or pending price appears as incomplete or unknown information β never as βno spendβ orUS$ 0.00. - Finalized does not mean fully measured or priced. Finalization confirms persistence;
measurement_completereports measurement coverage independently. Afinalevent can retaincost_usd=nulland still show only a partialmeasured_subtotal_usd, without beingno_usage. - One measured response does not confirm every request in the turn. If another model request has no confirmed completion yet, ConversaLabs keeps the turn's usage incomplete. Tokens and cost already measured remain in the subtotal. In a call, Measured subtotal and At least show the known floor; the complete cost remains unconfirmed. This state can also appear when the rest of the call or conversation finished normally.
- ASR without a measurement stays blank/unknown; a partial subtotal stays partial. If a line has a measured unit but no confirmed price, it is not added as free and the reason for the missing price remains visible.
- A liveness read does not certify usage.
liveness_known=trueonly says that the Redis read occurred. A known missing marker remainsunknownuntil durable proof exists;no_usagerequires positive proof of zero operations, never an empty list, TTL, or an error. - AI stays separate from WhatsApp costs. AI amounts are always shown in US dollars and are never added to the WABA/Meta billing currency.
- The maximum window is 365 days. Longer periods are clamped, not refused.
- A day with no spend shows as a day with no spend β not as a gap in the line.
Troubleshooting
The tab does not appear. The Brain module is disabled on the account, or you are not an administrator.
An error shows instead of the numbers. The AI service did not answer. Nothing is rendered as zero on purpose: a made-up figure here would be worse than none. Use Try again; if it persists, it is one for whoever runs the installation.
The screen reports incomplete or unknown data. That does not prove that there was no usage. A
durable line, a valid measurement, or a confirmed price may be missing. Even if the event is finalized,
finalization confirms persistence only; measurement_complete remains independent. In that case,
cost_usd is null and only measured_subtotal_usd, when present, shows the known floor.
The cost does not match the provider's invoice. Two common causes: the invoice covers the whole
installation (every account) while this screen covers one account; and complete cost can be unavailable
because a measurement or price is not yet confirmed. In that case, measured_subtotal_usd is only the
known floor, not a total. The price table used at measurement time may also be out of date with the
provider. Talk to whoever runs the installation.
The by-model list adds up to less than the total. Expected, and the screen warns about it β see "Tips, limits & best practices" above.
A surface shows calls but no dollar amount. That is deliberate when the unit was measured but no
price is confirmed. The measurement stays in its own unit (seconds, characters, units);
measured_subtotal_usd includes only the priced floor and cost_usd does not pretend to be complete.
If ASR measurement is missing or invalid, the ASR field is unknown, not zero. That is not the same as
zero cost, and the label exists precisely so you do not confuse the two.
The by-surface and by-conversation totals do not match exactly. A conversation only appears under "Per conversation" if its spend could be linked to it. Account work that belongs to no conversation β a generated dashboard, the onboarding briefing, the daily improvement cycle β counts toward the total and the surfaces, and correctly counts toward no conversation.