Subagent profiles (Model Routing)

0. Before you start

What are subagent profiles?

When the agent works on a big task, it can hand part of the work to subagents — built-in ones (for example, Code, Ask, Test, Review, Plan, Debug or General) and custom ones. By default, a subagent runs on the same model as the main (parent) agent.

Subagent profiles (the Model Routing feature) let you pre-define a set of named profiles — fast, balanced, strong, for example — and pin each one to a specific model and reasoning parameters. The main agent then picks the right profile for each subtask by its text description.

A profile consists of:

• an alias — a short name the main agent uses to refer to the profile;
• a description — a plain-language instruction telling when to use the profile;
• (optional) a specific provider model the profile is pinned to;
• (optional) a reasoning level for that model.

If a profile has no model set, it inherits the parent agent's model.

A profile can be passed to any regular subagent, including a custom one. Model Routing is not supported for MCP-backed subagents.

Why you need it

Profiles solve a common problem: different subtasks justify different models.

• A cheap, fast model — for simple code search, reading files, short answers.
• A balanced model — for routine analysis and test generation.
• The most powerful (and most expensive) model — for complex architecture, non-trivial edits, deep review and hard debugging.

The profile description defines the selection rule for the main agent. The pinned model and reasoning level define the request parameters once the agent has chosen that profile.

Built-in profiles

Three default profiles ship with the system (fast, balanced, strong). You can't delete them, but you can edit them (assign a model, change the description).

Profile	Default purpose
fast	Lightweight read-only search, file reading, summarization, simple codebase exploration.
balanced	Ordinary analysis, medium-complexity Q&A, routine test generation, typical implementation support.
strong	Complex architecture analysis, non-trivial code edits, hard debugging and deep review.

By default, built-in profiles have no model assigned — they inherit the parent agent's model (Inherit parent). To make the profiles start routing requests to different models, pin concrete models to them.

Besides the built-in ones, you can create custom profiles with any alias you like (for example, second-reviewer or planner).

1. Configuring profiles in Settings

Profiles are configured in Settings → Tools → Explyt → Model Routing.

Scope

At the top of the window you pick the scope the profiles belong to:

• Global — use it for personal profiles that should be available in every project on this machine. Select Global, configure the profiles and click Apply.
• Project — use it for the routing rules of a specific repository, for example when the team needs identical profile names and pinned models. Select Project, configure the full set of profiles you need, click Apply and, if necessary, add .explyt/model-routing.yaml to VCS.

The project configuration does not extend the global one: if the project file exists, it replaces the global one entirely. That is why in Project scope you also have to repeat any personal profiles you need in that project.

Profile table

The Profiles section shows a table with three columns:

• Alias — the profile alias;
• Description — the description (when to use the profile);
• Model — the pinned model and reasoning level, or Inherit parent if no model is set.

Add and edit profile dialog

To add a profile, click Add profile; to edit one, click Edit profile (or double-click the row); to delete one, click Remove profile.

The dialog has the fields Alias, Description, Mode, Model and Reasoning.

For example, you can create an image-to-text profile, describe when the main agent should use it, and pin it to a model with vision support:

2. Profile fields

Alias

The short profile name the main agent uses to reference it.

• Must match [a-z][a-z0-9-]* — lowercase Latin letters, digits and hyphens, starting with a letter (for example, fast, gpt-5, reviewer).
• Must be unique within the scope.
• The alias of a built-in profile cannot be changed.

Description

A plain-language instruction describing when the main agent should pick this profile. This field directly affects routing: the main agent chooses a profile precisely by its description.

• Cannot be empty.
• Write it as a short usage-scenario instruction, for example: "Use for lightweight read-only lookup and file reading."

Tip: if you temporarily need to steer the agent away from a built-in profile that cannot be deleted, give it a description such as "never use it".

Mode: Inherit parent and Model

The Mode field defines how the profile picks a model:

