Choose models for Subagents

A subagent is a helper agent DataMind Oda starts while it works on a task. By default, a subagent uses configured defaults or inherits the model of the chat that started it; model selection lets Oda choose a different provider, model and reasoning effort for a subagent, from a list of models you authorise. See Subagents for what subagents are and how Oda starts them.

Turn model selection on

The switch is the Model selection section of the Subagent card: on the Plugins page, open Subagent in the Official group, and find Model selection beside Limits. The card is a developer surface, so it appears while Developer tools are on; Subagent settings covers the Limits section and the other place the limits live.

1. In Model selection, turn on Allow agents to choose models for Subagents.
2. In Models agents may choose, select the models to allow.
3. Choose Save. Nothing is written before you save.

The switch is off by default, and the list of allowed models starts empty. Turning it on or off only changes a draft, and the text under the switch follows its state:

• While it is on: When enabled, agents can choose a provider, model, and reasoning effort for each Subagent from the authorized models below. Applies only to new sessions.
• While it is off: Subagents use configured defaults or inherit the parent agent's model. Saved model choices are retained.

An enabled switch must name at least one model: with nothing selected, the section reads Select at least one model before saving. and the card cannot save the change. A setting that still arrives enabled with an empty list is refused with enabled subagent model selection requires at least one allowed model.

Choose the models agents may use

Models agents may choose lists the model routes this deployment offers, grouped by vendor. Each row names a provider and a model that a Subagent may use.

• Select the rows you want to allow. A vendor group carries a switch, Allow all {vendor} models, that selects every model of that vendor at once, and clears them together again when switched off.
• Search models filters a long list; when nothing matches, the list reads No model matches your search.
• While the list loads, it reads Loading models…. If it cannot be read, the card offers Retry.

Models in your saved list that the catalogue no longer offers stay listed: they are marked Currently unavailable and you can still remove them. A saved list is kept even while the switch is off. The providers themselves are managed in Settings > Models; see Set up models and providers.

Save your changes

The card has one Save for both sections, Model selection and Limits. Each section is written only when you changed it, and the sections save on their own, so a refusal in one does not cancel the other. While a save runs, the button reads Saving… and the card's controls lock until it settles. An edit stays a draft until you save it, and leaving the card drops what you did not save.

Messages on the settings card

Which chats the choice applies to

• A chat decides when it starts. A chat reads the setting as it starts; when the setting is on, the allowed models are recorded for the chat before its first request, and the chat works from that record from then on.
• Later edits do not change chats that already exist. Changing the setting affects only chats that start afterwards.
• A chat restored from earlier keeps its past decision. A chat restored without a recorded decision stays without model selection, even when the setting is on now.
• A subagent takes the decision of the chat that started it.

Choosing a model also needs a delegation backend that accepts per-child options. A backend that does not keeps its fixed route; Choosing and enabling a delegation backend compares them.

How Oda looks up the routes it may use

While a delegation tool in the chat has model selection on, Oda can read the routes it may use with list_subagent_models. A lookup changes nothing about the chat; it only lists what is available, always trimmed to what the chat allows.

• Called with no arguments, it lists the providers inside the chat's allowed list, one per line: <provider-id> - <name>.
• Called with provider, it lists that provider's advertised models: <provider>/<model-id> - <name>, with a description after a colon when the model has one.
• Called with provider and model, it lists that model's reasoning efforts, with the default marked (default).

When there is nothing to show, the lookup says so:

• (no LLM providers): no provider is inside the chat's allowed list.
• (no advertised models for <provider>): the provider advertises no models.
• (no advertised reasoning efforts): that model offers no reasoning efforts.

A provider outside the chat's allowed list is refused before it is looked up (LLM provider "<id>" is not allowed for this Session) and never appears among the alternatives. The list is a guide, not a gate: a model a provider does not advertise can still work when the route is one Oda can serve. A lookup with a mistake is refused too: a model named without its provider (`model` requires `provider`), a provider named as a blank string (`provider` must be non-empty), or a provider Oda does not know (LLM provider "<id>" is not registered; available providers: <list>).

How the model and effort are chosen

A delegation names its choice with three fields: provider, model and reasoning_effort. The call itself is described in Delegating work to subagents.

• Provider and model travel together. A call that names one without the other is refused with child LLM `provider` and `model` must be supplied together.
• The effort stays optional. A blank effort is refused with child LLM `reasoning_effort` must be non-empty. An effort on its own works only when the model is already decided for the call.
• Every choice must resolve to an allowed route. A route outside the chat's allowed list is refused with child LLM route "<provider>/<model>" is not allowed for this Session before any subagent starts, and a route Oda cannot serve fails the delegation.
• Model selection off. The fields are not offered, and a call that still names a choice is refused with child model selection is disabled for this tool instance.
• What a subagent inherits. A subagent inherits the latest model call of the chat that started it: provider, model and effort. A route configured for the delegation tool is the fallback. When Oda chooses a different model but names no effort, the inherited effort is cleared, so the new model resolves its own default.
• Other per-child options. Where the backend accepts per-child options, a delegation can also set the child's token budget, its tool access and its persona.

Choosing the model for the chat itself is covered in Chat with Oda.

Questions, answered

Where do I turn model selection on?

On the Plugins page: open Subagent in the Official group and turn on Allow agents to choose models for Subagents in Model selection. It is off by default, the card appears while Developer tools are on, and an enabled switch must name at least one model.

Which models may a subagent use?

The models on the allowed list recorded for its chat. Oda can look them up with list_subagent_models, and the lookup is trimmed to what the chat allows; Oda chooses only from those routes.

Can I authorise a whole vendor at once?

Yes. Each vendor group carries a switch, Allow all {vendor} models, that selects every model of that vendor together; switching it off clears them together again.

Does turning it on change my existing chats?

No. Each chat keeps the decision it started with: the setting is read when a chat starts, and later edits affect only chats that start afterwards. A chat restored without a recorded decision stays without model selection. A subagent takes the decision of the chat that started it.

Why was a model choice refused?

Model selection may be off (child model selection is disabled for this tool instance), the route may be outside the chat's allowed list (child LLM route "<provider>/<model>" is not allowed for this Session), or the choice may name only half of the route (child LLM `provider` and `model` must be supplied together). A blank effort is refused too.

Why did the reasoning effort reset when the model changed?

When Oda chooses a different model for a subagent and no effort is chosen together with it, the inherited reasoning effort is cleared, so the new model resolves its own default. Name an effort together with the model to keep a specific one.

Can a delegation name only the reasoning effort?

Yes, as long as a model is already decided for the call: the chat's own model, a route configured for the delegation tool, or the provider's own default.

What if the lookup finds nothing?

(no LLM providers) means no provider is inside the chat's allowed list; (no advertised models for <provider>) means that provider advertises no models; (no advertised reasoning efforts) means that model offers no reasoning efforts.

Why is a model shown as Currently unavailable?

It is a model in your saved list that the catalogue does not offer right now. The card keeps it listed so your choice is not lost, and you can remove it at any time.

What happens to my saved models if I turn the switch off?

They are kept: Subagents use configured defaults or inherit the parent agent's model. Saved model choices are retained. Turn it on again and the same models are there.

Models could not be loaded. What can I do?

Choose Retry. When only part of the catalogue fails, the card says Some model providers could not be loaded; saved choices remain removable., and the models that did load stay selectable. If it keeps failing, ask your administrator.

Which delegation backends support choosing a model?

Those that accept per-child options; a backend that does not keeps its fixed route. Choosing and enabling a delegation backend compares them.