Usage & Analytics

Every request records tokens, latency, time-to-first-token, provider, and status. View it in the dashboard or query GET /me/usage.

Every request through Ada AI records tokens, latency, time-to-first-token, provider, and status. You can browse it in the dashboard or query the /me/usage endpoint directly.

In the dashboard

Sign in and open Usage for a chart and table of your request, token, and throughput history — broken out per model and upstream. Switch the time range between 24h, 7d, and 30d; granularity follows automatically (hourly under 7 days, daily at 30d).

Decode speed, end-to-end speed, and time-to-first-token are shown only where the underlying sample is non-empty — a dash (—) means no matching traffic in that bucket, not a measured zero.

Per-organization usage

Any member (not just admins) can open an org → Usage for that org's own throughput history. It reflects only traffic sent through keys scoped to that org; a member's personal traffic (or their traffic through a different org's key) never appears here.

Your own /me/usage includes traffic you made through an org key too — it's selected by user_id, not scoped to personal-only rows. To see one org's pooled traffic (yours and every other member's), use that org's usage page instead.

`GET /me/usage`

The endpoint takes more than the dashboard UI currently exposes — custom from/to, group_by, and a model filter.

Requires a Stytch session JWT

/me/usage returns 401 for a proxy key (sk-rc-…) or an admin token. Only a Stytch session JWT authenticates this route. GET /me/organizations/{id}/usage takes the identical parameters and returns the identical envelope, scoped to the org instead of the caller.

Query parameters (all optional)

Param	Default	Notes
`from`	`to` minus 24h	RFC3339 timestamp. Must be strictly before `to`.
`to`	now	RFC3339 timestamp.
`granularity`	`hour` if range ≤ 7 days, else `day`	Must be `hour` or `day` if given explicitly.
`group_by`	`model_upstream`	`model`, `upstream`, or `model_upstream`.
`model`	—	Exact-match filter on the model string (authenticated, so no length/charset limit).

to − from is capped at 90 days; a longer range is a 400.

Example

curl -G https://api.ada.ai/me/usage \
  -H "Authorization: Bearer $JWT" \
  --data-urlencode "from=2026-08-01T00:00:00Z" \
  --data-urlencode "to=2026-08-08T00:00:00Z" \
  --data-urlencode "granularity=day" \
  --data-urlencode "group_by=model"

Response shape

{
  "granularity": "day",
  "from": "2026-08-01T00:00:00Z",
  "to": "2026-08-08T00:00:00Z",
  "buckets": [
    {
      "window_start": "2026-08-01T00:00:00Z",
      "model": "glm-4.7",
      "requests": 42, "successful": 41, "errors": 1,
      "input_tokens": 12000, "output_tokens": 5400,
      "decode_tokens_per_s": 87.3,
      "e2e_tokens_per_s": 40.1,
      "ttft_ms_avg": 210.5,
      "latency_ms_avg": 1340.2
    }
  ]
}

model, upstream_id, upstream_name, and upstream_host are present only when group_by selects that dimension. Every rate field (decode_tokens_per_s, e2e_tokens_per_s, ttft_ms_avg, latency_ms_avg) is number | null — null means the bucket had no sample for that metric (e.g. no streaming requests for the decode fields). It is never coerced to 0.

What's recorded per request

Field	Meaning
`window_start`	Start of the hour or day bucket.
`model`	The model ID requested.
`upstream_id` / `upstream_name` / `upstream_host`	Which upstream served it (when `group_by` includes the upstream dimension).
`requests` / `successful` / `errors`	Request counts.
`input_tokens` / `output_tokens`	Token usage.
`decode_tokens_per_s`	Streaming decode throughput (null if no streaming samples).
`e2e_tokens_per_s`	End-to-end throughput (null if no streaming samples).
`ttft_ms_avg`	Average time-to-first-token in milliseconds.
`latency_ms_avg`	Average end-to-end latency in milliseconds.

Attribution is denormalized

Each row's organization_id is written once, from the key's scope, at request time — it's not derived by looking up which org currently owns the upstream. So an org's usage history survives deleting the upstream that produced it (the upstream's own upstream_id reference goes to NULL, but organization_id and upstream_host stay put).