Open Customize → Usage to review model activity. Choose the source first: the Managed report and device reports have different scopes.

Choose a source

Managed usage requires a connected account. Previously saved API-key and local activity can be viewed while signed out. A device report is not a complete history of work performed on other machines. Deleting a conversation removes its saved call activity; imported billing evidence remains until its import is removed. Inherited fork history is not counted twice. Older saved activity without a known route appears under Unclassified, including any managed calls that cannot be classified.

Filter the report

1. Select Last 7 days, Last 30 days, Last 90 days, or Custom dates.
2. Set From and To when you need a particular range. Both dates are inclusive and use UTC; a range can cover at most 366 days.
3. Choose All models or a single model.
4. Select Tokens, Cost, or Requests in Daily activity. For device reports, choose a Cost category; the cost chart shows known amounts from that category only. Select or focus a day to inspect its totals.

The summary shows each cost category separately, plus recorded tokens, requests and cached input. Amounts with omitted observations are labeled partial, and entirely missing amounts are Unknown. Subscription fees are Not allocated. Imported credits are displayed separately from imported charges; no net invoice amount is inferred. By model summarizes the same filtered records. Refresh reloads the report. A loading or connection error is not a confirmed zero-usage result.

Export the matching records

Select Export CSV below the report. It exports the selected source, dates, and model filter as daily model/provider totals, including:

• UTC date, provider, model, route, and request count.
• Input, output, reasoning, cache-read, cache-write, and total tokens.
• Separate exact decimal USD columns for Wallet charges, provider-reported amounts, catalog estimates, imported charges/credits, calculated Ace amounts, and historical accounting.
• Cost-source labels, unknown cost observation counts, and a clearly labeled compatibility accounting column for older integrations.

Output tokens already include reported reasoning; do not add reasoning again. Cached-token fields explain the breakdown, rather than representing extra requests. A small positive cost can appear below one cent; do not round each row to dollars and cents before summing an export.

The export is an activity report, not a payment invoice. It contains aggregate records, not prompts, complete responses, or project files.

Import provider billing evidence

Choose API keys → Manage billing imports → Download billing template. Convert your provider export into this JSON format, then choose Import billing JSON. This is a normalized exchange format, not an automatic reader for every provider's native export. Keep stable provider billing-line IDs and use the provider ID recorded by OpenScience. Use a consistent label for each provider account. The label is user supplied; OpenScience cannot verify account ownership from the file.

{
  "schema_version": 1,
  "provider": "openai",
  "account_label": "Research API account",
  "currency": "USD",
  "records": [
    {
      "billing_id": "invoice-line-123",
      "kind": "charge",
      "provider_request_id": "req_example",
      "occurred_at": "2026-10-18T12:00:00Z",
      "model": "example-model",
      "amount_usd": "0.0123456789"
    }
  ]
}

Only USD is supported; no exchange rate is invented. Amounts must be nonnegative decimal strings, with at most 12 integer digits and 18 decimal places. Use kind: "credit" for a credit or refund; omitted kind defaults to charge. provider_request_id and model are optional. Timestamps require a timezone. Files are limited to 2 MiB and 10,000 records. Other fields are rejected so a native export cannot silently lose information during conversion.

A unique exact provider/request-ID match can link a billing record to a saved BYOK or custom call. A supplied model must also match. Missing request IDs, missing calls, duplicate local matches, and provider-account collisions remain unmatched or ambiguous. Matching updates when calls are later saved or removed. Imported totals include unmatched records and can cover work outside OpenScience; they are never added to provider-reported or estimated amounts. Importing a bill does not prove that an amount was paid or settled.

Repeated files and overlapping records do not add duplicate billing amounts. Changing an existing billing ID's amount or other evidence fails atomically; remove the imports that reference that record before replacing it. Remove import discards only that local import. Shared records remain while another import references them. This changes neither a provider bill nor Wallet history.

Export billing reconciliation downloads normalized records and their current match state for the selected dates, including stable local call/session IDs when matched. Billing records and import identities are stored in research.sqlite on this device, independently of Synthetic Sciences sign-in and trace sharing. They are not uploaded by this feature. Treat the file and reconciliation export as private financial data.

Compare with dashboard usage

The dashboard Usage page also supports date and model filters and CSV export. Its account view separates managed usage from reported user-owned routes. Those user-owned records depend on what has reached the account; they need not match a device with unshared local history.

Workspace usage respects member permissions. Owners and members with usage-view permission can see workspace totals; other members see their own workspace usage. Dashboard CSV exports cover matching daily model/endpoint totals independently of the recent-request list's 50-row limit.

Reconcile an amount

Use Wallet for settled managed charges and your provider's billing for direct usage. Card payments add purchased funds and can include a separately disclosed processing fee; they are not the same thing as model spend. Temporary reservations, unsettled requests, different date boundaries, and different account scopes can also explain a mismatch.

For a single conversation, open its context indicator or run openscience stats for local session summaries. openscience debug audit <session> adds content-free call identities for the conversation and its workers, including provider request IDs when the provider reports them. These views describe saved research activity and may have a different scope from account reports. If a discrepancy remains, retain the date range, funding workspace, model, request identifier, and relevant CSV rows for support.

See Pricing and usage for rates, reservations, and spending controls, and Privacy and data for trace sharing.

CLI summaries

openscience stats separates locally retained provider reports, catalog estimates, imported billing charges and credits, subscription coverage and historical accounting. Exact decimal amounts stay separate; a partial subtotal shows the number of observations with unreported amounts. Missing evidence is Unknown. This command does not fetch Ace Wallet receipts; check the task context for settled charges.

Cost evidence uses call and billing timestamps in the selected --days window. Legacy accounting statistics describe whole transcripts of sessions active in that window and can contain estimates or historical token zero defaults. They are labeled separately. Use openscience debug audit <session> for exact nullable provider fields on recorded calls.

--project <id> limits evidence to that project's sessions. Unattributed internal calls and unmatched or ambiguous billing records are excluded from project summaries; all-project summaries include them. --models also lists models seen only in internal/failed calls or imports, even without transcript messages.

OpenAI and Azure Responses cache-write counters are retained when the provider exposes them. Explicit zero stays zero; omitted or null counters remain unknown. A reported counter takes precedence over a catalog-based cache-write estimate.

Billed model names and request aliases

A provider can bill a dated model version even when you requested an alias. Keep the provider's name in model and optionally add requested_model with the alias recorded on the local call. Matching still requires an exact provider request ID and one unique local call; the supplied requested name must also match. Without requested_model, model remains the model-name check.

Both names are retained in billing reconciliation exports. Uniquely matched annotated records group under the requested model in Usage; unmatched and ambiguous records keep their billed model name. Alias annotations are user supplied, not verified model mappings. They do not resolve duplicate request IDs or account ambiguity. If you need to annotate an already imported billing ID, remove its original import before reimporting the corrected document; conflicting evidence is never silently replaced.