Skip to main content
Your organisation’s usage shows what its requests used and cost. Its request history helps you diagnose a single request. Read the last 7 days of usage:
GET /v1/organization/usage returns totals, the same totals for the period before in previous, and daily values. by_model and by_api_key break them down by served model and by API key. Dates are UTC unless you pass a timezone. Diagnose a request lists the fields. In an organisation with several projects, a key that works as a developer sees only its own project. It lists, spends and counts usage there alone. This holds for an owner’s full-access key too. To read usage for the whole organisation, use an admin key.

​
Metering

usage.input_tokens counts your input with the shared billing tokenizer, which usage.tokenizer names. It is not the model’s rendered prompt. usage.decisions counts the decisions. Native decisions return probabilities, not generated text.

​
What counts as input

You pay only for the text you send:
  • the context
  • each decision’s question
  • each outcome’s name and description. A binary decision counts only the descriptions you give yes and no. An ordinal decision counts its levels and its rubric lines
  • the image tokens of each picture (images)
A decision whose outcomes are the same as an earlier decision’s in the request, with the same names and descriptions in the same order, doesn’t pay for them again. Nothing OneHot adds to a request is billed. The quickstart’s request, with its descriptions and rubric, comes to 648 input tokens. To count a request before you send it, use its estimate, POST /v1/decide/estimate (score many texts). Usage is metered against the model that answers, a fallback included. Each billed input token costs: Before a decision runs, the wallet reserves the requested model’s price (Credit and holds). The response’s charge records the operation ID, the reserved amount and the answering model’s charge. The charge and the answer are saved together before the answer is returned. To recover the answer after a lost response, send the request again with its Idempotency-Key (After a lost response). An organisation with zero data retention keeps no answer. There, a retry runs again and is charged again. Read prices from the current catalogue and account, not from a guide.

​
Diagnose a request

start and end are required. They are inclusive dates, in UTC unless you pass a timezone. This example reads today in UTC. The history is cursor-paginated (Pagination). To find one request, pass request_id: the X-Request-ID or X-Operation-ID its response carried. A period is 1 to 90 days. A page lists limit requests: 25 if you leave it out, and at most 200. model, api_key_id, source (api or console) and project narrow it to one model, key, source or project. GET /v1/organization/usage takes the same filters, and its days is 1 to 90, or 30 if you leave it out. The history has request IDs, status codes, requested and served models, timing, token counts, fallback reasons, costs and key identity. It never has the request’s context or answers. Fields can be null for a failure before scoring. GET /v1/organization/usage reports: The other fields count inference. None of the times includes the client’s network time.