# Connection, request, and speed limits

Litport enforces three distinct controls. The dashboard's legacy word **threads** means concurrent authenticated TCP proxy connections.

## Limit definitions

| Public term | Unit and scope | Enforcement |
| --- | --- | --- |
| Concurrent connections | Open authenticated TCP connections per token | A new connection may wait for the configured capacity window, then fails with proxy error `6`. |
| Request rate | Admission events per second per token | Fails with proxy error `10` when the per-token rate limit is reached. |
| Speed | Aggregate bidirectional bytes/second per token | Traffic is throttled or backpressured; exceeding speed does not itself produce a new proxy error. |

## What counts as a request

| Ingress mode | One request-rate event |
| --- | --- |
| Plain HTTP forward proxy, including HTTP keep-alive | Every HTTP request handled on the connection |
| HTTP `CONNECT` | The tunnel-opening request, once per tunnel |
| SOCKS5 TCP | The authenticated connection, once per connection |

## Speed units

Speed is reported as decimal megabits per second (`Mbps`), matching the dashboard and common network-service conventions. A 100 Mbps limit means 100,000,000 bits per second.

## Client guidance

- Reuse HTTP connections and tunnels when the target workflow allows it.
- Bound parallel work to the capacity configured for the token.
- On error `6`, close idle connections and retry only after capacity can free.
- On error `10`, use jittered exponential backoff and reduce the applicable request or connection admission rate.
- Treat slow writes or reads as normal speed backpressure; do not open extra connections merely to defeat it.