Pools: using your keys together
A named group of keys that a flow runs through — spreading a batch across all of them, stepping around one that is cooling down, and never exposing a key to the person building.
In this article (5)
A pool is the thing a flow actually points at: "run this step on the Gemini pool". It is a named group of keys for one provider, and it is where FlowArray's parallelism comes from.
Creating one
Pools → name, provider, strategy, then add keys to it. A key can be in more than one pool. Builders then pick the pool by name on any AI step and never handle a key.
Strategies
| Strategy | Behaviour |
|---|---|
| Least busy first (default) | Each request goes to whichever key has the most free capacity right now |
| Rotate evenly | Take turns across the keys |
| Weighted | Favour keys with a higher weight |
| Priority order | Use higher-priority keys first |
| Backup only | Use a backup only when the primary is unavailable |
Least busy is the right default and the one that makes a big batch finish fastest. Priority and backup are for "use the cheap account first" and "keep this key for emergencies".
What the pool does for you during a run
- Spreads items across every enabled key at once, which is why forty images take about as long as the slowest few.
- Holds work back before it becomes an error, using each key's requests-per-minute and parallel settings.
- Steps aside a key that is cooling down (a provider asked it to wait) or has hit its own allowance, and keeps serving from the rest. One busy key never stops the flow.
- Honours the provider's own retry timing when one is sent, rather than guessing a cooldown.
You can see all of this happening in the run monitor, which draws a lane per key.
What pools are not
Pools aggregate capacity you legitimately have — several of your own organisations or projects, a client's own key that they asked you to use, a second account you genuinely hold. That is the honest framing and the only one FlowArray supports.
They are not a way around a provider's rate limits, and more keys does not reliably mean more throughput: where a provider meters per organisation or per project (OpenAI per org, Gemini per project), two keys from the same account share one limit. Tell FlowArray about that with the Shared account field and it will stop assuming capacity you do not have.
Keeping spend bounded
Set a Daily spend cap on the pool itself (here), a per-key cap on the API keys page, and the workspace-wide ceiling in spend limits — whichever is reached first applies. A key that has spent its own allowance steps aside and the pool keeps serving from the others.