Skip to main content
Every Corti endpoint that consumes credits reports how many it used in its response. Corti has no visibility into which of your customers, features, or workflows a request belongs to, so if you need to bill customers, attribute cost to a feature, or set per-customer budget alerts, capture that context yourself at the point you make each call. This page covers the pattern we recommend: an application-layer wrapper around every credit-consuming call, the same approach commonly used to attribute LLM API spend. For how credits are priced per product, see Corti pricing.

How Corti reports usage

The field to read depends on how you call the endpoint:
usageInfo.creditsConsumed is the same shape on every REST endpoint that returns it. See the response documentation for Guided Synthesis and Medical Coding, or the schema on the Extract Facts and Create Transcript reference pages.
The Agentic Framework reports credits differently: task.metadata.credits on the message:send response, not a top-level usageInfo object. This shape isn’t in the OpenAPI spec yet, but the field is present on every message response and safe to read. For real-time streaming, delta_usage is an approximate running total sent after each flush; the final usage message sent after end is authoritative. See Speech to Text usage messages (the same shape applies to /streams).

Computing cost for Corti Models

Corti Models follows the OpenAI-compatible spec, so it returns token counts, not a credits figure. Use @pydantic/genai-prices (JavaScript/TypeScript on npm, Python on PyPI) to compute the USD cost from the response’s usage object and the documented per-model rates. Corti’s models aren’t in the library’s bundled catalog, so register them as a custom provider with the current rates. The library handles the per-million-token math and the cached-input discount (90% off the standard input rate) automatically — you just map the OpenAI-format usage fields to the library’s Usage shape:
For the Responses API, map usage.input_tokens / usage.output_tokens instead. For embeddings, pass input_tokens only — the library skips output cost when no output rate is set.
A future release of GET /models will return each model’s per-token pricing directly, so you can look up rates dynamically instead of hardcoding them in the custom provider. For now, refer to the documented rates.

The application-layer wrapper pattern

Treat every credit-consuming request as a billing event you tag, measure, and log yourself. Corti doesn’t expose which customer or feature a past request belonged to after the fact, only an aggregate total is queryable retroactively, and only under the conditions described in Limitations below. Capture attribution at request time instead of trying to reconstruct it later. Rather than adding tracking code at every call site, wrap the calls once:
  1. Tag the request with your own metadata: which customer or end-user it’s for, and which feature or workflow triggered it.
  2. Call the Corti endpoint as usual.
  3. Read the credits or tokens consumed from the response (see the table above for which field).
  4. Log one structured event per request to your own datastore: request ID, timestamp, feature, customer ID, credits consumed, latency, and status.
Apply the same pattern to WebSocket streaming by logging from the usage message instead of a REST response:

What to record per event

Reject events with missing metadata instead of defaulting to “unknown”. An unattributed cost event is harder to fix after the fact than a wrapper call site you forgot to update.

Aggregate and alert

Once events land in your own store, attribution is a query, not an integration problem:
  • Sum credits by customer ID and time window for chargeback or invoicing.
  • Sum by feature to see which parts of your product are most expensive to run.
  • Alert when a customer’s rolling spend crosses a threshold you define.

Corti Assistant: the event is the wrapper

If you’re integrating Corti Assistant rather than calling the Corti API directly, you don’t need to build a wrapper. The embedded widget already emits an account.creditsConsumed event after every stream, transcription, or document generation. Listen for it and log the same fields you would from a wrapper: creditsConsumed, reason, and interactionId are all in the public (non-confidential) payload, so you don’t need to handle patient data to attribute cost.
See Corti Assistant events for the full event system and transport options (Web Component, postMessage, or window API).

Limitations

  • Corti Models doesn’t return a credits figure directly; see Computing cost for Corti Models above.
  • The Admin API exposes an aggregate consumption endpoint (total credits for one of your Embedded Assistant end-users over a time window), but it reports a total, not a per-request or per-feature breakdown. Treat it as a cross-check against your own totals, not a substitute for wrapper-level attribution.