Credits are the customer unit

A credit is a platform-defined unit of metered agent work. A short support answer usually uses less work than a long crash investigation or a code candidate, so the debit can vary with the work actually performed. You do not need to translate a customer action into provider token prices to understand your balance.

The customer promise is stable: credits are the balance you can spend, the applicable plan and account caps determine whether work may start, and the ledger records what changed. If the platform changes an internal catalog or entitlement version, that change must be versioned and reflected in the customer-facing terms; this page does not turn internal implementation details into a new pricing unit.

What counts as billable work?

A billable action is a bounded agent request or task recorded by the platform. It may include routing, retrieval, model work, and safety checks behind the scenes. The customer-facing result is the metered credit debit and its ledger entry—not a separate charge for every internal workflow stage.

Work that is refused before execution, or that fails because the required capability is unavailable, must not be presented as completed work. Retries and corrections must remain attributable to their actual usage and recorded outcome rather than silently disappearing from the account history.

Caps and hard-stops

• Plan or account cap — an entitlement can limit the number or class of actions available in a period. Reaching a cap is a gate, not permission to continue silently.
• Credit hard-stop — when the balance cannot cover the next metered action and no explicitly enabled bounded overage path applies, the action is refused before it can create an unbilled provider or effector result.
• Optional capped top-up — if this control is enabled for your account, its ceiling is part of the account setting. It must never be treated as unlimited spend; if it is not exposed, the hard-stop remains the safe default.
• Failure is visible — a cap, insufficient balance, timeout, or unavailable effector should be shown as blocked or unavailable, not as a successful action.

Your ledger is the audit trail

Balance changes belong in a tenant-scoped ledger alongside the resulting balance. Depending on the released billing path, entries can include included grants, purchases, debits, carryover, refunds, and administrative adjustments. The ledger is the place to reconcile a balance; a marketing estimate or a synthetic showcase scene is not billing evidence.

Separate resource meters

AI reasoning is measured in credits. Other resources stay separate so a build or retained artifact cannot silently consume the AI balance:

• CI/build execution — build minutes or compute units.
• Artifact retention — retained or pinned storage, typically expressed as a storage quota or GB-month meter.
• Durable tenant storage — the tenant-home or artifact quota, separate from model reasoning.
• Live server operations — any released action or concurrency quota is a separate operational limit, not hidden AI spend.

CI and storage meters are a product boundary and roadmap item until their released customer surfaces, quotas, and reconciliation paths are present. They are not advertised here as silently active or bundled into credits.

What this page intentionally does not promise

• No raw provider COGS or Routera multipliers. Those are internal catalog and entitlement inputs, not customer pricing language.
• No unverified reservation or settlement claim. Internal billing machinery may evolve, but this page does not present a reservation API or provider-call sequence as a customer-visible feature until it has release evidence.
• No live BYOK promise. A stored key, design document, or shape check is not proof of provider validation, fallback, or billing behavior. Only a released and verified account path can establish that availability.
• No automatic billing portal or invoice-history promise. If the account surface does not expose a working route, do not infer one from a schema, mock, or product tour.