• Inherit parent — use it when the profile should describe a type of subtask but must not change the parent agent's model. Select Inherit parent, fill in Description and save the profile; the Model and Reasoning fields stay inactive.
• Model — use it when the subtask has to be routed to a pre-selected model, for example to verify a result independently with another model. Select Model, then the model and an available Reasoning level, and save the profile.

Reasoning

The Reasoning field sets the requested reasoning level for the pinned model. It is available only in Model mode. Support for the levels and their actual behavior depend on the model and the provider.

• Default — use it when you want to leave the level choice to the model or the provider. Select Default and save the profile.
• None — use it for a simple subtask that needs no separate reasoning, for example a literal search or data extraction. Select None and save the profile.
• Low — use it for a short analysis with only a few steps, for example an initial file classification. Select Low and save the profile.
• Medium — use it for an ordinary subtask where you need to weigh several facts or implementation options. Select Medium and save the profile.
• High — use it for a complex subtask with several dependencies or hypotheses, for example analyzing an architectural change. Select High and save the profile.
• XHigh — use it for a rare, especially complex subtask, if the selected model supports this level. Select XHigh and save the profile.

Choosing a higher value does not guarantee a better result by itself. Check whether the level is available for the selected model and evaluate the result on your own task.

3. The model-routing.yaml file

Profiles are stored in the model-routing.yaml YAML file:

• project-level — .explyt/model-routing.yaml in the project root;
• global — ~/.explyt/model-routing.yaml.

The project file replaces the global one entirely. Profiles from the two files are not merged by alias, so add every profile the project needs to the project file.

Current file contract

The format has no separate version field. Below is the contract that the current Explyt parser uses. The provider and model values in the example are placeholders: for a working configuration, use the identifiers from the file saved through Settings.

profiles:
  fast:
    description: "Use for lightweight read-only lookup and file reading."
  balanced:
    description: "Use for regular analysis and common implementation support."
    provider: "OpenAI"
    model: "gpt-5"
    reasoning: "medium"
  strong:
    description: "Use for complex architecture and deep review."
    provider: "Anthropic"
    model: "claude-sonnet-4"
    reasoning: "high"
  second-reviewer:
    description: "Use for an independent second review."

Key	Type	Requirements and constraints
profiles	object: alias → profile	A file managed by Explyt must contain fast, balanced and strong
description	string	Required and must not be empty after trimming surrounding whitespace
provider	string	Optional; set only together with model, whitespace inside the value is not allowed
model	string	Optional; set only together with provider, whitespace inside the value is not allowed
reasoning	string	Allowed only together with provider and model; values: default, none, low, medium, high, xhigh, case-insensitive

The alias must match [a-z][a-z0-9-]*. Unknown keys are treated as a structural error. If provider and model are absent, the profile inherits the parent agent's model. Take the model and provider identifier values from the file saved through Settings: the name shown in the interface does not always match the value in the YAML.

Common errors

Error in the file	What the validator reports
description: ""	the profile description must not be empty
alias Second Reviewer	the alias does not match [a-z][a-z0-9-]*
model set without provider	provider is required when model is set
provider set without model	model is required when provider is set
reasoning: extreme	only the listed reasoning levels are allowed
reasoning without a model	reasoning is allowed only together with provider and model
fast, balanced or strong missing	the configuration must define the missing built-in profile
a YAML key is repeated	duplicate key syntax error

Errors contain the field path, and for syntax and structural errors they may also contain the line and column. A profile with an error does not enter the available registry. Fix the file and wait for the automatic reload, or save it through Settings.

4. Recommendations

• Start by pinning models to the built-in fast/balanced/strong — that alone is enough for the main agent to route subtasks to different models.
• Write descriptions as clear selection rules: the main agent relies on exactly those. The more specific the scenario ("read-only", "test generation", "deep review"), the more accurate the routing.
• Use the Project scope and commit model-routing.yaml to the repository so the team works with the same routing rules.
• If models differ in limits or pricing, take that into account when assigning profiles and check the actual spend in your provider configuration.
• If a profile is temporarily not needed but cannot be deleted (a built-in one), switch it to Inherit parent mode or describe it as undesirable to invoke.

