Credit lifecycle
Credits measure eligible Starfire compute and feature usage. The available balance can come from more than one source and can be governed by billing periods and hard limits.Credit sources
Depending on plan and active product configuration, a billing context can contain concepts such as:- plan-included credits
- organization shared credits
- administrative bonus credits
- purchased credits when supported
- temporary promotional or recovery credits
Usage attribution
Every metered workload should be attributable to the context that owns it:- personal Chat
- organization Project
- FORGE build
- Research run
- developer API application
- agent/workflow run
Billing periods
Plan-included allowances can reset or renew according to the subscription/billing period. The active billing surface is the source of truth for current period dates and available allowance.Hard ceilings
A hard credit ceiling blocks additional metered work after the configured threshold even if an upstream provider would still accept the request. This lets users and organizations bound spend or usage.Bonus adjustments
Authorized administrators can apply audited credit adjustments when product policy allows it. Bonus credits should be visible as a distinct source rather than silently rewriting historical usage.Reconciliation
If renewal occurred but the expected allowance did not appear, troubleshoot period/provisioning state before manually adding credits.Shared organization credits
Shared pools should still preserve attribution by member/application/workload. A shared balance should not make it impossible to discover what consumed the credits.Starfire does not publish one permanent credits-per-token conversion in the docs because model/provider cost and platform metering configuration can change independently.