Switching models mid session in Hermes Agent resets the prompt cache. On a long Django session that meant a noticeable latency spike and a re ingestion of a large chunk of the repo right after typing /model. The question that matters isn't whether this happens, it does, it's when it's actually worth paying for and when a saved skill or an open ended instruction can dodge the cost entirely.
I spent the last few weeks running Hermes Agent 2.3 against a mid sized Django monorepo, mostly doing the boring work: migration cleanup, test triage, a staging deploy pipeline that needed hand holding until it didn't anymore. The official tips and best practices page for Hermes Agent reads like a short list of common sense suggestions, and most of them are exactly that. Two of them, the model switching cache tradeoff and the skills mechanism for repeat tasks, change the economics of a session in ways you don't see coming until you've paid for the mistake once.
My stance going in: skills are the single highest leverage feature in that doc, and the model switching advice is correct but incomplete, because it doesn't say what counts as a long session or how much a cache reset actually costs in practice. Let's take them one at a time.
Why Model Switching Costs More Than the Docs Admit
Bounce Back vs Fresh Session: What Happens on a Model Switch
Approach One: Bounce Back and Forth in One Session
Approach Two: Fresh Session Per Model
Source: Based on author's five test runs described in article
Picture a session where you start in Claude Sonnet 4.6 to design a new permissions layer for an internal admin tool, then drop to GPT 4o mini for the grunt work of renaming fields across forty files. That's exactly the workflow the Hermes docs recommend: frontier model for architecture, faster model for formatting and boilerplate. On paper it sounds like a clean division of labor, expensive brain for the hard part, cheap brain for the tedious part.
I did this on a session that had already built up a sizeable amount of context, mostly file reads and a long back and forth about foreign key constraints. The moment I typed /model to drop to a faster tier, the prompt cache reset. Every file the agent had already read got re ingested on the next turn. The latency spike was obvious, noticeably longer on the first response after the switch, and the cost didn't go down the way I expected, because the agent effectively re read a large portion of the repo just to re establish context.
Here's the part the docs get right: on long sessions it's often cheaper to start a fresh session on the other model than to bounce back and forth. I tested this directly. Below is roughly what the two approaches looked like in terms of session shape, not exact numbers pulled from a billing dashboard, but the pattern held consistently across five separate test runs.
# approach one: bounce back and forth in one session
/model claude-sonnet-4.6
40 turns of architecture discussion, context grows to 58k tokens
Where Context Comes From in a Bounced Session
Approximate token load across one bounced session (58k base context plus two cache rebuild events)
Total session token load
Original architecture context
Cache reset on switch to mini
Cache reset on switch back
Source: Author's described session shape, directional not exact billing data
/model gpt-4o-mini
cache reset here, next turn re-ingests large chunks of prior context
The Break Even Rule for Model Switching
Short session, low context
Bounce OK
Cache rebuild is cheap, switching mid session fine
Tens of thousands of tokens
Start Fresh
Closing session beats re ingesting large context
Observed in article: session context grew to 58,000 tokens before the first /model switch triggered a cache reset and large re ingestion
Note: exact break even threshold is not published by Hermes and likely varies by workload. Pattern held across five test runs, treat as directional.
Source: Author's directional observation from one week of usage logs
15 turns of renaming and formatting
/model claude-sonnet-4.6
cache resets again, same re-ingestion cost
approach two: fresh sessions per model
hermes session start --model claude-sonnet-4.6 --task "design permissions layer"
finish architecture work, close session
hermes session start --model gpt-4o-mini --task "rename fields across repo"
no shared history to reconstruct, smaller fresh context from the start
The second approach cost less in my own usage logs over a week of similar tasks. That's an observed pattern from my own sessions, not a benchmark Hermes has published, so treat it as directional rather than a guarantee. What the docs don't say is where the break even point sits. My own rough sense: once a session has grown into tens of thousands of tokens of active context, a model switch is probably going to cost more than closing the session and starting a new one on the other model. The exact threshold likely varies by workload. Below that, bouncing back and forth is fine, the cache rebuild is cheap enough not to matter.
Someone running short, low context sessions gains the most from the current one line warning, since the advice there is basically free. Anyone running a long, exploratory architecture session loses the most, because that's exactly the scenario where the hidden cost is highest and the docs give no number to reason about. The fix for that second group isn't a smarter model switch, it's avoiding the need to switch at all for repeated work. Which is exactly what the skills mechanism is for.
A Six Minute Deploy Becomes a Forty Five Second Command With Skills
Three weeks ago I had a staging deploy that took eleven manual steps: build, run a schema check, push to a holding bucket, flip a feature flag, run smoke tests, and so on. The first time I did it through Hermes Agent I walked it through every step individually, the same way I'd onboard a junior engineer who had never seen the pipeline. The second time, I said something close to the exact phrasing in the docs: save what you just did as a skill called deploy staging.
That single sentence does more work than it looks like. Hermes Agent isn't just storing a transcript, it distills the sequence into a reusable procedure you invoke with a slash command, something like /deploy-staging on the next run. The practical effect: a task that used to take several minutes of back and forth, a good chunk of it me re explaining context the agent should already have inferred, now takes well under a minute of typing one command and watching it execute.
Here's roughly how that second invocation looked in my terminal history:
# first time: full manual walkthrough
> build the staging bundle, run the schema check against the staging db,
> push to the holding bucket, flip the canary flag to 10 percent,
> then run the smoke test suite and report pass/fail
agent executes all five steps, takes about 6 minutes with back and forth
> save what you just did as a skill called deploy-staging
agent confirms: skill 'deploy-staging' saved, 5 steps captured
next session, days later
/deploy-staging
agent loads the full procedure, executes without re-explaining context
total time: under a minute
What makes this different from a shell script or a Makefile target is that the skill isn't a rigid sequence of fixed commands. It's closer to a saved procedure with some judgment attached, so if the schema check fails on step two, the agent still knows to stop and report rather than barreling through steps three through five like a dumb script would. That's the actual value, and it's also the actual risk. A skill saved from a session where something unusual happened, say a flaky network call that got silently retried, can bake that oddity into the procedure permanently. I had this happen with a skill called run-migrations that quietly included a retry loop I never asked for, because the agent had hit a transient database timeout during the original recording and decided retrying was part of the normal procedure.
The lesson isn't to avoid skills. It's to review what got saved before trusting it on a production path. Treat a new skill the way you'd treat a first draft of a runbook written by a smart but slightly over eager colleague: mostly correct, worth a second read before it runs unattended.
For anything done once, manual prompting wins outright, since skills add overhead for no payoff there. For anything repeated more than twice with the same shape, skills win decisively, and the gap widens with every additional run. The break even point in my experience sits almost always at the second repetition, not the fifth.
Exploring a Bug Beats Narrating One, Most of the Time
Saved skills work well for procedures you already know, like a deploy sequence. The deploy skill above only exists because I'd already done the eleven steps manually once and knew exactly what the correct sequence looked like. Bugs are different: you often don't know the sequence of steps that will fix them in advance, so the question becomes whether to narrate the investigation yourself or let the agent explore on its own.
A test suite of a few hundred tests had one failing on a CI run last month, somewhere in a payment reconciliation module. My first instinct, the old instinct from years of pairing with less capable tooling, was to open the failing test file, point to the line number, and narrate the fix step by step. The Hermes docs push back on exactly this habit: say find and fix the failing test rather than walking through tests/test_foo.py line by line. The agent has file search, terminal access, and code execution, so let it explore.
I ran both versions on the same bug, somewhat artificially, by reverting the fix and asking twice with different phrasing. The hand held version took longer in wall clock time, mostly because I was the bottleneck, re reading stack traces and deciding which file to point at next. The exploratory version, just find and fix the failing test, had the agent run the suite, isolate the failure, grep for the relevant function, read two adjacent files I wouldn't have thought to check, and land on a fix that touched a currency rounding helper I didn't even know existed in that part of the codebase.
This doesn't always work better, and the failure mode is worth naming directly. On a separate occasion I asked the agent to find and fix a flaky integration test, and it genuinely couldn't tell flaky from broken, so it spent several turns applying a fix to logic that was correct, because the actual problem was test ordering and a shared fixture leaking state. The open ended instruction works well when the agent's exploration tools, file search, terminal, test execution, are sufficient to localize the real cause. It works poorly when the root cause lives outside what those tools can see easily, like test execution order or environment specific flakiness.
A quick way to sanity check whether a bug is a good candidate for the find and fix pattern:
- Reproducible failure with a clear stack trace or assertion
- Localized failure within a small number of files or one module
- No dependency on timing, ordering, or external state, and this one matters more than the other two combined
If a bug meets those three conditions, open ended delegation tends to work close to as well as careful hand holding, and it's considerably faster since you're not the one reading stack traces. If it fails any of them, especially the ordering or external state condition, doing some of the diagnosis yourself before handing the agent a narrower instruction tends to pay off more.
$ hermes run "find and fix the failing test"
[hermes] running pytest suite... 1 failure detected
[hermes] FAILED tests/payments/test_reconciliation.py::test_rounding_edge_case
[hermes] grepping for related functions in app/payments/
[hermes] reading app/payments/helpers.py, app/payments/currency.py
[hermes] identified fix: round_half_up() missing in currency.py line 42
[hermes] applying fix, re-running suite... 340 passed
This is the part of the Hermes best practices doc that most engineers underrate, because it reads like generic advice about trusting your tools. The specific claim buried in it, that the agent's combination of file search, terminal access, and code execution together are usually sufficient for straightforward bugs, is a real and testable one. In my own runs it held for most of the bugs that met the three conditions above, though not all of them. The exceptions are where you still earn your salary.
None of this makes Hermes Agent some kind of autonomous engineer that replaces judgment. The three cases above, model switching, skills, and open ended bug fixing, all come down to the same underlying question I started with: which costs are visible up front and which ones only show up after you've paid them once. A model switch looks free until the cache reset bill arrives. A skill looks free until it quietly bakes in a retry loop you never asked for. An open ended "find and fix" looks free until the bug turns out to be about test ordering instead of logic. What changes with Hermes Agent isn't that these costs disappear, it's where your attention has to go: less on narrating steps the agent could find itself, more on reviewing what it decided to do, more on deciding when a model switch is worth the cache reset, more on reading a saved skill before letting it run unattended on something that matters.