Credit Usage
CreditUsage renders the signed-in company’s credit balances as a card per credit: what is left, the grants behind it, how the plan’s grants add up, and who on the team spent it. The cards load from the company billing API, so they need a session on the provider as described in the Drop-in components overview.

Usage
Props
A company with no credits, on a plan that draws on none, renders nothing.
Buy More
“Buy More” shows on a credit only when a bundle of it is on offer to the company’s plan, and only when you give it somewhere to go with onBuyMore or buyMoreUrl. The component has no purchase flow of its own, so you decide whether the button opens your checkout, a dialog, or a page.
Balance details
Each card shows the remaining balance, such as “3,100 AI credits remaining”. When the plan grants the credit per license, a line under it shows the plan’s total per period, the license count times the per-license amount that makes it up, any company grant on top, and the day it renews.
“See balance details” opens the ledger: the live grants behind the balance, newest first. Each grant names where it came from (included in the plan, a bundle purchase, an auto top-up, or a promotional grant) and when it resets or expires. The ledger shows three grants, then “See all” for the rest. The server leaves expired and zeroed-out grants out. A credit with no grants shows neither the ledger nor usage by user.
Usage by user
Under the ledger, each credit lists who on the team spent it over the span of its live grants, heaviest first, with the team’s total. It shows three people, then expands to the top 20 and reports the rest as a count. Usage sent without a user appears as “Unattributed” once the list is expanded. When this list fails to load, it shows its own message and “Try again” and the rest of the card stays.
Errors
A failure with nothing to show replaces the content with a short message and a “Try again” button. A 404 reads “Credits are not available for this account.”, because that status means the account is not enabled for the company billing endpoints. Every other failure, and a 404 under balances already loaded, reads “There was a problem retrieving your credits.” A refetch that fails with balances on screen is reported under them rather than replacing them. In development the component logs the underlying error to the console beside the copy.
Strings
Every word the component renders resolves through strings on the component, then on the provider, then the provider’s translate, then English. See Localization for how the chain works. These are the component’s own keys:
The per-user list shares the usageByUser* keys with Metered Features, and the composition line uses periodMonthShort, periodQuarterShort, and periodYearShort (mo, qtr, yr).
Markup
This is what the component renders, for a host styling it without SchematicStyles. The root carries no card styling of its own; each credit is a schematic-card. Styling and theming lists the shared classes.
While loading, the root carries data-state="pending" and aria-busy="true", with a visually hidden schematic-hidden loading label and a schematic-skeleton: a heading bar when showHeader is set, then two rows, each with a name and a remaining cell. On a failure with nothing to show, the root carries data-state="error" and holds a schematic-status row.
Build it yourself
useCreditBalances returns the balances with their grants, and useCreditUserUsage(creditId) returns one credit’s usage by user. deriveCreditUsage turns the balances into each credit’s remaining amount, ledger rows by kind with their dates, and the plan composition.