Scale reasoner capacity

Use this page when you need to change the compute pools that host reasoners rather than manage one named reasoner directly. Use it to raise the shared concurrency ceiling for a reasoner size or to reserve always-ready capacity for lower provisioning latency.

The RAI Native App is installed and usable in your Snowflake account.
You can run SQL in Snowflake with an active warehouse.
You have the eng_admin application role.

When to scale reasoner capacity

This page is about the app-managed compute pools that host reasoners. It does not resize one named reasoner. Instead, it changes the shared pool limits for a reasoner type and size.

Use compute-pool scaling when you need to change how many same-size reasoners can run at once or how much capacity stays reserved in advance.

Setting	What it controls	Use it when
`MAX_NODES`	The maximum number of nodes available for that reasoner type and size. One node corresponds to capacity for one running reasoner.	More reasoners of the same size need to run concurrently.
`MIN_NODES`	The minimum number of nodes that stay reserved and always ready.	You want lower provisioning latency for that pool and can accept the extra cost of idle reserved capacity.

Choose this page when the bottleneck is shared capacity for one type and size. If the problem is startup visibility or queueing and you have not confirmed the cause yet, start with Monitor reasoner usage. If you actually need a different size for one named reasoner, recreate that reasoner through the relevant type-specific management workflow instead.

Increase the maximum number of reasoners

Requires the eng_admin application role.

Raise MAX_NODES when the pool needs to support more same-size reasoners at the same time.

CALL relationalai.api.alter_reasoner_pool_node_limits('logic', 'HIGHMEM_X64_S', NULL, 12);

This example raises the concurrency ceiling for HIGHMEM_X64_S logic reasoners to 12 without changing the current MIN_NODES setting.

If starting another reasoner would exceed the pool’s maximum capacity, the request fails instead of waiting for capacity. Use this change when concurrency is the real bottleneck.

Raising MAX_NODES does not keep extra capacity warm by itself.
If more reasoners actually run after the change, spend can increase.

Reserve capacity for lower provisioning latency

Requires the eng_admin application role.

Set MIN_NODES when you want some capacity to stay reserved and always ready for a reasoner type and size. This improves readiness for that shared pool, but reserved nodes are billed even when idle.

CALL relationalai.api.alter_reasoner_pool_node_limits('logic', 'HIGHMEM_X64_M', 2, 12);

This example reserves capacity for at least two HIGHMEM_X64_M logic reasoners and allows up to 12 to run concurrently.

Reserved nodes help when normal provisioning latency is the problem for that pool. They do not fix queueing inside one busy reasoner, and they are broader than warm reasoners because they reserve compute-pool capacity rather than pre-provisioning warm logic instances.