Manage prescriptive reasoners

Prescriptive reasoners run the decision-problem and optimization workflows behind PyRel prescriptive reasoning. This guide explains how prescriptive reasoners are created, how to inspect and manage them, and how to interpret nearby docs that still use solver terminology.

Before you start, make sure that:

• The RAI Native App is installed and usable in your Snowflake account.
• You can run SQL in Snowflake with an active warehouse.

What prescriptive reasoners do

Prescriptive workflows need a prescriptive reasoner. Prescriptive reasoners run decision-problem and optimization workloads rather than normal semantic-model queries.

By default, each user gets a dedicated prescriptive reasoner. When a user runs a prescriptive workflow, PyRel uses the configured prescriptive reasoner, resumes it if it is suspended, or creates it if it does not exist.

Some existing docs still describe these workloads as solver workloads or solver reasoners. On public configuration and reasoner-management surfaces, the supported reasoner type and config field are prescriptive.

Which compute pools host prescriptive reasoners

Prescriptive reasoners run in app-managed compute pools. You do not create or manage these pools directly, but you do choose prescriptive reasoner sizes that map to them.

Compute pool	Size	Supported cloud platforms	Used for
RELATIONAL_AI_HIGHMEM_X64_S	HIGHMEM_X64_S	AWS, Azure	Small prescriptive workloads and the default prescriptive reasoner size.
RELATIONAL_AI_HIGHMEM_X64_M	HIGHMEM_X64_M	AWS, Azure	Medium prescriptive workloads.

How prescriptive reasoners are created

PyRel creates prescriptive reasoners automatically. Users can configure the name and size of the prescriptive reasoner that PyRel creates for them.

When a user runs a prescriptive workflow that needs a prescriptive reasoner:

• PyRel checks whether the configured reasoner exists and is READY.
• If it is READY, PyRel sends the solve workload to that reasoner.
• If it exists but is not READY, PyRel resumes it and waits for it to become READY.
• If it does not exist, PyRel creates it using the configured size, or HIGHMEM_X64_S if no size is configured.

The default prescriptive reasoner settings are:

Setting	Behavior
Size	Defaults to HIGHMEM_X64_S when PyRel creates a prescriptive reasoner and you do not set a different value.
Auto-suspend	Defaults to 60 minutes of inactivity for newly created reasoners when you do not set a different value.

Related resources:

• Configure prescriptive reasoner settings
• Solve a decision problem

How prescriptive reasoners handle jobs

Prescriptive reasoners handle prescriptive problem solving jobs rather than normal query jobs. Although a prescriptive reasoner can process more than one solve job at a time, concurrent solve jobs on the same reasoner may affect each other’s performance.

If performance issues arise, start by checking which jobs are queued or running on that reasoner before you change lifecycle settings using the APIs on this page.

Related resources:

• Manage reasoner jobs
• Scale reasoner capacity

How prescriptive reasoners are managed

Prescriptive reasoners are fully managed by PyRel, including creating them if a prescriptive workflow needs one. By default, each PyRel user gets a dedicated prescriptive reasoner.

As an admin, you can perform the following actions on prescriptive reasoners:

What to do	When to do it
View all prescriptive reasoners	When you want to confirm that a prescriptive reasoner exists and see its high-level state.
Verify that a prescriptive reasoner is ready	When you want to confirm that one specific prescriptive reasoner is usable with its expected size and settings.
Change a prescriptive reasoner’s auto-suspend settings	When you want to trade off lower cost against lower startup latency.
Manually suspend a prescriptive reasoner	When you want to stop it from consuming compute while it is not needed. Jobs sent to a suspended prescriptive reasoner fail until the reasoner is resumed again.
Manually resume a suspended prescriptive reasoner	When you need it available before the next solve or when you want to confirm that the reasoner itself can start normally.
Delete a prescriptive reasoner	When you no longer want to keep that reasoner instance or its current configuration. Deletion is stronger than suspension because it removes the reasoner entirely.

View all prescriptive reasoners

Requires the eng_user application role.

Use the list view when you want to confirm that a prescriptive reasoner exists and see its current lifecycle state.

