
One of the cool things about the Possible Studio is that it is workflow driven, making it easy for us to integrate with emerging AI capabilities. However working with these cutting edge platforms also means having to manage different kinds of rate limits.

Here is a simple example flow:
1. User writes a story that has 40 *shots*, and makes edits to some *shots*  
2. User then presses “Play *movie*”  
3. The app fires APIs to generate text-to-speech via ElevenLabs for up to 40 *shots* at the same time, which hits their rate limit & causes downstream failures  
4. User is unable to play the movie

![](/blog/media/provider-limits-1.png)

We could throttle “Play movie” to only sequence *shots* up to the ElevenLabs rate limit, but that is inefficient for a couple of reasons:
* Multiple users might be attempting to generate text-to-speech simultaneously, this approach wouldn’t account for their usage  
* There are multiple providers in this workflow, each with their own rate limits, so we would have to limit “create *shot*” concurrency to the lowest rate limit

This is where [ARTISAN](https://www.thepossible.io/blog/posts/realtime-collaboration) comes in. Just like **render artisans** are used in render workflows, we use **gen artisans** in generation workflows. Quick recap of what they are:
* Used in APIs that make calls to 3rd party providers such as Luma Dream Machine image-to-video gen or Eleven Labs text-to-speech gen  
* Handles queuing jobs to the same 3rd party provider so we don’t exceed each provider’s concurrency limits

Now, using a **gen artisan** in our example flow:
1. User writes a story that has 40 *shots*, and makes edits to some *shots*  
2. User then presses “Play *movie*”  
3. The app fires APIs to generate text-to-speech via ElevenLabs for up to 40 *shots* at the same time  
4. Each API uses its **gen artisan** to check if it is allowed to kick off a text-to-speech generation  
5. ARTISAN is provider aware, and checks each **gen artisan** against individual provider limits (these can also be set at the environment level)  
6. If the provider rate limit is reached, the API is subscribed to find out when the queue frees up, and waits quietly  
7. The API is notified when the queue frees up and is able to complete its text-to-speech generation

![](/blog/media/provider-limits-2.png)

While this approach protects against failures, it can increase latency for stories with many shots. To counteract this, we “gen as we go” as much as possible, which allows us to leverage caches to reduce latency.

Managing 3rd Party Provider Limits