Audit and cost tracking — AI Portal Docs

Cost is logged per model call and grouped by turn only for display. A turn is an agentic loop of many calls, and a per-turn record would lose which model, tool or retry spent the money.

Key rules

One record per model call, never per turn. Turns, people and departments are groupings over the same records.
Cost rolls up model call → turn → user → department → cost centre.
The portal keeps no price list. Every rate comes from the model gateway.
You read cost back only for your own scope. Organisation viewers see the organisation, a department lead the department, everybody else themselves.
Reading somebody else’s conversation is recorded. It needs transcript.read, and an approved request where your organisation requires one.

How one model call is recorded

A usage report arrives

Each usage report from the agent stream is one model call.
It is priced

The tokens are priced at the model’s four rates: input, output, cache read and cache write.
It is written in one go

One audit record and one update to the daily rollup are written together, in a single transaction.
Budgets are checked

The new daily total is checked against the department’s budget thresholds. See Budgets and policy.

What is recorded per model call

Field group	Contents
When and who	Timestamp, user, department
What ran	Agent, model
What it used	Tokens in, tokens out, cache reads, cache writes, cost, tools invoked
How it ended	An admission, then an outcome (below)

Admission	Outcome
`ALLOWED` · `BLOCKED_MODEL` · `BLOCKED_QUOTA` · `BLOCKED_BUDGET` · `BLOCKED_RATE_LIMIT` · `BLOCKED_GUARDRAIL`	`NOT_ATTEMPTED` · `SUCCEEDED` · `PROVIDER_ERROR` · `CANCELLED`

A message your organisation’s guardrails refuse before its turn opens leaves one record with BLOCKED_GUARDRAIL and NOT_ATTEMPTED, priced at nothing. Each finding a guardrail matched is recorded on its own — see Records of findings.

How long prompt and response content is kept is set by your organisation.

Where the price comes from

The portal keeps no price list. A reconcile copies the four rates the gateway publishes for each served model onto that model’s catalogue entry: plain input, output, and the two a cached prompt needs. Nothing else writes them, and an administrator cataloguing a model is not asked for them.

Cache tokens. Cache reads and cache writes are counted inside the prompt total, as the gateway counts them. They are not priced like plain input:

Token	Price
Plain input	The input rate
Cache read	A tenth of the input rate (×0.1)
Cache write	The cache-write rate, which carries a premium over input

Pricing the whole prompt at the input rate would therefore read low.

What the screens show. The spend screen and the audit log show the prompt with its cache reads taken out, and keep the whole count a hover away, because a bill is checked against the new tokens. The rollup carries both counters, and a rate limit counts the full prompt.

When a price is missing, the portal refuses rather than guessing:

Refusal	When
A model with no input or output rate serves no turn	Between cataloguing a model and the reconcile that makes it servable; the reconcile report names those models
Cache counters for a model with no cache rate stop the call	Instead of pricing those tokens at nothing

How cost rolls up

Every level is a grouping over the same per-call records:

Model call — the record itself.
Turn — the calls of one agentic loop, grouped for display.
User — the person the call ran for.
Department — the cost bucket the call was billed to.
Cost centre — recorded on each call, so spend can be reported by cost centre.

Guardrail charges are kept as their own daily charge per person and department, and the usage screens add them to model spend.

Reading cost back

Rows are paged, one per department, person, model and day.
Dashboard figures are summaries over a window, grouped by day, department and model — a month of rollups runs to thousands of rows, more than any page serves.
Distinct active people cannot be summed from smaller windows, so a daily and a weekly count are two separate queries.

Spend on a personal model key. Spend on a model served by a model key its owner pasted is split out by the model itself, since such a key brings catalogue entries of its own. The model breakdown lists and marks them, and the budget sums that fire a department’s alerts leave them out — the department’s pool paid for none of it.

Reading message content

A conversation belonging to somebody else is reached with transcript.read and nothing else. It opens three routes:

Route	What it records
A listing of every conversation in the organisation	Nothing — it holds no message content
One conversation’s transcript	A content-access record
The files one conversation produced	A content-access record per file read

A content-access record names the reader, the owner, what was read and the caller’s address. When the reader is the owner, their own reads record nothing.
Opening a file to read it on screen goes through the same route as saving it, so both leave the same record.
A transcript names attached files by id only, so transcript.read also reads a file’s name, type and size. That read records nothing: the transcript read that named the file already recorded the disclosure, and showing a picture or opening a document records its own file read.
An artifact’s own visibility rules are ignored here. The artifact is resolved against the conversation it was produced in, so nothing reaches an artifact that conversation did not produce, and the read is recorded the same way as an attachment read.

Impersonation

Starting and stopping an impersonation each write an admin event naming the administrator as actor and the person they acted as as target; records written in between carry the impersonated person’s id, so the window between the two events is what an auditor reads.

The start event carries the moment the window closes, the stop event the moment it opened. The stop event is written on every way out: the button, the half hour running out, and signing out while a window is open.

Other audit records

Record	Purpose
Per-call audit	One record per model call
Daily rollups	Running cost, plus prompt, cache-read, cache-write and completion counters, per bucket
Admin events	A governance or configuration change: SCIM writes, memory writes, both ends of an impersonation, access requests and approval switches
Content-access events	Who read a conversation, transcript, file or audit export

Budget enforcement, which these records feed, is described in Budgets and policy. To search and export them, see Audit log.

Why it works this way

Why one record per model call?

A turn is an agentic loop of many model calls. A single record per turn would lose which model, tool or retry spent the money; per-call records keep that, and a turn total is just a grouping.

Why no price list in the portal?

The gateway already publishes the rates for each model it serves, so the portal copies them in a reconcile instead of asking an administrator to type them. A model with no rate is refused rather than priced at nothing.

Why does asking about somebody else answer about you?

A narrowed read that returned an error for an unknown person would reveal whether that person exists. Answering about the caller reveals nothing.

Under the hood

The live write path

One usage chunk from the agent stream is one model call: one audit row plus one daily-rollup upsert, in a single transaction, in the portal’s usage schema.

Property	Why
The rollup’s unique constraint is real and every column in it is `NOT NULL`	Two concurrent calls for one bucket both land as increments
An audit row snapshots the agent name, model name and cost centre	It stays self-describing after those rows are retention-deleted
The run id correlates to the turn by value, never by foreign key	The two schemas are on independent retention schedules

How a personal-key model is recognised

No column on the audit row or the rollup records that a model was served by a pasted key; the join to the model catalogue answers it.

Audit log Search model calls, guardrail findings and content reads.

Budgets and policy How these records feed alerts and the hard stop.

Access approvals When reading a transcript needs a second administrator.

Guardrails Findings, refused messages and guardrail charges.