Billing and Usage

Choose the scope and credential first

• One key's usage/budget: call GET /v1/key with that inference API key. Read usage, limit_remaining, and limit_reset. This is a key spending budget, not the enterprise wallet or credit balance.
• Enterprise wallet and credit: call GET /enterprise/v1/billing/balance with a MANAGEMENT key scoped only to tenant:billing:read. Inference and PROVISIONING keys cannot use it.
• Account charges/request reconciliation: existing GET /v1/billing and GET /v1/billing/requests/{request_id} use an inference key or signed-in JWT. Management keys cannot call these /v1 endpoints. Recorded charges and remaining balance are different metrics.
• Legacy account balance: GET /v1/billing/balance remains compatible and reports account funds, not the calling key's remaining budget. Prefer the Enterprise endpoint for new enterprise balance monitoring.

Enterprise API guide · Get enterprise balance

Token360 meters each model request using the pricing rules published for the selected model. Charges can be reconciled from the response, the console, and billing APIs.

How charges are calculated

The billing meter depends on the model. Common meters include:

• input and output tokens;
• reasoning or cached tokens where separately priced;
• generated images;
• audio characters or seconds;
• video duration, resolution, or another model-specific unit.

Always use the pricing section of the live model page. A provider's public price is not automatically the price of the Token360 route, and different SKUs of the same model can use different meters.

Estimate versus final charge

Playground estimates are planning aids. Final billing uses measured usage and the active pricing rule after the request completes. Inputs such as output length, generated duration, and provider-reported usage can make the final charge differ from a pre-request estimate.

For asynchronous work, billing may be finalized after the resource first enters a terminal state. Use request-level reconciliation when exact settlement matters.

Request-level reconciliation

Store the request or generation ID returned by inference. Query:

1GET /v1/billing/requests/{request_id}

The response indicates whether the request is billed and returns recorded usage and charge components when available. Use this endpoint to reconcile customer-visible jobs, not an estimate reconstructed only from token counts.

Account usage

Use GET /v1/billing for summarized account usage over a time range. Enterprise administrators can filter authorized data by member or API-key display identifier. The console also provides dashboard charts, request details, and CSV exports where available.

Use UTC boundaries when comparing daily API results, API-key reset periods, and daily spend protection.

Postpaid funding semantics

All amounts are USD. Under POSTPAY, positive wallet top-up funds are spent first and the remainder uses enterprise credit. Promotional Credit/vouchers are neither spent nor included in the total.

• credit_limit_usd: approved credit limit.
• current_exposure_usd: credit used in the current open billing period.
• credit_remaining_usd: max(credit_limit_usd - current_exposure_usd, 0).
• credit_available: remaining enterprise credit under POSTPAY; available vouchers under PREPAY. These meanings are different.
• total_spendable: max(wallet_available, 0) + credit_remaining_usd for POSTPAY; the existing wallet_available + credit_available for PREPAY.

Historical unpaid invoices are not deducted from remaining credit a second time. Balances are snapshots of recorded billing data, not real-time reservations. Exhausted credit, key limits, account spend protection or other policies can still reject requests. Exhausted credit blocks new POSTPAY calls even if wallet funds remain, so the total is not a guarantee of callable capacity.

Spending controls

Token360 provides several independent controls:

The most restrictive active control wins. Raising daily spend protection cannot override an exhausted credit limit.

Investigating a billing discrepancy

1. Capture the request ID and UTC timestamp.
2. Compare the response usage with request-level billing data.
3. Confirm the public model name and pricing rule shown on the model page.
4. Check whether the request was retried or submitted more than once.
5. For Batch, inspect aggregated billing and individual output lines.
6. Contact support with IDs and amounts, never with API-key secrets.