What an investigation costs

Sentinel-Q investigations cost us money to run. Each one sends alert text, process command lines, sign-in records and rule descriptions to a language model, several times over, and the platform records exactly what each decision cost down to a millionth of a dollar. This article explains what that means for you, which is mostly: less than you would expect.

The commercial position first, because everything else follows from it. Investigations are not billable. You are not charged per alert, per investigation or per token. There is no meter you can accidentally run up by connecting a noisy log source, and no invoice that grows because a detection rule misfired. A false positive we generated must never cost you money — a vendor whose revenue rises with their own false-positive rate has an incentive we do not want to have.

What the daily cap is actually for

There is a cap, and it is not a billing device. It is a blast-radius control on our own spending, and it exists because the failure mode it prevents is real: one misconfigured log source, one rule firing every four seconds, and a single organisation can consume a month of model budget in an afternoon. Rather than let that happen quietly and then have a conversation about it, the platform meters every model call and enforces a ceiling.

The current defaults, which are ours to tune rather than yours to buy:

Spend is accumulated in integer micro-dollars rather than in decimals, so the ledger cannot drift: floating-point rounding across thousands of calls is exactly the kind of small error that eventually makes a budget decision wrong. Every decision also carries its own input tokens, output tokens and cost, which is why "what is this actually costing" is a query against a table rather than a conversation with an account manager.

The degradation ladder

There are three states, and the design contract behind them is stated plainly in the code that implements them:

Normal

Below the soft threshold. Full-quality investigation: up to six rounds of evidence gathering across the fifteen read-only lookups, full output budget, the standard model.

Degraded

The soft threshold has been crossed. The request is still served, but more cheaply: a tighter output budget and fewer rounds of evidence gathering. The tenant keeps working and the burn rate roughly halves. The decision records the engine as agentic_degraded and says so in its own limitations block.

Exhausted

The daily cap is spent. No further model calls happen today. Triage falls back to the deterministic scorer — free, and still writing an auditable decision — and the engine is recorded as budget_fallback. Interactive chat is told to queue rather than being given an error.

The choice of four rounds for the degraded tier rather than two is worth mentioning, because it is the kind of number that is usually guessed. Two was tried. It did not produce a cheaper answer; it produced no answer, and every degraded run fell through to the deterministic scorer instead. Our evaluation harness caught it by scoring the cheap tier at 24.6 against the standard tier's 67.7 on the same provider. Degradation should reduce depth, not prevent completion.

What degraded looks like on your screen

This is the part that matters to a reader, because a degraded investigation is not labelled with a warning triangle. It looks like a slightly thinner version of a normal one, and the honest signals are these:

• The engine field reads agentic_degraded rather than agentic. That is the single reliable indicator.
• The limitations block gains a line, appended automatically. It is quoted in full below.
• The tool-call list is shorter. Four rounds of gathering instead of up to six means some avenue was not explored — often the one that would have settled an ambiguous case.
• The factor bar may be thinner, and a thinner bar means a lower derived confidence, because confidence is computed from findings that were actually established. A degraded run is therefore somewhat more likely to escalate to you than to reach a decisive verdict, which is the correct direction for it to fail in.

This decision was produced under a cost-degraded configuration (smaller
model or fewer evidence lookups) because the organisation was near its
daily AI budget.

At the cap

Two things happen, and neither of them is an invoice.

Alert triage continues. Every alert still receives a decision; it is produced by the deterministic scorer instead of by an investigation. That scorer reads rule severity, whether the response engine had already auto-approved, and recent alert density on the same sensor — and it says so on its own decision, in a limitations line stating that it did not read the process tree, the identity or threat intel. An exhausted budget never drops an alert.

Interactive chat asks you to come back. The assistant returns a queue response rather than a failure, with a header naming the retry time. The body is exactly this:

{
  "error": "ai_budget_exhausted",
  "detail": "This organisation has reached its daily AI budget.
             Requests resume at 00:00 UTC; ask an administrator to
             raise the cap if this is unexpected.",
  "retry_after": <seconds until 00:00 UTC>
}

The status code chosen is the one meaning "too many requests, try later". A payment-required status would be wrong because nothing is unpaid, and a server-error status would be wrong because nothing is broken. If you see this and it is unexpected, the useful action is to tell us — an unexpected cap is nearly always a noisy source rather than heavy legitimate use, and finding the source is a better outcome for both of us than raising a number.

Which alerts get the expensive path

Not every alert is worth a full investigation, and the platform does not pretend otherwise. A severity floor routes low-severity alerts down the free deterministic path by design, so the expensive path is spent on the alerts most likely to matter. A mixture of engines across your decisions is the normal steady state, not a symptom of something going wrong.

What is not built yet, said plainly

Everything above describes metering that exists and enforcement that works. There is a specific gap between that and an allowance you could hold us to, and this section is it.

• The cap is per deployment, not per plan. The mechanism for making the cap a per-tenant entitlement — so that a larger plan carries a larger allowance — is built as a single seam and deliberately left unconnected. Today one configured default applies to every organisation on a cell.
• Billing does not read AI usage. The daily usage rollup exists, is accurate and is queryable. Nothing in the billing system consumes it. There is therefore no path by which your model usage can affect an invoice, which is convenient given the position at the top of this article, but it also means an allowance cannot currently be metered against a plan.
• Enforcement can be switched off per deployment, in which case usage is still recorded and no request is ever refused. And if the usage lookup itself fails, the platform serves the request rather than failing, recording budget lookup failed; served without enforcement on the grant so the audit record shows the cap was not consulted. A metering read failure must not become a service outage.

Pricing

Every figure on our pricing page is indicative and not yet contractual, including anything describing AI usage, seats or allowances. A firm quote is available on request and is the only thing you should plan a budget against. The numbers in this article — the daily cap and the soft threshold — are operational defaults for our own spending rather than anything you are purchasing, and we may change them without it affecting what you pay.

Two related articles are worth reading next. How confident is confident? explains how a degraded run's thinner evidence shows up in the confidence figure, and The escalation vocabulary covers what to do when a cheaper investigation hands the alert to you instead of settling it. For the wider limits, What Qorionix does, and what it does not is the honest overview.