> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kynasmith.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Billing & limits

> Understand how Kynasmith billing works, including quotas, plan limits, and usage tracking.

# Billing & limits

Kynasmith bills based on **accepted frames** — the pose frames that are successfully processed during your detection sessions. This page explains how billing works and how to manage your usage.

## How billing works

1. Your organization is on a plan that includes a monthly quota of accepted frames.
2. Each detection session submits pose frames to Kynasmith.
3. Frames that are accepted and processed count toward your monthly usage.
4. When your usage approaches or exceeds your quota, the API returns billing-related errors.

See [Accepted frames](/billing/accepted-frames) for details on what counts as an accepted frame.

## Checking your usage

You can check your current usage in the portal at [app.kynasmith.dev](https://app.kynasmith.dev) under **Settings > Usage**, or through the API:

* `GET /api/usage` — Organization-level usage summary
* `GET /api/usage/projects/{project_id}` — Project-level usage breakdown

## Quota and plan limits

| Concept           | Description                                                                                    |
| ----------------- | ---------------------------------------------------------------------------------------------- |
| **Monthly quota** | The total number of accepted frames included in your plan per billing cycle.                   |
| **Billing cycle** | Typically calendar monthly, starting from your organization's creation date.                   |
| **Overage**       | Frames accepted beyond your quota may be billed at the overage rate defined by your plan.      |
| **Grace period**  | A short grace period (typically 3 days) after quota exhaustion before hard enforcement begins. |

## Billing error codes

When a billing limit blocks an operation, the API returns one of these error codes:

| Code                     | Meaning                                              | What to do                                            |
| ------------------------ | ---------------------------------------------------- | ----------------------------------------------------- |
| `quota_exceeded`         | Monthly accepted-frames quota exhausted.             | Upgrade your plan or wait for the next billing cycle. |
| `organization_suspended` | Organization suspended (e.g., extended non-payment). | Resolve the issue in the portal or contact support.   |
| `delinquent_payment`     | Payment is overdue.                                  | Update your payment method in the portal.             |
| `plan_requires_upgrade`  | Feature not available on your current plan.          | Upgrade your plan.                                    |
| `billing_not_configured` | No billing method configured for the organization.   | Set up billing in the portal.                         |

See [Error codes](/api-reference/error-codes#billing-and-quota-errors) for the full error response format.

## Rate limits vs. billing limits

Rate limits and billing limits are enforced separately:

* **Rate limits** (HTTP 429) protect service stability. They are per-minute request caps that apply equally to all customers. Retry after the indicated duration.
* **Billing limits** (HTTP 403) enforce your plan's usage quota. They require a plan upgrade or waiting for the quota reset — not just retrying.

See [Rate limits](/api-reference/rate-limits) for details on request-rate enforcement.

## Managing costs

* **Monitor usage regularly** through the portal or usage API to avoid surprises.
* **Use `replay` mode for testing** with short sample videos to minimize frame consumption during development.
* **Scope browser tokens narrowly** with `sessions:write` to prevent accidental MoveSpec modifications.
* **Finalize or cancel sessions promptly** to avoid frames being counted from idle sessions.