Enable warm reasoners

Warm reasoners are pre-provisioned logic reasoners kept ready to reduce create and resume latency. Use this guide when startup latency is the main problem for logic reasoners and you want the app to keep one or more warm instances ready in advance.

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 reduce create and resume latency. If a user requests a logic reasoner of a size that already has warm capacity available, the app can assign that warm instance instead of provisioning a new reasoner from scratch.

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

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. 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 warm reasoners reduce startup latency but do not guarantee zero wait time.

Enable a warm reasoner

Requires the app_admin application role.

Start with one warm reasoner for the logic size that has the worst startup latency.

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 replacement warm capacity is already finished provisioning.

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.