Use cases

Cross-model consensus: one task, three models in parallel

On a hard task, it helps to run the same job with several agents on different models and then compare the results: the models compensate for each other's weak spots. You get a "consensus" where several models independently solve the task and arrive at a shared conclusion.

Setup:

1. Create three profiles, for example gpt, opus and glm, and pin a different provider model to each. The names are arbitrary — pick whatever you like.
2. Make the descriptions general enough that the main agent can route the same subtask to each profile.

Working mode. Run the main agent in Orchestrator mode: it does not edit files itself but distributes subtasks to subagents, which suits coordinating three models. General also works if the task might grow and you want the main agent to do part of the work itself. Run the subagents in Code mode (when edits are needed) or Ask mode (research and brainstorming, read-only).

Then give the main agent an instruction roughly like this:

Solve this task in parallel with three subagents — the gpt, opus and glm profiles.
Each should independently propose a solution. Then compare their answers,
find discrepancies, and formulate a final solution that accounts for all viewpoints.

Sharing between subagents. Subagents run in parallel and cannot see each other's progress, so it is convenient to keep shared context in a file under the .tasks/ directory: each agent appends its own variant and comments on the others, and the main agent assembles the final result.

Tip: treat the shared file in .tasks/ as a "discussion board" where each agent notes what it agrees with and what it disputes. Instead of three independent answers, you get one discussion with a shared conclusion.

Ready-made Skill. Save the prompt as .explyt/skills/multi-model-consilium/SKILL.md — then you can launch it with the /multi-model-consilium command or automatically when the agent deems it necessary. Adjust the profiles to your needs.

---
name: "multi-model-consilium"
schemaVersion: "v0.1"
description: "Solve a task in parallel with three models and compare the results (cross-model consensus)"
agent: "General"
used-by:
  - "Orchestrator"
  - "General"
---

1. Run the task in parallel with three subagents in Code mode using the `gpt`, `opus` and `glm` profiles (see Model Routing). For research without edits, use Ask mode.
2. Each subagent independently proposes a solution and writes it to its own section of the shared file `.tasks/consilium/<task>.md`.
3. When all three finish, read the file, compare the answers, and find discrepancies.
4. Formulate a final solution that accounts for all viewpoints and record it in the same file.

Cross-model review

The same technique works for review: several models check the same change, and the main agent compares the findings and resolves discrepancies. This is useful when you want to reduce the risk of missing a bug because of a blind spot in one model.

The setup is the same — several profiles with different models.

Working mode. The main agent, Orchestrator, coordinates the subagents. For review, run the subagents in Review mode: it is designed for checking changes and uses IDE inspections. The main file editing tools are unavailable in this mode, but before running it, check the available tools and permissions: the set depends on the configuration and does not give a strict technical guarantee of read-only behavior.

Request to the main agent:

Review these changes in parallel with the gpt, opus and glm profiles.
Each should independently find problems. Then merge the findings,
remove duplicates, and produce a single prioritized list.

Tip: put each review result into a shared file under .tasks/, and let the main agent handle deduplication and prioritization. The output is then one consolidated report instead of three independent ones.

Ready-made Skill. Save the prompt as .explyt/skills/multi-model-review/SKILL.md — then you can launch it with the /multi-model-review command or automatically when the agent deems it necessary. Adjust the profiles to your needs.

---
name: "multi-model-review"
schemaVersion: "v0.1"
description: "Review changes in parallel with three models and produce a single list of problems"
agent: "Orchestrator"
used-by:
  - "Orchestrator"
  - "General"
---

1. Run a review of the changes in parallel with three subagents in Review mode using the `gpt`, `opus` and `glm` profiles.
2. Each subagent writes the problems it finds to its own section of the shared file `.tasks/review/<review>.md`.
3. When all three finish, merge the findings: remove duplicates and assign priorities.
4. Produce a single consolidated list of problems.