A mixed CX pipeline charges several ledgers at once: per-message SMS, per-minute voice, and per-token model inference. The token ledger is the only one that can double overnight without a single pricing change, because the cost driver is not a tariff. It is how long the agent talks and which model it routes to. That asymmetry is why AI spend needs its own control surfaces rather than a line on a generic usage page. Devotel Orbit ships three of them, and this post covers what each one answers, how they fit together, and how to put an alert on the few numbers that actually move the bill.
The FinOps-of-AI problem
On a mixed CX pipeline, model costs often outrun SMS and voice usage combined. SMS moves at fractions of a cent per segment and voice at per-minute rates. An AI voice agent, by contrast, burns input and output tokens continuously: on the retrieval-augmented system prompt, on the conversation history it replays, and on every downstream model call it makes. Add automatic speech recognition on the voice leg and re-summarization of long histories, and the AI side of an agent's cost envelope can exceed the telecom side by an order of magnitude once the conversation volume picks up.
That is not a pricing complaint. Tokens are billed per-call and the model sets the price. The problem is that without a governor, LLM cost is the only line that scales with conversation depth, not just with traffic, and it does so invisibly until the invoice lands. The fix is to treat AI spend the way cloud-cost teams treat compute: instrument the usage, bound it with a budget, and attribute it against the outcomes each agent actually resolves.
Three surfaces, one control loop
Orbit ships three insights surfaces that together close the loop on AI spend.
`/insights/cost-governor` — the policy surface. Set a per-tenant budget cap on LLM tokens (and on the ASR speech-to-text leg of voice-agent calls). When spend nears the cap, the governor downshifts model routing automatically instead of letting traffic run against an unbounded meter. It also reports cost-per-resolution margin analytics per agent, so the budget decision is made against what each agent costs to resolve a conversation.
`/insights/llm-spend` — the telemetry surface. Tokens and cents per agent, per model, and per conversation, in both an org-wide overview and a daily-bucketed timeseries. It tracks daily-cap progress and projects month-to-date spend, so the mid-month answer to "will we blow the budget" is read off a graph rather than computed in a spreadsheet. Per-model and per-agent breakdowns make rebalance decisions concrete: moving a route to a cheaper model tier with the same resolution rate shows up directly as lower spend.
`/insights/agent-roi` — the value surface. Each agent's AI cost against the attributed revenue of the outcomes it resolved, with a configurable value-per-outcome assumption, a daily trend, and a margin figure per agent. This is the surface that tells you whether the budget should be tightened or expanded: an agent with negative margin needs a cheaper model or a narrower prompt, and one with strong positive margin can absorb a more expensive tier.
The Insights dashboards guide in the docs covers each endpoint and console route in full.
Guardrails, telemetry, and value: what each metric means
The three surfaces answer three different questions, and conflating them is the most common AI-FinOps mistake.
The cost governor is not a dashboard. It is the enforcing counterpart, and it is where policy lives: the budget cap, the automatic downshift, the resolution-margin guardrail. It does not tell you what you spent; it decides what you are allowed to spend and what happens near the limit.
LLM spend is pure telemetry: usage counted, nothing enforced. Because it breaks spend down per model and per conversation, it is also where you diagnose the governor's behaviour: which model the traffic downshifted to, which agent's long conversations are dominating the meter, whether the daily cap is being consumed at a healthy pace.
Agent ROI attributes value. The governor governs the cost side; ROI prices the outcome side. An agent that resolves routine tickets at high volume may look expensive on llm-spend and still be the best-performing line on agent-roi once the value-per-outcome is set. The three surfaces disagree deliberately, and the disagreement is the point.
A worked example: a voice agent with quiet hours and no governor
Consider an AI voice agent handling a mixed outbound and inbound CX flow, with SMS follow-ups scheduled using send-time optimization inside a quiet-hours window (see the quiet-hours and DST post for the recipient-local timing model). The agent's model cost comes from three places: the input tokens on every call, the conversation history replayed on each turn, and the ASR speech-to-text leg on the voice channel.
Say the agent routes a premium model for every call. During a campaign push the call volume triples, and the conversations also get longer, so each turn replays more history and the input-token count per turn climbs. The SMS and voice portions of the bill scale with traffic and stay predictable. The token portion scales with traffic times conversation depth, and without a cap it consumes the month-end projection on llm-spend earlier each day. Nothing on the invoice warns about this; the meter just keeps running against the model that was chosen once and never revisited.
With the governor set, for example a daily LLM-token cap with automatic downshift to a cheaper model tier once spend crosses the threshold, the same campaign push degrades gracefully. Traffic continues, callers still get an agent, and the model downshift is a routing decision the governor makes on its own. The quiet-hours and STO model on the SMS side is unaffected; this class of problem is not about the message schedule. It is about bounding the one cost component that scales superlinearly with usage.
Set an alert rule on the numbers that move the bill
The governor is the enforcement layer; the alert layer tells you before enforcement is needed. Orbit's usage alert rules surface, announced in the August 2026 release notes, lets an operator define threshold and anomaly rules on the usage signals that move the bill. For AI spend specifically, the useful rules are a daily LLM-token threshold, a month-to-date spend projection that crosses a ceiling, or a sudden change in conversation-length per agent (longer histories mean more input tokens per turn). The rule notifies in-app the moment the threshold breaches, so the operator sees the drift before the governor starts downshifting, or before the budget is silently consumed.
The usage-anomaly alert rules guide in the docs walks through creating a rule, and the Insights API reference exposes the same thresholds programmatically for teams that route alerts into their own incident channel.
Frequently asked questions
What is the difference between the cost governor and the LLM spend dashboard?
The LLM spend dashboard is telemetry. It counts tokens and cents per agent, per model, and per conversation. The cost governor is enforcement. It holds the per-tenant budget cap and automatically downshifts model routing when spend nears the cap. One measures; the other bounds.
Does the cost governor block traffic when the budget is exhausted?
No. When spend nears the cap, the governor downshifts model routing to a cheaper tier rather than dropping the traffic. Callers still reach an agent; the model choice degrades gracefully instead of hard-failing. The operator can review the downshift behaviour on the LLM spend dashboard and tune the cap.
Which models does the LLM spend dashboard break down?
Tokens and cents are reported per agent, per model, and per conversation, in both an org-wide overview and a daily-bucketed timeseries. The per-model breakdown is what makes rebalancing concrete: moving a route to a cheaper tier while keeping the same resolution rate shows directly as lower spend.
How is Agent ROI different from LLM spend?
LLM spend counts cost. Agent ROI attributes value, setting each agent's AI cost against the revenue of the outcomes it resolved under a configurable value-per-outcome assumption. An agent can be expensive on the spend surface and still show positive margin on the ROI surface if its outcomes are valuable.
Do quiet hours and send-time optimization interact with the governor?
Quiet hours and STO govern when messages are delivered; the cost governor governs which model an agent runs. They are independent controls that happen to share the same dashboard family. The worked example above uses STO for the SMS schedule and a token cap for the AI budget, and each operates on its own axis.
Where do I set up a spend alert?
Open /insights/usage-alert-rules in the dashboard and create a threshold rule on the usage signal that matters (daily LLM tokens, month-to-date projection, or per-agent conversation length). The August 2026 release notes and the usage-alert-rules guide in the docs cover the rule types.