oh-my-hermes: an operating layer for Hermes Agent workflows
Just install once. Anyone can use hermes-agent professionally. the powerful intelligence and memory system for your agent .
At a glance
- What is it?
- oh-my-hermes (OMH) is a Python skill pack that sits above Hermes Agent and adds routing, evidence gates and project memory. It installs through Homebrew, Bun, npm or a shell script, then expects you to run omh setup.
- Who is it for?
- Adopt oh-my-hermes if you already run Hermes Agent and want a governed path from a natural-language request to a recorded outcome; the README is explicit that OMH strengthens Hermes rather than replacing it. Skip it if you are not a Hermes user, or if you want a coding executor hidden behind the interface, which the project says it will not do.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap oh-my-hermes is trying to close
A Hermes Agent request is a natural-language instruction. That is convenient and also the source of the problem: nothing in the request itself says which capability should run, how much reasoning effort it deserves, or what counts as proof that the work happened. oh-my-hermes, abbreviated OMH throughout the README, is positioned as an operating layer above Hermes-native skills. The README states that OMH "frames the problem, picks the workflow and evidence gates, and runs native skills as capabilities inside that governed path."
The target reader is someone who already uses Hermes and wants repeatable runs rather than one-off prompts. The README names the areas it covers: planning, research, creation, coding handoffs, operations, and project memory. The phrase that matters most is "explicit evidence boundaries." OMH is not trying to make an agent smarter. It is trying to make an agent's claims inspectable.
That is a narrower goal than the marketing line ("the powerful intelligence and memory system for your agent") suggests, and the narrower goal is the more defensible one. Plenty of tools will happily route your prompt to a model. Fewer will tell you, per dispatch, which category and effort level were chosen and what the run is permitted to assert afterwards.
How routing and evidence gates actually fit together
The mechanism visible in the README is mixture-of-models routing. Each delegated lane is routed onto a category, and the README lists examples: ultrabrain, deep, quick, writing, visual-engineering. A model and a reasoning effort are applied per dispatch. Every activity row carries its category, name, model and effort in the form `category:name(model:effort)`, so the routing decision is printed rather than hidden. Rejected routes fall back along the category chain.
That fallback behaviour is the interesting design choice. A routing layer that silently degrades is hard to audit; one that walks a declared chain and labels each row is easier to reason about after the fact. The cost is verbosity. If you dislike a terminal that narrates its own decisions, this will read as noise.
Alongside routing, the README describes parallel tool calling, where batched tool calls run concurrently. The repository layout backs up the routing claim: pyproject.toml declares packages including omh.routing, omh.routing.trigger_packs, omh.evidence, omh.capabilities, omh.catalogs, omh.codegraph, omh.quality and omh.profiles. There is a distinct omh.evidence package, which is consistent with the evidence-boundary language in the README rather than being decorative. There is also omh.install and omh.maintenance, which matches the update and uninstall behaviour described later in the README.
What the README does not document is the exact format of an evidence record or how a gate fails. The docs/CAPABILITIES.md and docs/CAPABILITY_IMPACT.md files are linked but their contents are not reproduced, so the precise contract is something you have to read in the repository.
Installing oh-my-hermes and running a first workflow
The README states that Homebrew, Bun and npm installs have been public since v1.0.6. Bun is marked as the recommended path. Pick one manager and stay with it, because `omh update` detects how the command was installed and upgrades through the owning installer.
With Bun:
bun install -g oh-my-hermesWith npm:
npm install -g oh-my-hermesWith Homebrew:
brew install rlaope/tap/omhOn macOS or Linux there is a universal installer, and on Windows a PowerShell script for PowerShell 5.1 and above:
curl -fsSL https://raw.githubusercontent.com/rlaope/oh-my-hermes/main/install.sh | shirm https://raw.githubusercontent.com/rlaope/oh-my-hermes/main/install.ps1 | iexInstalling the CLI is not the end of it. The README marks setup as required, and this is the step people skip:
omh setupAfter that, `omh doctor` verifies or troubleshoots the installation. Running bare `omh` opens Hermes itself with the OMH identity applied, so it is the same entry point as `hermes` rather than a separate shell.
If you would rather wire OMH in through Hermes skills, the README gives a tap path:
hermes skills tap add rlaope/oh-my-hermes
hermes skills install rlaope/oh-my-hermes/skills/omh-routing --yesThe README also offers an agent-driven install that points an AI agent at INSTALL_FOR_AGENTS.md, with an explicit instruction to resolve refs/heads/main to a full commit SHA first and fetch only that pinned revision. That pinning detail is worth noticing: it is the project telling you not to let an agent execute whatever main happens to contain at install time.
Where oh-my-hermes is the wrong tool
The clearest boundary is stated by the project itself. OMH "never replaces Hermes" and does not hide a coding executor behind the interface. If you want a single command that takes a ticket and returns a merged pull request, this is not that, and the README says so deliberately.
The second boundary is dependency. OMH is an operating layer, so it presumes Hermes Agent is present and that you have opinions about which models you want in the chain. The README describes an interactive model setup and a model-chain interview during the agent-driven install, which means installation is not fully unattended. A team expecting a silent package install followed by immediate use will be surprised by the prompts.
The third is platform reach. The universal installer covers macOS and Linux, and Windows is served by install.ps1 rather than by the shell script. The pyproject classifiers declare OS Independent, and a comment in pyproject.toml states that the full test suite runs as an enforcing gate on windows-latest as well as ubuntu, but that describes the Python package's test matrix, not a promise that every install path behaves identically everywhere.
Finally, the README's own framing of OMH as a layer that strengthens what you already use means it inherits Hermes' limits. If your problem is that Hermes cannot do something, adding routing categories and evidence gates will not change that.
How OMH differs from installing skills one by one
The obvious alternative is the plain Hermes skill workflow: add a tap, install a skill, invoke it. The README shows that path directly with `hermes skills tap add` and `hermes skills install`, and OMH supports it. The difference is what wraps the skill.
In the plain path, the skill is the unit of work. You choose it, you run it, and any record of what happened is whatever the skill emits. In the OMH path, the skill becomes a capability invoked inside a governed run. The routing layer picks a category and an effort level, the activity row prints which ones were chosen, and the evidence boundary constrains what the run may claim. The README describes this as running native skills as capabilities inside a governed path.
So the trade is control versus overhead. Installing skills individually gives you a smaller surface and no category vocabulary to learn. OMH gives you a consistent record across runs, at the cost of an extra layer between your request and the skill, plus the model-chain configuration that layer needs. The repository's pyproject.toml lists no runtime dependencies, which suggests the CLI itself is thin and the weight sits in the workflow definitions rather than in vendored libraries.
Upgrading, removing, and what the MIT licence leaves you to decide
Upgrades go through one command:
omh updateThe README explains the sequence: it detects how the command was installed, upgrades the Homebrew, Bun, npm, curl or PowerShell package through its owning installer, then re-enters the updated command to refresh managed skills, the installed plugin bundle, and existing Hermes registration. When `omh update` reports that the owning manager is unavailable, the README says to use the manager command directly, and it lists those: `brew upgrade rlaope/tap/omh`, `bun update -g --latest oh-my-hermes`, or `npm update -g oh-my-hermes`.
Removal has a subtlety. Removing the command package preserves OMH state, so a manager uninstall is not a clean sweep. For full removal the README instructs you to run `omh uninstall --all` before the manager's remove command. There is also a documented reconciliation path for turning a `--full` install back to core, in docs/INSTALLATION.md under reconciling an existing full install back to core. That section is where you should look before changing install shapes, because the README does not reproduce the procedure.
The licence is MIT, declared both in the repository's LICENSE file and in pyproject.toml. MIT is permissive and places few obligations on how you redistribute or modify the code, but it also means the project offers no warranty. That is a standard trade, not a problem specific to OMH. What you should not read into it is any guarantee about the models your routing chain reaches; the licence covers the code, and the model providers are governed by their own terms. This is not legal advice, and if redistribution matters to your organisation, read the LICENSE file yourself.
On maintenance: the last push was on 2026-08-29, and v2.0.0 was released the same day, following v1.0.10 and v1.0.9 earlier in August 2026. The repository is not archived.
Editorial conclusion
Adopt oh-my-hermes if you already run Hermes Agent and want a governed path from a natural-language request to a recorded outcome; the README is explicit that OMH strengthens Hermes rather than replacing it. Skip it if you are not a Hermes user, or if you want a coding executor hidden behind the interface, which the project says it will not do. Before committing, check the docs/INSTALLATION.md reconciliation path, confirm which package manager your machine already uses, and read the evidence boundary rules in docs/CAPABILITIES.md so you know what a run is allowed to claim it did.
Frequently asked questions
What is oh-my-hermes used for?
It adds an operating layer above Hermes Agent that frames a request, selects a workflow and evidence gates, and runs native skills as capabilities inside that path. The README lists planning, research, creation, coding handoffs, operations and project memory as the areas it covers.
How does the oh-my-hermes system work?
Each delegated lane is routed onto a category such as ultrabrain, deep, quick, writing or visual-engineering, with a model and reasoning effort applied per dispatch. Activity rows print the choice as category:name(model:effort), and rejected routes fall back along the category chain.
Is oh-my-hermes free?
The repository is licensed under MIT, declared in both the LICENSE file and pyproject.toml, so the code is free to use and modify under those terms. The README does not state anything about the cost of the models that the routing categories dispatch to.
Which text-to-speech provider works with oh-my-hermes?
The README does not name a text-to-speech provider, so this cannot be answered from the available material. The routing categories it lists are ultrabrain, deep, quick, writing and visual-engineering.
Community notes