Every autonomous decision SITEY makes has a price attached to it. Triaging a finding, writing a remediation plan, generating a patch script, answering a question in the security assistant. Each one is a model call that consumes tokens and bills to your provider account. AI Usage & Cost Analytics is the meter on that pipe. It records every AI call your installation makes and shows you what it cost, on which model, through which part of the product, day by day.
The problem
When a platform makes hundreds of AI calls a day on your behalf, your only default visibility is a single monthly number on a provider invoice. That number cannot answer the questions people actually ask. Which feature burned the tokens: the assistant, or the autonomous patch pipeline? Did the bill grow because you onboarded more assets, or because someone switched the default model to a more expensive one? Is a model silently failing and being retried?
Without a per-call ledger, teams fall back to exporting provider CSVs and guessing, or they do something worse: they throttle AI usage defensively because nobody can prove where the money goes. And for an autonomous product specifically, an unexplained cost spike is often the first visible symptom of an operational problem: a retry loop, a prompt that got much larger, a fallback chain firing on every request. If you are not watching the meter, you find out from finance a month later.
How it works
Every model call writes a usage row
A shared usage tracker sits behind the product’s AI entry points, from the assistant to the autonomous pipeline. When a call completes, it writes one row to an ai_usage_logs table in your own database: the account, the model, the endpoint it came from, prompt tokens, completion tokens, total tokens, a USD cost computed from those tokens, and, where the calling path supplies them, the measured duration in milliseconds and an error string. Token counts are taken from the provider’s own response payload rather than being guessed. The write is wrapped defensively, if logging fails, the transaction is rolled back and the AI call itself still succeeds.
Cost is computed from a central price table
Pricing is not scattered through the codebase. A single model registry holds the input and output price per 1,000 tokens for each model the platform offers, and the cost of a call is input tokens times input price plus output tokens times output price. For OpenAI models those are the published list prices.
For some models served through other providers the registry carries an approximate price, so read those rows as a working estimate rather than a quote. Models the registry does not recognise fall back to a deliberately conservative default price rather than an alarming worst case, so a newly released model never produces a nonsense estimate.
The dashboard aggregates the window you pick
The page queries a rolling window over your own account’s usage rows, 7 days, 30 days, 90 days or a full year, and returns four views over it: headline totals, a per-model breakdown, a per-endpoint breakdown, and a day-by-day trend. Each daily bar carries its own request count, token count and cost on hover, so a spike is traceable to a date before you go looking for a cause.
OpenAI billing is pulled in for reconciliation
Token math is an estimate. Real money is what the provider actually charged. Reconciliation against real invoicing is available for OpenAI. If an OpenAI organization admin key is configured, the page also calls the OpenAI Organization Costs and Usage APIs and shows the genuinely billed amount next to your local estimate, along with organization-wide token and request counts per model. Without that key, the page says so explicitly and shows the local estimate instead of pretending the number is an invoice. For models you run through other providers, the local estimate is what you get, there is no billing comparison for those today.
| Local ledger | OpenAI billing API | |
|---|---|---|
| Source | Every call, logged in your database | OpenAI Organization Costs / Usage API |
| Granularity | Per model, per endpoint, per day | Per model, per day, organization-wide |
| Nature | Estimate from tokens times the price table | Actually billed USD |
| Requires | Nothing | An OpenAI organization admin key |
| Covers | Every provider you use | OpenAI only |
Failures and latency ride along with cost
The same rows carry response time and error information, so the summary shows an average response time for the window and a count of calls that recorded an error. Both are indicators rather than complete audits: the average is taken over the calls whose code path measured a duration, and the error counter counts the calls whose code path passed an error string, so a rising number is a signal to investigate rather than a certified failure total. Cost, speed and reliability are still read on one screen instead of three.
What you can do
See total requests, total tokens with the input/output split, estimated USD and the average response time across the calls that record one, for a 7, 30, 90 or 365-day window.
Break spend down by model, with request count, token volume and cost per model, ranked and shown as proportional bars.
Break usage down by the endpoint identifier each call was logged under, so each of the following separates out as its own line. Autonomous work carries its workflow identifier in that endpoint, so those runs list as one row per run rather than a single grouped line, and the most common endpoints get a friendly label while the rest show their raw identifier.
Read a daily trend chart where every bar exposes that day’s requests, tokens and cost.
Reconcile your internal estimate against OpenAI’s actual billed total when an organization admin key is configured.
Use the error count and the average duration in the summary as a first signal that AI calls are failing or slowing down.
Keep all of it in your own database. The usage ledger is a table in your installation, and this module’s own outbound traffic is the model inference itself plus, optionally, the provider’s billing endpoint.
Who it is for
The CISO or security manager who signed off on an AI-driven platform and has to defend its running cost at the next budget review with evidence rather than an anecdote.
The platform or system administrator who chooses the default model and needs to know whether the expensive model is being spent on decisions that deserve it, or on routine calls that a cheaper one would handle.
The SOC lead who treats a sudden change in AI volume as an operational signal, a stuck workflow, a retry storm, a prompt that ballooned, and wants to catch it the same week it starts.
The finance or procurement partner at renewal time, who asks what the platform actually consumed and deserves a real number.
Why it matters
Model inference is the one genuinely variable cost of running an autonomous security platform.
Everything else, the installer, the agents, the database, is fixed once you deploy. Which means that if you cannot see AI consumption, you cannot forecast the cost of the product, and you cannot make the single decision that moves it most: which work goes to which model.
The per-model breakdown makes that decision concrete. When you can see that a specific model accounts for most of your token volume, you can move low-stakes work to a cheaper tier and reserve the expensive model for the calls that genuinely need the reasoning: and then verify on the next window that the change actually landed, instead of hoping.
There is a control argument too. Autonomous systems fail quietly. A workflow that retries the same generation forty times may not raise an alert anywhere else, but it is immediately obvious as a vertical spike on a daily token chart.
Cost telemetry doubles as health telemetry, which is why it sits in the product rather than in a spreadsheet next to it.
Works with
- AI Command Center, rolls the same usage ledger into a shorter-horizon operational view alongside vulnerability and workflow metrics.
- AI Operations Log: the per-action narrative behind the numbers: what the AI decided, and why.
- Autonomous Operations, the largest consumer of tokens in the platform, and the one whose cost profile is most worth watching.
- AI Remediation, remediation analysis and script generation report under their own endpoints in the breakdown.
Frequently asked questions
Does this module cap spending or shut the AI off at a budget limit?
No. This is a reporting module. It measures and reports consumption; it does not enforce budget ceilings and does not automatically stop AI calls when a threshold is crossed. Control over what the AI is allowed to do, which model is selected, which features are enabled, which actions require human approval, lives in model configuration and the approval gates, not here. We would rather state that plainly than let you discover it after a surprise invoice.
How exact are the cost figures?
The figures the platform computes itself are estimates: real token counts from the provider’s response, multiplied by the per-model prices held in the registry. Those prices are published list prices for OpenAI models and approximate values for some models served by other providers. They are close, not authoritative. The authoritative figure is the billed total pulled from OpenAI’s own billing API, which appears alongside the estimate when an organization admin key is configured; there is no equivalent reconciliation for other providers today. Where only a combined token total is recorded instead of an input/output split, the tracker approximates the split, which slightly affects that row’s estimate.
Does my AI usage data leave my infrastructure?
The usage ledger is a table in the database of your own installation, and the dashboard reads it directly. Nothing about your usage is sent to us. The outbound traffic involved in this module is the model inference itself, which goes to whichever provider you configured, and the optional billing lookup to OpenAI.
Whose usage does the dashboard show?
The dashboard is scoped to the signed-in account’s own usage rows. Background autonomous work is recorded against the administrator account that owns the run, so that account sees the platform’s automated consumption as well as its own. The OpenAI billing block, when a key is available, reports at organization level rather than per user.
SITEY is deployed inside your own infrastructure, which means the AI cost is yours to manage. And so is the data that explains it. AI Usage & Cost Analytics ships as part of the platform. See pricing for what is included in a licence.