Reading usage in the console

The Usage tab answers the question “what was consumed, by whom, and for how much”. This page describes what it shows, what its figures do not tell you, and the comparison it does not make.

Like the accounts and plans tabs, it only exists in consoles built with the hosted profile: usage is read from the billable request log, which the closed profile does not write. The console is restricted to administrators (security white paper V3, section 6.2). What this screen shows is usage metadata, stored in the database, on your side: neither request content nor code appears there (security white paper V3, section 8.3).

What the screen shows

Four totals over the selected period (input tokens, output tokens, request count, cost), then two charts:

• token volumes as stacked bars, with the request count as a line on a second axis;
• cost, as areas.

There is no table: no row per call, no export. What you see is an aggregate.

Choosing the period and the granularity

Four granularities (hour, day, week, month) and a period selector. The default is the current day.

The granularity you choose sets the chart’s step: a day is split into hours, a week or a month into days, an hour into minutes. Intervals with no calls are shown as zero rather than omitted, so that the line does not look continuous where there is nothing.

Intervals are placed in your browser’s local time. Two people in two time zones do not see the same split for the same day.

The period selector stops at the current period: there is no future to display.

Filtering

Two filters, User and Model, each with an “all” entry (All Users, All Models).

Their values come from two different places:

• the account list comes from the account registry. An account that has never called anything appears there;
• the model list comes from the request log. A model that is declared but never called does not appear; a model that was called and then deleted still appears.

How cost is calculated

For each logged call, the cost is the number of input tokens multiplied by the model’s input token price, plus the same thing for output. The prices used are those declared on the model at display time, in nano-euros per token. See Declaring a model served by the gateway.

Three consequences to know before presenting these figures:

1. A price change changes the past. The cost is not frozen at call time: it is recalculated at each display with the current price. Changing a model’s price changes what the console displays for past months.
2. A model with no price costs zero. A price left at zero when declaring the model, or a model that was called and then deleted, produce a cost of zero. An unexpectedly low total is diagnosed there. The screen uses a banner to flag calls it could not price (missing token counters, or a model with no declared price). A price set to zero is not a missing price: it does not trigger the banner and it costs zero.
3. There is no currency conversion. Amounts are in euros, as expressed by the declared prices.

Very small amounts are displayed with up to eight decimal places: over an hour and a few calls, a cost is written in fractions of a cent.

Comparing against the cap

This screen knows nothing about caps. The Caps tab is the one that compares an account’s spending against the cap that will block it.

Two differences make it impossible to read one for the other:

• the cap applies to the current calendar month, whatever the period you are looking at here;
• the cap is compared against a single account’s spending, whereas this screen aggregates everyone by default.

The two screens answer two different questions. This one answers “what was consumed, by whom, on which models”, over a period you choose, with charts. The Caps tab answers “who is going to be blocked this month”, with no charts, over the calendar month.

See Capping a customer’s spending for caps and the refusals they produce.