Field Report // NO. 012

The 13-Profile Stack: how I run a fleet of Hermes agents on one machine

4 August 2026· 6 min read· Case № 012

How to run a fleet of Hermes profiles like a cost ledger: the rule for when a new profile earns its own tier, who sits where, and the four failure modes that burn money.

I have 13 Hermes profiles running on one box, and the machine stays quiet. Most of them are not running at all — they are definitions waiting for a job.

Read the fleet as a cost ledger, not an org chart. Each profile carries a different workload, and the workloads differ in what they cost. One profile thinks hard for an hour on architecture. Another sends a briefing and goes back to sleep. Treating both with the same model is how a month of smooth operation turns into a session that burns a token allowance on the first heavy task.

This article is the management layer on top of that — the part that is not really about configuration at all. The tiers, the sync script, and the full file walkthrough live in hermes-06 and hermes-11. What this article owns is the rule that decides when a new profile gets its own tier, and the four ways a fleet quietly stops being cheap.

The stack

Thirteen profiles on a single VPS: personal, system-admin, engineering-lead, engineer, junior-engineer, architect, devops, product, trainer, accountant, reviewer, fishing, and the-agent-files-editor.

Each profile is a directory under ~/.hermes/profiles/<name>/ with its own config.yaml, its own skills, its own memory, and its own model. None of them carries an API key in the config file — that was the problem the tier system fixed.

A tier is a named model chain: an ordered list of fallback hops. Index 0 is the primary model; indices 1 and up are tried in order until one succeeds. Profiles do not name models; they name tiers. The tier is the only per-profile decision.

The tier-creation rule

The rule, as it has settled in practice: share a tier until the workload proves it needs something else.

  • A new profile starts on the closest existing tier, usually general-medium. One line in profiles:, zero new chain definitions. That is the default move.
  • Create a new tier only when the workload differs in cost or capability in a way the existing chains do not express — a provider whose allowance is tight, a capability only one model has, a volume high enough that the cheap tier must be the cheap tier.
  • The code family exists because engineering is a different cost shape from conversation: the engineer needed DeepSeek V4 as primary, and code-* names that shape. The specialist family exists because Alibaba’s allowance is tight, and specialist-heavy is how that allowance gets spent only where it pays.
  • The cost gradient is why the rule matters: M2.5 Highspeed at the base of simple is effectively free; M3 at the top of heavy costs roughly ten times more per token. The ratio compounds inside a long reasoning loop, so the tier choice matters more than the price-per-token ever does.

The fishing profile is the one I keep going back to when the rule stops making sense. It started on general-simple — the cheapest thing that works. A week later it moved to medium, then again. The workload proved it needed something else, and the rule is what makes that a one-line change instead of a config rewrite.

Who sits where

The profile map from the same file — the July 2026 state, before the gateway migration that the next articles cover:

profiles:
  personal:                { tier: general-heavy }
  engineering-lead:        { tier: general-heavy }
  engineer:                { tier: code-heavy }
  junior-engineer:         { tier: code-simple }
  architect:               { tier: specialist-heavy }
  devops:                  { tier: code-medium }
  product:                 { tier: general-heavy }
  trainer:                 { tier: general-medium }
  accountant:              { tier: general-medium }
  reviewer:                { tier: specialist-medium }
  fishing:                 { tier: general-simple }
  the-agent-files-editor:  { tier: general-medium }

Read it as a cost ledger. Most profiles land on heavy because the cost of being wrong is higher than the cost of a slightly more expensive token. The cheap ones earn their tier by being genuinely low-stakes: fishing is light chat and research, junior-engineer is scoped routine coding, and the editor is text-only work where heavy was habit rather than necessity.

The tier names are workload names, not provider names — general-*, code-*, and specialist-* are promises about the workload, and the chain underneath can change providers without the profiles noticing. hermes-11 has the full rationale for each family and the selection framework.

The failure modes

Thirteen profiles fail in predictable ways. Here are the ones I have seen.

Shared tier is not a shared allowance. Sharing is the design — twelve of the thirteen profiles share a family with at least one other. What breaks is the illusion that a shared tier means a shared allowance. Fallback spend is per provider: when a primary leg fails, the chain steps to leg two and that spend comes out of the second provider’s window. Resilience has a cost, and the cost shows up in whichever provider window the fallback landed in.

The allowance windows do not line up with the tooling. MiniMax, OpenCode Go, and Alibaba meter on 5-hour rolling token windows. The budget enforcement in the gateway layer is a flat monthly cap per key. The two do not map cleanly. I run a conservative monthly cap and watch the provider dashboards, and budget enforcement against rolling windows is still unsolved — that is the next article.

A tier family that is really one provider is a single point of failure. The biggest lesson from the fleet so far: in the July 2026 file, every tier’s primary sat on MiniMax, and every tier’s fallback chain leaned on the same three providers in the same order. The chains looked like four independent safety nets. They were one net with extra knots. When MiniMax’s window filled, every profile stepped into the same second provider at once.

Profiles drift. A fleet is not a static org chart; it is a running system, and a running system needs the same attention a single profile does. Some profiles carry most of the traffic; some quietly stop. In the first week of August 2026, architect, junior-engineer, and devops showed zero activity, while junior-engineer had 86 never-ended sessions sitting in its session store. The tier-creation rule has a reverse side: a tier is only earned while the workload keeps proving it. When a profile goes quiet, the question is not what tier it is on. It is whether it is still earning the one it has.

The recipe

Everything above, in one place:

  1. One file. ~/.hermes/models.yaml — providers, tiers, auxiliary map, profile assignments. The full walkthrough and the sync commands are in hermes-06.
  2. One decision per profile. profiles.<name>.tier.
  3. The rule. New profiles start on the closest existing tier. New tiers exist because a workload differs in cost or capability, not for novelty.
  4. Sync, don’t hand-edit. hermes-models reads the one file and rewrites the model keys in every profile’s config. Hand-editing 13 configs is how a typo breaks a profile for a weekend — the commands are in hermes-06.
  5. Watch the failures. Shared tiers are fine; shared provider windows are the risk. Fallback spend counts against the fallback provider’s allowance. Rolling windows do not map to monthly caps. Idle profiles still carry tiers.

The takeaway

Thirteen profiles are manageable because the configuration is not thirteen things. It is one file, one decision per profile, and one rule for when that decision changes: share a tier until the workload proves it needs something else. The failure modes are mostly about money and attention — fallback spend, rolling windows, the fact that a fleet quietly shares one provider’s luck, and the profiles that stop earning their tier without telling you.

The next layer down is where the tiers become real chains inside a gateway, and where the rolling-window problem lives. See From models.yaml to LiteLLM for the gateway install, and Choosing a Hermes model by task and budget for the tier-selection framework and how to change a profile’s tier in one line.


Michael Short is the founder of The Agent Files.

← All transmissions