Usage

Open Usage in the signed-in SayGM dashboard to inspect account activity and spend.

Check the current key balance

For a point-in-time balance check from the same API key an application uses:

curl -fsS "https://api.saygm.com/v1/credits" \
  -H "Authorization: Bearer $GM_API_KEY"

This returns the key’s current spendable balance. See check balance and current spend for the response fields. It is not a usage-history endpoint.

Read a key’s usage history

An application can read its own key’s request counts, errors, and spend without a dashboard session:

curl --get "https://account.saygm.com/v1/usage/self" \
  -H "Authorization: Bearer $GM_API_KEY" \
  --data-urlencode "from=2026-09-01T00:00:00Z" \
  --data-urlencode "to=2026-09-08T00:00:00Z" \
  --data-urlencode "group_by=day"

Note the host: account.saygm.com, not api.saygm.com. group_by is model (the default) or day, grouped by UTC day. Without from and to the window is the last 30 days; one request covers at most 90 days. Each row reports requests, errors, and spent with exact usd and nano_usd values.

The endpoint returns only the presented key’s usage. It does not accept a key or account selector; use the dashboard for account-wide activity.

Make usage attributable

Create a separate API key for each application and environment. Give every key a descriptive name such as production-api, staging-worker, or local-dev. This makes unexpected activity easier to isolate and lets you revoke one workload without interrupting the others.

Investigate unexpected spend

1. Identify the affected key and time window in the dashboard.
2. Check recent deployments, background jobs, retries, and streaming reconnects.
3. Revoke the key immediately if compromise is possible.
4. Replace it only in the intended workload.
5. Contact hi@saygm.com with timestamps and request IDs, but never include the API key or prompt content.

Application-side telemetry

Record model ID, status, latency, and your own correlation ID. Avoid logging SayGM keys, authorization headers, or sensitive request content. When retrying, record the attempt number so duplicated work can be distinguished from separate user requests.