Hermes Subagent Model: What It Is, How To Set It, And Which Worker Models Score Best

The Hermes subagent model is the AI model that Hermes Agent's child agents run on when the main agent hands work out with the delegate_task tool.

Hermes Agent is the free, open-source agent from Nous Research, and its subagents reuse the main agent's model unless you pin a different one with delegation.model.

The official delegation docs say a parallel batch of subagents typically burns the large majority of a run's total tokens.

That makes the worker model the setting that decides most of what your agent work costs.

I'm Julian Goldie, and in this post I'll explain what the subagent model is, how to set it and how it fails, and then I'll show you how the models you'd give your workers score on GoldieBench.

Everything about Hermes here comes from Nous's own documentation, not from a lab test of each setting.

The Hermes subagent model at a glance

This table sums up the setting before we go into detail.

What is the Hermes subagent model?

When the main agent calls delegate_task, Hermes spawns child agents with isolated context, the parent's enabled tools and their own terminal sessions.

Each child gets a fresh conversation, and only its final summary returns to the parent.

The subagent model is the brain inside those children, and it is separate from the main model you pick with hermes model.

The docs say plainly that if you don't set a delegation model, subagents use the same model as the parent.

They also inherit the parent's credential pool, which means key rotation on rate limits still works for children.

For the mechanics of delegation itself, see my sibling post on Hermes Agent subagents.

The problem the subagent model setting solves

Most people put their main agent on the strongest model they can afford.

Then the agent delegates ten research jobs, and all ten workers run on that same expensive model.

The docs explain why that is wasteful.

Decomposing a problem into well-specified subtasks takes frontier-level judgment, while executing a subtask with a clear goal, full context and an output contract usually doesn't.

So the expensive thinking belongs with the planner, and the bulk work can often go to a cheaper model.

Nous calls this pattern frontier planner, inexpensive workers.

How to set the Hermes subagent model

The docs give the config version in exactly this form.

# ~/.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

Setting only model keeps the parent's credentials and changes just the model name.

Adding provider resolves that provider's full credential bundle, including the base URL, key and API mode.

The precedence is delegation.base_url first, then delegation.provider, then the parent's provider.

If you'd rather use a menu, run hermes model and choose Configure auxiliary models, where the delegation entry reads "auto / inherit main agent" until you change it.

That picker ends with a reasoning-effort step stored as delegation.reasoning_effort.

In Hermes Desktop, open Settings → Model → Subagents, pick the profile under Applies to, choose a provider and model and click Apply.

The Desktop page also sets the subagent turn limit, concurrency, timeout and reasoning effort, and it never changes the main model or a running child.

Local subagent models through a direct endpoint

The docs also show subagents sent straight to an OpenAI-compatible endpoint, such as a local server.

delegation:
  model: "qwen2.5-coder"
  base_url: "http://localhost:1234/v1"
  api_key: "local-key"

A direct base_url takes precedence over delegation.provider.

Hermes auto-detects the Anthropic wire format for paths such as /anthropic, and delegation.api_mode overrides the guess.

If you leave out api_key, the configuration reference says Hermes falls back to OPENAI_API_KEY only.

What happens when a subagent model fails

The configuration reference says a child pinned by provider, endpoint or model uses a fallback chain only when you declare delegation.fallback_providers.

Without that list, a pinned child fails loudly instead of borrowing the parent agent's route.

An unpinned child still inherits the parent's fallback chain, and fallback_providers: [] disables child fallback.

The parent always hears about a failure, because the result carries status: "failed" and the error text.

In the CLI, the delegation tree prints a one-line reason, and gateway chats get the same notice even with tool progress switched off.

Choosing a different model per task

The docs are honest that the default pin is global.

With the default strategy, delegate_task has no per-task model parameter, so every child in a batch shares one model.

They list three ways round it.

• You can leave delegation.model unset for that session so the children use your strong main model.
• You can install the official advanced-delegation plugin, which needs Hermes 0.22.5 or newer and adds model routes and profile routes.
• You can put quality-sensitive work on the kanban board, which has a per-task model override with hermes kanban set-model.

