> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://murf.ai/api/docs/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://murf.ai/api/docs/_mcp/server.

Murf provides dedicated request capacity based on your plan. Each plan includes specific limits for concurrency and WebSocket connections. As your application scales, you can upgrade your plan to increase capacity.

Below is a summary of the concurrent TTS request limits for each plan:

| Model    | Free tier                                           | Pay as you go                                       | Enterprise                                  |
| -------- | --------------------------------------------------- | --------------------------------------------------- | ------------------------------------------- |
| Falcon 2 | 5 for US-East;  2 for global and regional endpoints | 5 for US-East;  2 for global and regional endpoints | Custom Support Upto 10,000 concurrent calls |
| Gen2     | 5                                                   | 5                                                   | Custom support                              |

### Concurrency for Non-Streaming requests

Concurrency refers to the maximum number of generation requests that can be processed simultaneously. For all non-streaming endpoints, this is defined as the number of active requests at any given time.

### Concurrency for Streaming requests

Our TTS API supports streaming via both HTTP and WebSocket connections. Concurrency for streaming is defined by the number of unique context IDs active at a given time:

1. HTTP Streaming: Each request is treated as a unique context ID and counts toward your concurrency limit.
2. WebSocket Streaming: Each unique context ID also counts toward your concurrency limit. Thus, when additional requests are sent with the same context\_id, it does not increase your concurrency usage. This is because requests to the same context are processed sequentially. If no context ID is provided for request with websocket connection, we create null context ID and count it towards one concurrency.

If the number of active contexts exceeds your concurrency limit, new context IDs will be rejected, and an error message will be returned.

### WebSocket Limits

Two limits apply to WebSocket usage. They are counted separately: open connections do not consume or increase streaming concurrency.

| Limit                 | What it counts                                         | Your plan | Example (`N = 5`) |
| --------------------- | ------------------------------------------------------ | --------- | ----------------- |
| Streaming concurrency | Context IDs actively generating audio at the same time | `N`       | 5                 |
| WebSocket connections | Sockets open at the same time, whether idle or active  | `10 × N`  | 50                |

An open socket does not consume concurrency. Concurrency is consumed only while audio is being generated on that socket.

The number of sessions that can generate audio at the same time is capped by your streaming concurrency—not by your connection count. The larger connection allowance lets you keep sockets open and avoid a new handshake for every call; it does not increase throughput.

* A WebSocket connection closes automatically after 3 minutes of inactivity.
* If you attempt to open a new WebSocket connection after exceeding your limit, an error will be returned.

## Why These Limits Matter

The limits are designed to maintain system performance and ensure a consistent experience for all users. By adhering to the limits and following best practices, you can integrate the Murf API smoothly and efficiently into your applications.
If you have additional questions or need guidance on managing API limits, please drop a message in [our discord channel](https://discord.gg/FQVzyvqaVg) or contact our support team.