10 Hermes Plugins Worth Installing Right Now
Hermes plugins are where the agent stops being one loop and starts becoming an operating layer.
The core agent already does a lot: tools, skills, memory, cron, messaging, terminal access, subagents, and kanban. That is enough to run useful work. Plugins matter when the repeated parts of that work should not live in the prompt anymore.
A good plugin does one of three things. It gives the agent a new surface, moves cleanup or capture into a hook, or swaps a backend behind an existing system. The bad version is a plugin zoo where every feature adds model-visible clutter. The good version is quieter: fewer manual steps, cleaner state, better recall, and less ceremony around work the agent already does every day.
This is the short list I would test from. It mixes general plugins and memory provider plugins because Hermes treats both as extension points. General plugins can be enabled together. Memory providers are alternatives, not a stack: pick one active external memory provider at a time.
How Hermes plugins work
Hermes has three plugin shapes worth separating before installing anything.
General plugins add tools, hooks, slash commands, CLI commands, or dashboard extensions. The official Hermes plugins docs and built-in plugins docs are the source of truth when commands change. The core distinction is simple: enable turns on a bundled or already-installed plugin. install is for third-party plugin sources.
You manage bundled plugins with:
hermes plugins
hermes plugins list
hermes plugins enable disk-cleanup
hermes plugins disable disk-cleanup
For third-party plugins, use the install path and review the code first:
hermes plugins install <git-url-or-owner/repo> --enable
Provider plugins replace or extend a core backend. Memory providers are the main case today. You choose them through the plugin UI or the memory setup flow:
hermes plugins
hermes memory setup
Custom plugins can live in ~/.hermes/plugins/, project plugins can live in ./.hermes/plugins/ when HERMES_ENABLE_PROJECT_PLUGINS=true, and distributed plugins can arrive through Python entry points. Treat all three as code-execution surfaces. Only enable project plugins in repos you trust after reviewing the plugin code.
That matters because install does not always mean the model sees a new tool. Enable, install, provider selection, and toolset exposure are separate operations. Sometimes a lifecycle hook runs. Sometimes a dashboard tab appears. Sometimes memory extraction changes after the session ends.
The right question is not "what feature did I add?" It is "what repeated failure did I remove from the agent loop?"
1. disk-cleanup
Start with disk-cleanup.
Agents leave debris. Test scripts, scratch outputs, temp logs, browser artifacts, generated JSON, failed experiment files. If cleanup depends on the agent remembering a final step, cleanup will fail.
disk-cleanup moves that work into hooks. It tracks safe temporary files during Hermes sessions and cleans up the ones that fit its safety rules at session end. It focuses on Hermes-owned temp zones such as $HERMES_HOME scratch paths and /tmp/hermes-*, not random files on the machine.
That boundary is the reason I like it. Cleanup tools are dangerous when they are broad. This one is useful because it is narrow.
Enable it:
hermes plugins enable disk-cleanup
Then inspect the state or run cleanup manually:
/disk-cleanup status
/disk-cleanup dry-run
/disk-cleanup quick
/disk-cleanup deep
The best agent infrastructure is boring. It leaves less junk behind each run.
2. google_meet
google_meet turns meetings into agent input.
The plugin can join a Google Meet URL, capture captions or audio, and produce a transcript Hermes can summarize or turn into action items. It requires a Google account with Meet access, and the host may still need to approve the bot before it can enter the room. It has a transcribe-only mode, a realtime duplex audio mode, and a remote node host mode for setups where the signed-in browser runs on a different machine than the gateway.
I would not turn this on casually. A meeting bot changes the room. Use it where recording or transcription is disclosed, permitted by company policy, and compliant with local consent rules. Skip it for confidential or sensitive meetings unless the room has explicitly approved that workflow.
When the social boundary is clear, the value is obvious. The transcript lands inside the same system that can create follow-up tasks, update notes, draft recap emails, or route work to another agent. That is better than another isolated meeting-notes SaaS tab.
Enable and set it up:
hermes plugins enable google_meet
hermes meet install
hermes meet setup
# optional, depending on your browser/account flow
hermes meet auth
Then drive it explicitly:
Join meet.google.com/abc-defg-hij and take notes. After the call, send me action items.
The important part is explicit-by-design behavior. No calendar scraping. No surprise joins. A URL goes in, meeting artifacts come out.
3. spotify
spotify sounds like a toy until Hermes becomes a resident assistant.
The plugin adds native Spotify tools for playback, devices, queue, search, playlists, albums, and library. Authenticate first:
hermes auth spotify
Then enable the bundled plugin and toolset if they are not already active:
hermes plugins enable spotify
hermes tools enable spotify
That auth flow walks you through the Spotify developer-app setup for your own account. OAuth grants account-scoped permissions, which you can revoke from Spotify account settings. Playback control also needs an active Spotify Connect device. Playback changes require Spotify Premium. Search, library, and playlist work do not need Premium.
I would install this only if Hermes already lives in a messaging gateway, home chat, or ambient terminal. In that setup, small commands should not require app switching:
Play Aphex Twin in the office.
Queue Miles Davis after this.
Make a playlist from the tracks I saved this week.
This is the broader point: plugins do not need to be serious to be useful. Low-stakes control surfaces train the operating habit. The agent handles the small command, picks the right API, and gets out of the way.
4. honcho
Honcho is the memory provider I would test first for personal agents.
It is built for cross-session user modeling: what the user prefers, how they communicate, what the assistant keeps getting wrong, and what conclusions should survive across sessions. The provider uses semantic search plus dialectic Q&A style reasoning over stored memory.
That makes it different from plain retrieval. Retrieval answers "what did we say?" User modeling answers "what does this imply about how I should work with this person?"
Setup usually starts with the Honcho setup path or the generic memory setup flow:
hermes honcho setup
# or
hermes memory setup
Honcho needs a Honcho API key or a self-hosted Honcho base URL. Put durable secrets in the profile .env or use the setup wizard. Do not paste keys into a normal agent session.
Pick Honcho when the agent's failure mode is social or personal context. It forgets tone. It asks questions the user already answered. It misses working preferences. It treats every session as a blank room.
Do not pick it blindly for shared teams. Memory has a privacy boundary. If multiple people use the same agent profile, decide what should be modeled before the system starts modeling it.
That privacy boundary applies to every memory provider below. Memory systems can store personal data, customer names, repo paths, decisions, meeting notes, and secrets the user pasted by mistake. Review retention, deletion, training-use, access control, data-location, pricing, and quota rules before enabling any managed provider.
5. hindsight
Hindsight is the memory provider I would test when recall quality matters more than personality modeling.
Its pitch is long-term memory with a knowledge graph, entity resolution, and multi-strategy retrieval. It supports cloud mode, local embedded mode, and local external mode. The local embedded path can run a daemon with PostgreSQL and use the configured LLM provider for extraction. Depending on configuration, cloud mode and extraction can route memory content through external services.
That shape fits research-heavy agents. If your sessions mention projects, people, repos, incidents, model names, papers, and decisions over months, keyword search starts missing the connective tissue.
Setup:
hermes memory setup
Pick Hindsight when the agent keeps missing related facts across a large history. Pick Honcho when it keeps forgetting who the user is. Those are different problems.
I wrote the broader argument in AI Agent Memory: How I Built Persistent Memory Into My Agent Org. Files still matter. Memory providers do not replace durable state. They decide what context gets pulled back into the loop.
6. mem0
mem0 is the pragmatic cloud memory option.
The provider description is straightforward: server-side LLM fact extraction, semantic search, reranking, and automatic deduplication. That is the right set of defaults when you want memory to work without building your own local store.
Use it when you care more about speed to value than owning every piece of the memory stack. That is not a weakness. A lot of agent systems fail because the operator tries to self-host everything before proving which memory events matter.
Setup runs through the same provider path after the package and API key are present. Set MEM0_API_KEY in ~/.hermes/.env or through the setup wizard so the value survives new sessions:
pip install mem0ai
hermes memory setup
Pick mem0 when you want a managed memory backend and you accept the external service boundary. Skip it when data locality is the main requirement.
7. supermemory
supermemory is another managed memory provider, but I would test it for explicit memory workflows.
Its provider manifest calls out semantic long-term memory, profile recall, semantic search, explicit memory tools, and session ingest. That mix matters. Some teams want memory to be implicit, extracted after each turn. Others want visible memory operations the agent can call and the operator can inspect.
I prefer explicit memory tools in professional workflows. If an agent is going to remember something that changes future behavior, I want the write path to be visible.
Setup. Set SUPERMEMORY_API_KEY in ~/.hermes/.env or through the setup wizard:
pip install supermemory
hermes memory setup
Pick it when the memory boundary needs to be more operational than personal. Profile recall and explicit tools are easier to reason about during review than a purely invisible background memory layer.
8. retaindb
retaindb is for operators who want cloud memory with typed storage.
The plugin describes RetainDB as a cloud memory API with hybrid search and 7 memory types. The setup requires RETAINDB_API_KEY, which tells you the operational shape immediately: this is an external memory service, not a local file.
Hybrid search is useful when semantic recall alone is too fuzzy. Memory systems need exact matches for names, IDs, commands, and project labels. They also need semantic retrieval for loose references. If the provider gives you both, it reduces the number of times the agent remembers the vibe and misses the identifier.
Setup. Set RETAINDB_API_KEY in ~/.hermes/.env or through the setup wizard:
pip install requests
hermes memory setup
Pick RetainDB when typed memory and hybrid search fit your workflow. Skip it when you want no external memory service in the path.
9. byterover
byterover is the memory provider I would look at for a knowledge-tree mental model.
Its manifest describes a persistent knowledge tree with tiered retrieval through the brv CLI. It hooks into on_pre_compress, which is the interesting part. Compression is when a long session loses detail. A memory provider that acts before compression can preserve structure before the context window throws it away.
Install the external CLI first:
npm install -g byterover-cli
brv --version
hermes memory setup
If you prefer the upstream shell installer, inspect it first instead of piping it straight into sh.
Pick ByteRover when session compression is your pain point. If long work sessions keep shedding important context before the final artifact is done, a pre-compress memory hook is worth testing.
10. openviking
openviking is the memory provider I would test for session-managed context databases.
The plugin describes automatic extraction, tiered retrieval, and filesystem-style knowledge browsing. It requires OPENVIKING_ENDPOINT, so it expects an external OpenViking service rather than a purely local embedded store.
The filesystem-style browsing piece is the part I care about. Memory systems need operator visibility. If a provider can expose knowledge in a way humans can browse, debug, and prune, it is easier to trust than a black box that only returns snippets to the model.
Setup. The OpenViking server has to be running, and embedding plus VLM settings need to exist in ~/.openviking/ov.conf. Set OPENVIKING_ENDPOINT in ~/.hermes/.env or through the setup wizard:
pip install openviking
openviking-server
echo 'OPENVIKING_ENDPOINT=http://localhost:1933' >> ~/.hermes/.env
hermes memory setup
If you already run OpenViking elsewhere, skip the local server and point OPENVIKING_ENDPOINT at that service before running hermes memory setup.
Pick OpenViking when you want a browsable context database and already have the service boundary handled.
The order I would use
I would not install all 10 on day one.
Start with disk-cleanup. It reduces mess without changing the agent's judgment. Add google_meet only if meetings are part of the workflow. Add spotify only if Hermes is becoming an ambient assistant.
For skimmers, the picker is this:
| Problem | Start with | Skip when |
|---------|------------|-----------|
| Session debris keeps piling up | disk-cleanup | You need broad filesystem cleanup outside Hermes temp paths |
| Meetings turn into lost action items | google_meet | Consent, policy, or confidentiality is unclear |
| Hermes already lives in your home or work chat | spotify | You do not use Spotify Connect or Premium playback |
| Recall is the failure mode | one memory provider | You have not defined the privacy boundary |
For memory, pick one provider and test it against real failures. Do not run a provider bake-off against sensitive work history. Do not switch because a feature page sounds better. Switch because the agent missed a fact, remembered the wrong thing, stored too much, retrieved too little, or crossed a privacy line.
My default order:
disk-cleanupfor hygiene- one memory provider based on the failure mode
google_meetfor meeting-heavy workspotifyfor ambient control- a second memory provider test only after the first one fails a real task
The pattern is simple: install plugins when they shrink the prompt burden or move repeated behavior into code. If a plugin only gives the model more ways to wander, leave it off.
Hermes does not need plugins to be useful. Plugins are where it starts becoming infrastructure.
If you want help deciding which plugins belong in your own agent stack, Mimir Works can audit the current loop first: prompts, tools, memory, cron, gateway, and the places work is still falling out of the system.
Read next: Hermes Agent Setup Guide: Zero to Running in 30 Minutes and Building Custom Hermes Skills: A Walkthrough.