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

# Plans and limits

> How Registry licenses, bandwidth allowances, and incoming request limits work.

The Engine verifies its license with Fused Registry at startup and refreshes
plan limits through heartbeats. It keeps limits in memory and enforces them
locally; ordinary requests do not call Registry.

## What is limited

| Allowance                    | Meaning                                       |
| ---------------------------- | --------------------------------------------- |
| Input bandwidth              | Bytes admitted during a UTC calendar month    |
| Output bandwidth             | Bytes returned during a UTC calendar month    |
| Incoming requests per second | Incoming HTTP requests and WebSocket messages |
| Entity profiles              | The plan's entity-profile cap                 |

There is no separate outgoing-request rate allowance. Rate counts requests;
bandwidth counts bytes. Current self-hosted plans do not charge per token or
cap the number of threads created. Storage capacity depends on your deployment.
Protocol request-size and concurrency safeguards still apply.

## Registry operator configuration

Registry administrators add `threadify` inside each existing plan entry in
`registry.yaml`. Preserve the other product's fields in the same entry.

The following example allocations use decimal MB (1 MB = 1,000,000 bytes).
The dev request and profile values shown are examples; use your chosen policy.

```yaml theme={null}
plans:
  - id: dev
    name: Developer
    # Existing Fused plan fields go here.
    threadify:
      input_bandwidth_bytes: 64000000
      output_bandwidth_bytes: 125000000
      input_requests_per_second: 100
      entity_profile_limit: 100

  - id: scale_up
    name: Scale Up
    # Use your existing plan ID and retain its Fused fields.
    threadify:
      input_bandwidth_bytes: 256000000
      output_bandwidth_bytes: 512000000
      input_requests_per_second: 1000
      entity_profile_limit: 100
```

Use your existing plan IDs. These are example allocations, not published pricing.
Set all four fields: `-1` means unlimited; **zero or missing means denied**.

Restart Registry after changing its YAML. The Engine receives changes on its
next successful heartbeat (normally 60 seconds). This YAML belongs to Registry,
not your Engine installation.

## Why can the dashboard return 429?

Dashboard API requests currently share the Engine's request and bandwidth quotas
with integrations. This includes `/v1/contracts` and `/v1/billing/plan`; a quota
can therefore prevent the plan page itself from loading.

* A brief burst can exceed `input_requests_per_second`.
* A zero or omitted request limit can reject requests continuously.
* Exhausted output bandwidth can prevent an otherwise valid response.

Check the license's plan fields and reverse-proxy limits. `/health` does not
check quota, and a generic 429 may not identify the exhausted allowance.

## Registry outages

After a successful verification, a failed heartbeat does not stop the running
Engine. It continues enforcing the last verified limits. Explicit suspension or
revocation is different from a transient network failure. A new startup still
needs to verify its license.