Model configuration

LLMs are configured at two levels: the Master Orchestrator (MO), which governs the whole bot, and individual AOPs, which can either inherit the MO's model or override it. This page covers both.

---

Watch the tutorial

---

Master Orchestrator Model

Selects the LLM that powers the Master Orchestrator — the model used to interpret user queries, route them, and generate responses. This configuration is also inherited by every AOP on the bot unless an AOP is given its own model.

Choosing a model: The picker is organised provider-first. Select a provider, then a model:

The default configuration is OpenAI — GPT 5.5. Use the Compare models link in the picker header to view benchmarking data before deciding.

Model settings:

• Effort — Controls how thoroughly the model thinks before responding (Low / Medium / High). Higher effort improves reasoning quality on complex requests at the cost of response time. Default: Low.
• Priority processing — Runs requests through a priority lane for faster, more consistent response times. Available on supported models only and Off by default where supported.

How it works:

• Changes apply on save and take effect from the next user request.
• AOPs inherit this configuration live — changing the model here immediately changes the model every inheriting AOP runs on. AOPs with their own model override are unaffected.
• Run History and the Debugging Console record the resolved provider and model for every run, so you can always trace which model handled a request.

---

AOP Model

Selects the LLM this AOP runs on — the model used to follow the AOP's instructions, make decisions, call tools, and generate responses during execution. Every AOP resolves to a model in one of two ways: inheriting from the Master Orchestrator, or holding its own.

Inherited from Master Orchestrator (default)

By default, the AOP uses the Master Orchestrator's model configuration and follows it live — if an admin changes the Master Orchestrator's model, every inheriting AOP switches with it, with no action needed on the AOP. The picker shows the currently inherited configuration (e.g., "GPT 5.5 · OpenAI — Inherited from MO") so you always know which model the AOP will actually run on.

Inheritance is the right choice for most AOPs: it keeps model management in one place and ensures consistent behaviour across the bot.

Or choose a specific model (override)

Override the inherited model when this AOP has different cost, speed, or reasoning needs than the rest of the bot — for example, a simple acknowledgement AOP that doesn't need a heavyweight model, or a complex multi-step decision flow that benefits from deeper reasoning.

The picker is organised provider-first. Select a provider, then a model:

An overriding AOP stores its own full configuration (provider, model, and model settings) and is unaffected by Master Orchestrator changes. Re-selecting the inherited option at the top of the picker returns the AOP to live inheritance.

Use the Compare models link in the picker header to view benchmarking data before deciding.

Model settings:

• Effort — Controls how thoroughly the model thinks before responding (Low / Medium / High). Higher effort improves reasoning quality on complex, multi-step AOPs at the cost of response time.
• Priority processing — Runs requests through a priority lane for faster, more consistent response times. Available on supported models only and On by default where supported.

How it works:

• Changes apply on save and take effect from the AOP's next run — in-flight runs are not affected.
• Run History and the Debugging Console record the resolved provider and model for every run (marked as inherited where applicable), so you can always trace which model handled a request.
• Existing AOPs default to inheriting the Master Orchestrator's configuration; nothing changes until you explicitly override.