Enable warm reasoners

Warm reasoners keep pre-provisioned logic reasoners ready so matching create or resume requests can start faster when warm capacity is available. Use this guide when startup latency is the main problem for logic reasoners and you want faster startup by keeping warm capacity ready, while accepting the additional cost of keeping it active.

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 app_admin application role.

When to use warm reasoners

Warm reasoners are the right setting when startup latency is the main problem for a logic reasoner. If a request needs a logic reasoner size with matching warm capacity available, the app can assign that warm instance instead of provisioning a new reasoner from scratch, so startup can be faster.

Use warm reasoners when all of the following are true:

the workload is latency-sensitive at startup
the workload uses logic reasoners
the problem is startup readiness, not sustained concurrency
you accept the additional cost of keeping warm capacity active

Warm reasoners are a preview feature. Only logic reasoners are supported today, so prescriptive workloads, predictive workloads, and CDC are out of scope.

Warm reasoners are also different from a non-suspending reasoner:

A non-suspending reasoner keeps the same named reasoner running.
A warm reasoner only affects startup. After assignment, the reasoner follows the requested settings, including its normal auto-suspend behavior.

Warm reasoners consume compute while they remain active, even when no request is using them. They improve readiness, but they do not increase the maximum number of same-size reasoners that can run concurrently.

If one warm reasoner is assigned, the app provisions a replacement to keep the configured warm count available. That replacement can still take time to come online, so provisioning can still be slower for later requests in a burst after the existing warm capacity is consumed.

Enable a warm reasoner

Requires the app_admin application role.

Start with one warm reasoner for the logic size with the worst startup latency. This tells the app to keep matching warm capacity ready for that size:

CALL relationalai.app.enable_warm_reasoner('logic', 'HIGHMEM_X64_S');

The procedure result confirms that the app accepted the warm-reasoner configuration change for that type and size. Treat that result as confirmation of the setting change, not as proof that the warm capacity is already READY.

Set the warm reasoner count

Requires the app_admin application role.

If one warm reasoner is not enough for a given size, set the exact number of warm reasoners to keep running.

CALL relationalai.app.set_warm_reasoners('logic', 'HIGHMEM_X64_S', 2);

Use this to increase or decrease the warm count for a size. Set the count based on the number of concurrent cold starts you want to absorb, not on the total number of running logic reasoners you need during steady-state work.

The procedure result confirms the new target count. It does not mean that every requested warm reasoner is already READY, because replacement capacity may still be provisioning.

Disable warm reasoners

Requires the app_admin application role.

Disable warm reasoners when you want to remove always-on warm capacity and accept slower cold starts in exchange for lower ongoing compute usage.

CALL relationalai.app.disable_warm_reasoner('logic', 'HIGHMEM_X64_S');

You can also set the warm count to 0 with app.set_warm_reasoners(), but disable_warm_reasoner() is the clearest removal workflow.

Once warm reasoners are disabled, the next create or resume for that size may need to wait for normal provisioning again.