# Usage and limits

Availability: Release contract.
Last reviewed: 2026-08-28.

Operational limits and money answer different questions. A rate limit protects the service; a spending policy limits authorized financial activity.

## Authentication usage

The first authentication check is free and does not consume credits. It can still have request limits. The initial console should show actual received authentication activity, not a fabricated billable-usage chart.

Unavailable usage is not zero usage. Rejected unknown keys must not be attributed to an application merely because the request claimed its name.

## Planned financial controls

There are four independent optional limits: account cash spend, application cash spend, account prepaid usage and application prepaid usage. Each defaults to none. An application does not gain a separate wallet.

A cash-spend cap controls new purchases or charges; a prepaid-usage cap controls consumption from existing prepaid funds. Neither should be silently treated as the other.

## Count the right units

Future operations must define their own customer units and distinguish quoted, reserved, consumed, released and settled amounts. Provider calls, pages, qualifying products, hosted media and completed physical services can have different counts.

## Handle limits

Follow server-provided retry timing for request throttles. Do not repeatedly purchase credits to address a rate limit, and do not retry uncertain work just because a quota display has changed.