Hermes Subagent Model: How to Choose the Model Each Subagent Runs On

Your Hermes subagent model decides how smart, how fast and how expensive every child agent is. By default, Hermes subagents simply use the same model as your main agent. That’s easy, but it’s rarely the cheapest setup, because subagents are where most of your tokens go. In the video below I show subagents doing real work for me. In this guide I’ll show you every way to choose the model your subagents run on — one global setting, the model picker, fallbacks, and per-task routing.

What model do Hermes subagents use by default?

When your agent calls delegate_task, each subagent runs on the same model as the parent unless you say otherwise. The official docs are clear: “If omitted, subagents use the same model as the parent.” They also inherit the parent’s provider, API key and credential pool, which means key rotation on rate limits still works for children.

That’s a safe default, but think about the cost. The docs point out that a parallel batch of subagents typically burns the large majority of a run’s total tokens. If your main agent runs on a top frontier model, every subagent does too — even the ones just summarising a web page.

Option 1: pin one model for all subagents

The simplest change is to set one model for every child in ~/.hermes/config.yaml:

model:
  default: "your-frontier-model"     # parent (planner) stays on the frontier model
delegation:
  model: "your-inexpensive-model"    # all delegate_task children run on this
  provider: "openrouter"             # optional: route children to a different provider

This is the pattern the docs call frontier planner, inexpensive workers. Splitting a problem into clear subtasks takes strong judgment. Doing a subtask that already has a clear goal, full context and an output format usually doesn’t.

You can also point subagents at a direct endpoint — for example a local model — with delegation.base_url and delegation.model. The order is: base_url first, then provider, and if neither is set the children inherit the parent’s provider. delegation.model applies in all cases; leave it empty and children inherit the parent’s model.

Option 2: use the model picker (no YAML)

Prefer menus? Run hermes model and choose Configure auxiliary models. In the list you’ll see a delegation entry, which shows “auto / inherit main agent” by default. Pick a provider and model and it saves to delegation.provider and delegation.model. Here, auto means inherit the parent’s provider, model and credentials.

In the Desktop app the same keys live under Settings → Model → Subagents. That page edits the profile you choose under Applies to, affects subagents launched after you click Apply, and never changes your main model or a child that’s already running.

The catch: one pin applies to every subagent

It also helps to remember what a subagent actually receives: a clear goal, the context the parent wrote and an optional output format. Because the hard thinking happens when the parent plans the work, a well-briefed subagent can often do its part well on a smaller, faster model.

A delegation.model pin is global. With the default strategy, delegate_task has no per-task model setting, so every child in a batch runs on the same delegation model. That’s fine when your subagents all do similar work.

When some tasks need a stronger model, the docs give you three options: leave delegation.model unset for that session, use a delegation strategy plugin, or hand the task to the kanban board, which supports a per-task model override.

Option 3: a different model per task (model routes)

The cleanest fix is the official advanced-delegation plugin (Hermes 0.22.5 or newer). Its model routes mode lets you define named routes and lets the agent pick one per task:

delegation:
  backend: model_map
  backends:
    model_map:
      options:
        - name: fast
          description: "Cheap and quick: lookups, summaries, simple edits."
          provider: openrouter
          model: google/gemini-3-flash-preview
        - name: deep
          description: "Slow and careful: hard debugging and design work."
          provider: anthropic
          model: claude-opus-5
          reasoning_effort: high
      default: fast

The agent only ever sees the route names and descriptions, never your provider, model or key fields. Each result reports the route it ran on, so you can check which model did which job. While model routes are active, delegation.model and delegation.provider are ignored — the routes decide.

Option 4: a different profile per task (profile routes)

The same plugin’s profile routes mode runs a subagent as one of your Hermes profiles. Each profile keeps its own model, so the model choice comes with the profile — plus its credentials, skills and SOUL.md. A coder profile on a coding model and a researcher profile on a long-context model is a simple, powerful setup. Only list profiles whose keys and terminal access you’re happy for this agent to use.

Fallbacks for subagents

If a subagent’s provider fails, Hermes can fall back to another one. A model route without its own fallback_providers uses delegation.fallback_providers; setting fallback_providers: [] on a route switches fallback off for it. A profile route uses that profile’s own fallback chain. When a fallback takes over, the result says so (fallback_activated: true).

Which model should your subagents run on?

Here’s a practical way to think about it. I’m not quoting prices here — check each provider’s current pricing.

For specific picks, I’ve tested several strong options: Kimi K3.1 Pro in Hermes, DeepSeek V4.1 Flash as a low-cost worker, and GPT-6.1 Sol as a balanced option. My full ranking is in the best model for Hermes Agent.

My verdict on the Hermes subagent model

Leave subagents on your main model while you’re learning. Once they’re doing real work, pin a cheaper delegation.model, and when you need a mix, add model routes or profile routes. Getting your Hermes subagent model right is the single easiest way to cut agent costs without losing quality.

About Julian Goldie

I’m Julian Goldie — founder of Goldie Agency and the AI Profit Boardroom. I test new AI agents almost every day for 432K+ YouTube subscribers and run Hermes, OpenClaw, OpenCode, Claude and Codex side by side in my own Agent OS. Claim your free strategy session or join the AI Profit Boardroom.

Want another angle? Read the AI Profit Boardroom guide to Hermes subagent model.

FAQ: hermes subagent model

What model do Hermes subagents use?

By default the same model as the parent agent, along with its provider, API key and credential pool.

How do I change the subagent model in Hermes?

Set delegation.model, and optionally delegation.provider or delegation.base_url, in ~/.hermes/config.yaml, or use hermes model, Configure auxiliary models, delegation. In Desktop it’s Settings, Model, Subagents.

Can each subagent use a different model?

Not with the default strategy, where one pin applies to every child. The advanced-delegation plugin’s model routes or profile routes let the agent pick per task.

Should subagents use a cheaper model?

Often yes. The Hermes docs recommend a frontier planner with inexpensive workers, because subagents use most of a run’s tokens while well-specified subtasks rarely need a frontier model.

What happens if a subagent’s provider fails?

Hermes can use fallback providers: a route’s own fallback_providers or delegation.fallback_providers. The result shows fallback_activated when one took over.

Related reading

• Hermes Advanced Delegation
• Hermes Agent Subagents
• Best Model for Hermes Agent

Last updated October 2026. This page is a living guide to hermes subagent model — the facts here move fast and it is updated as they do.