Skip to content
ATLAS
 Docs
On this page

Usage and audit#

Every AI request through the gateway leaves one permanent record. Usage statistics, the Explore view, budgets and the audit log all come from that single record, so the numbers always agree.

The big picture#

flowchart LR
    C[Caller] -->|request| G[Gateway]
    G -->|usage record| L[(Audit log)]
    G -.->|body, if capture is on| B[(Secure body storage)]
    L --> ST[Statistics and Explore]
    L --> BU[Budget spend]
    L --> AL[Audit log search]
    B --> AL
  • One source of truth. The audit log is the only record of who called what, with which model, at what cost.
  • Records are permanent, bodies expire. ATLAS keeps the record of each request. Prompt and response text, if captured at all, expires after a retention period.
  • Two ways to read it. The audit log answers "what exactly happened in this request?". Statistics answer "how much, and who spent it?".

What is recorded#

ATLAS records every request that gets past authentication, whether it succeeded, failed or was cancelled. It writes the record just after the response, so a lookup straight away may briefly miss it.

Each record keeps a copy of the names it needs. These are the user email, project name and code, space name and organisation. They also include the last characters of the API key and the model as the caller named it. This is deliberate:

  • History outlives what it describes. Deleting a user, space, project, key or organisation never changes past records.
  • Reports show names as they were at the time, so renaming something doesn't split its totals.
  • Something deleted later shows as "Deleted" in viewers, never as an error.

Two labels tell you who and where. The actor is a person (their email) or a machine (a project key, shown as project name and code). The acting context is the space or project the request ran under, if any.

Chat in the web app uses the person's own API key, so grouping by key still covers it.

Tracing a request#

Every gateway response carries an atlas-request-id header. It's also the ID of the audit record, so your ilionx contact can find the exact record from the header you send them.

If you send your own atlas-correlation-id header, ATLAS stores it and echoes it back. Use it to group several calls of one workflow and search for them later. ATLAS never invents a correlation ID, and it doesn't pass either header on to providers.

Conversations#

A conversation groups related requests. ATLAS builds it from the log and doesn't store it separately.

  • If you send a correlation ID, requests with that ID belong together.
  • Otherwise ATLAS recognises a multi-turn chat from its opening system prompt and first user message, which stay the same as the chat grows.
  • A gap of 30 minutes ends a conversation. The same opening after the gap starts a new one.
  • Requests that can't be grouped appear as single-request entries, so nothing disappears.

Use Conversations to understand a session and Request Log to pinpoint one call. Each conversation links to its requests.

Prompt and response capture#

Prompts and responses are sensitive, so capturing them is opt-in and kept apart from the record.

  • Set per provider. You switch capture on for a provider, not per organisation. Where it's off, ATLAS never stores a body.
  • Never blocks a request. ATLAS stores bodies in the background. A failed upload doesn't affect the request or its record. The record shows whether the body is pending, stored or unavailable.
  • Separate permission. Search results never contain bodies. Reading them needs the Auditor role, so someone who can see what was spent can't automatically read what was said.
  • Bodies expire after the retention period. The record stays.

ATLAS records and reports. It doesn't filter content, detect or redact personal data, or produce compliance exports.

Data and privacy#

Question Answer
What is stored for every request? Metadata only: who (user or project key), organisation, space or project, model, provider, status, tokens, cost and timing. Prompt and response text are not part of it.
Are prompts and responses stored? Only if capture is switched on for that provider. It is off by default.
How long is it kept? Metadata is kept indefinitely. Captured bodies expire after a retention period. ilionx sets one retention period for every organisation (365 days today).
What happens when a user, project or organisation is deleted? Past records stay and keep the names they had at the time.
Who can see the metadata? Individuals see their own requests. Organisation Auditors read the organisation's audit log.
Who can read prompt and response bodies? Organisation Auditors only. Admins and Owners do not get bodies unless they also hold the Auditor role.

For the full list of roles, see Roles and permissions.

Statistics#

ATLAS computes statistics from pre-totalled figures per hour and per day, so dashboards stay fast over long periods. Totals are exact for any start and end time.

  • All outcomes count. Failed and cancelled requests count in cost and tokens when they reached a provider, because it may already have used tokens. Refused requests cost nothing. The status is visible in the audit log. For more information, see Pricing and cost.
  • Granularity follows the period. Charts are hourly for a week and monthly for a year. Empty periods show as zero, so charts have no gaps.
  • The same numbers drive budgets. The spend you see is the spend that budgets enforce.

Who sees what#

  • Organisations see what they spend, split between models billed by ATLAS and their own provider connections. The provider invoices the second group, and ATLAS shows it as an expected invoice. Organisations also see the platform fees as a separate figure. They don't see ATLAS's revenue or upstream cost.
  • Individuals see their own requests in the active organisation. Nobody sees another person's requests this way, not even an Admin.
  • Project dashboards are visible to project members. Per-person spending and key rankings are limited to Admins and project managers, and machine traffic appears as one combined entry.

Forecast#

The forecast looks at the last 28 closed days, fits a trend and applies a weekday pattern, so it projects weekends and weekdays differently. With fewer than 7 days of history, ATLAS shows no forecast rather than a misleading one.

Explore#

Explore is a drill-down table. Choose a focus, pick the dimension to break it down by, and sort, compare or split by month.

flowchart TD
    ORG[Organisation] --> SP[Spaces]
    ORG --> PR[Projects]
    ORG --> PV[Provider]
    SP --> SP2[Space and sub-spaces]
    SP2 --> U[Users]
    SP2 --> M[Models]
    PR --> PR2[Project]
    PR2 --> U
    PR2 --> M
  • Spaces and projects are separate. Space figures never include project traffic. Project figures include machine traffic that no person made. A row called "No space or project" holds the rest, so the parts add up to the whole.
  • Compare against the previous period or any chosen month, or split by month, to answer "what changed?" without exporting data.
  • Space managers see the same screen limited to the spaces they manage and those below. Anything outside their reach behaves as if it doesn't exist.
  • Providers are grouped by a stable ID, so renamed or deleted connections stay accounted for. Models provided by ATLAS appear under a single "Platform" row.
  • Rankings on the Overview link into Explore with filters already applied.