Model routes are named options such as fast and deep, each with its own provider and model, and the agent picks one per task from the name and description alone.

Profile routes run a subagent as one of your Hermes profiles, with that profile's model, credentials, skills and SOUL.md.

Each routed result reports the provider, model, reasoning effort and speed tier the child actually ran on.

I've covered the plugin in full in Hermes advanced delegation.

A worked example: one research batch, two ways

Picture a main agent asked to compare five competitor pages and write a short report.

It splits the job into five subagent tasks, one per page, and keeps the report-writing for itself.

On the default setting, all five workers run on the same expensive model as the planner.

With a delegation.model pin, the five workers run on a cheaper model, and only the planning and the final report use the frontier model.

Each worker still needs a full brief, because the docs warn that subagents start with a completely fresh conversation and know nothing about the parent's chat.

A good brief names the URL, what to extract and the shape of the answer.

The delegation docs also let each task carry an output_schema, which makes the parent validate the worker's answer and send one correction turn if it doesn't match.

That safety net is a big reason a cheaper worker model can be trusted with structured jobs.

I won't put a percentage on the saving, because it depends on your tasks and your provider's pricing.

Common problems with the subagent model

If subagents still use the main model after a change, check that you edited the profile you're actually running.

If a child fails with a model-not-found error, the id doesn't exist on that provider, so pick it from the hermes model catalogue instead.

If a pinned worker stops when its provider is down, that is designed behaviour, and delegation.fallback_providers is the fix.

If a local endpoint gets the wrong wire format, set delegation.api_mode explicitly.

If the Desktop page shows a draft that never saved, remember that nothing applies until you click Apply.

Tips and limits

Subagents know nothing except the goal and context the parent writes, so a cheap worker with a vague brief will disappoint.

Each Hermes profile has its own config, so a pin in one profile doesn't touch the others.

The /review reviewer subagent runs on your main model unless you pin auxiliary.review.

delegation.max_iterations caps each child's tool-calling turns, and the docs give 250 as the default.

Hermes subagent model: how the worker models score on GoldieBench

Hermes doesn't ship its own subagent model, so the quality of every child depends on the model you connect.

GoldieBench is where I score models on real one-shot builds, and these are current averages from the live board.

The Hermes docs use google/gemini-3-flash-preview as their example worker model, and that exact model isn't on the board, so I won't guess its score.

Their example deep route is claude-opus-5, and Claude Opus 5 is on the board at 8.27.

DeepSeek V4 Flash has been run on 50 tasks, but the live page shows no average, so I won't quote a number for it.

GoldieBench measures one-shot builds, not summaries, so a lower-scoring model can still be a perfectly good research worker with a clear brief.

For build-heavy subagents, the gap between 8.27 and 7.08 is the kind of difference you'd notice on screen.

If you want private workers, my local models page shows what runs on your own hardware.

The wider shortlist is in my best Hermes Agent model explainer, and the release context is in my Hermes Agent v0.22 explainer.

Verdict

Inherit while you learn, then pin a cheaper delegation.model for routine workers and keep the planner on a top model from the board.

Add a fallback chain before anything important depends on a pinned worker, and use routes when one batch mixes light and heavy jobs.

Also On Our Network

• Agent Operatorsthe step-by-step Hermes subagent model setup
• AI Income Deskhow a business cuts agent costs with the subagent model
• AI Tool Verdictevery Hermes subagent model option, scored with a verdict
• agentos.guidethe Hermes subagent model quick start for an Agent OS
• agentos.guidethe best Hermes Agent model guide on agentos.guide

If you run an agency and want a clear plan for putting agents to work on client SEO, you can book a free strategy session with my team.

If you'd like a second opinion on which models your workers should run, you can also claim a free SEO strategy session and we'll look at it together.

Keep the planner strong, give the workers a cheaper brain and a clear brief, and you'll get the most out of the Hermes subagent model.