SELECT *
FROM relationalai.api.reasoners
WHERE TYPE = 'prescriptive';

Start with NAME, SIZE, STATUS, AUTO_SUSPEND_MINS, and SUSPENDS_AT. Those columns usually tell you whether the reasoner is ready to use, scheduled to suspend, or worth inspecting in more detail.

Verify that a prescriptive reasoner is ready

Requires the eng_user application role.

Use the detail view when you want to confirm that one specific prescriptive reasoner is usable with its expected size and settings.

CALL relationalai.api.get_reasoner('prescriptive', 'my_reasoner');

Confirm the following fields first:

• STATUS = READY
• SIZE matches the expected prescriptive reasoner size
• AUTO_SUSPEND_MINS matches the current inactivity setting
• RUNTIME.compute_pool matches the expected high-memory pool

If the reasoner exists but is not yet READY, wait for provisioning to complete and check again. If it remains unavailable, continue with the troubleshooting section on this page.

Change a prescriptive reasoner’s auto-suspend settings

Requires the eng_admin application role.

Prescriptive reasoners can be configured to automatically suspend after a period of inactivity, which can help reduce costs when prescriptive workloads are infrequent. By default, newly created prescriptive reasoners suspend after 60 minutes of inactivity unless you set a different value, but you can change this setting based on your workload patterns.

Execute the following to change the auto-suspend timer for a prescriptive reasoner named my_reasoner to 30 minutes:

CALL relationalai.api.alter_reasoner_auto_suspend_mins('prescriptive', 'my_reasoner', 30);

Set the value to 0 to disable auto-suspension.

Manually suspend a prescriptive reasoner

Requires the eng_admin application role.

If you need to suspend a prescriptive reasoner immediately, rather than waiting for the auto-suspend timer, you can do so manually.

Run the following to suspend a prescriptive reasoner named my_reasoner:

CALL relationalai.api.suspend_reasoner('prescriptive', 'my_reasoner');

Use get_reasoner() to check the reasoner’s status and confirm that it has suspended successfully.

Manually resume a suspended prescriptive reasoner

Requires the eng_admin application role.

PyRel will automatically resume a prescriptive reasoner when it needs to run a prescriptive workflow, but you can also resume it manually if you want it available immediately.

Run the following to resume a prescriptive reasoner named my_reasoner:

CALL relationalai.api.resume_reasoner_async('prescriptive', 'my_reasoner');

It may take a few minutes for the reasoner to start up and become READY again. Use get_reasoner() to check the reasoner’s status and confirm that it has resumed successfully.

Delete a prescriptive reasoner

Requires the eng_admin application role.

Delete a prescriptive reasoner when you no longer want to keep that reasoner instance or its current configuration. Deletion is stronger than suspension because it removes the reasoner entirely.

CALL relationalai.api.delete_reasoner('prescriptive', 'my_reasoner');

When a reasoner is deleted, all current and queued solve jobs are cancelled. If PyRel is still configured to use that reasoner name, it can recreate the reasoner later when needed.

Troubleshoot common issues with prescriptive reasoners

Use this table to match common prescriptive-reasoner problems to the right next action:

Symptom	Likely cause	What to do next
The expected prescriptive reasoner does not exist.	PyRel has not needed it yet, or the configured name does not match the reasoner you expected.	Confirm the current reasoners.prescriptive configuration, then trigger the workflow that should use it or create the reasoner manually.
The reasoner exists but is not READY.	Provisioning is still in progress, or startup has stalled.	Wait briefly and run get_reasoner() again. If it does not recover, check broader app status.
A solve workflow refers to a solver reasoner, but management docs say prescriptive.	The same public workload family is described with older solver terminology in some places.	Follow the public prescriptive config keys and reasoner-management APIs on this page.
The prescriptive reasoner resumes slowly even though nothing is wrong.	The reasoner is auto-suspended and needs to start again.	Increase AUTO_SUSPEND_MINS if startup latency is the main problem.
Solve work backs up even though the reasoner is READY.	The bottleneck is likely queueing or capacity rather than reasoner lifecycle state.	Use Monitor reasoner usage and Scale reasoner capacity before changing reasoner lifecycle settings again.