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.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:- Tag the request with your own metadata: which customer or end-user it’s for, and which feature or workflow triggered it.
- Call the Corti endpoint as usual.
- Read the credits or tokens consumed from the response (see the table above for which field).
- Log one structured event per request to your own datastore: request ID, timestamp, feature, customer ID, credits consumed, latency, and status.
usage message instead of a REST response:
What to record per event
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 anaccount.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.
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.