DEV Community: Zack Chew

Hermes Agent System Requirements — RAM, CPU, Disk, Python, OS 2026

Zack Chew — Sat, 22 Aug 2026 12:06:23 +0000

Hermes Agent runs comfortably on modest hardware for chat-only workloads, but the browser toolset and large model contexts push memory and disk fast. Here's the minimum, the recommended, and where the bottlenecks actually are in 2026.

At a Glance

	Minimum	Recommended
RAM	1 GB	2–4 GB
CPU	1 vCPU	2 vCPU
Disk	2 GB	10 GB+ (with browser toolset)
Python	3.11	3.12 or 3.13
Node.js	Installed for you — only the browser toolset uses it
OS	Linux / macOS / Windows / WSL2	Linux x86_64 or arm64
GPU	None	None (models are remote)
Network	Outbound 443	Outbound 443 + inbound for webhooks

RAM

We host Hermes Agent, so rather than estimate, we measured. Across 31 live Hermes containers on our fleet, resident memory came in at a median of 282 MB, with a minimum of 139 MB and a maximum of 858 MB. Those are real resident figures, not values clamped by a container limit — the containers are capped at 2–4 GB and nothing was close to its ceiling.

The number that matters for sizing is the peak, not the median. A container caught mid-response — actually generating, tools running — touched 1.1 GB. That is the figure to size against, because it is what your box has to absorb on a busy turn. Large context windows (Claude 200k, Gemini 1M) push the working set up transiently in the same way.

A separate browser container adds only 8–95 MB at idle, which is far less than people expect — the cost of the browser toolset is mostly disk and burst, not steady-state memory.

For a single-user VPS, 2 GB is comfortable. For multi-user managed hosting, plan on ~1 GB per concurrent active container.

Worth knowing before you over-buy: the browser toolset is not on by default. It ships as a core toolset but stays inactive until you add browser to toolsets in your config. So the higher numbers on this page are a ceiling you opt into, not the baseline you start from — a stock install sizes against the chat-only figures.

CPU

Hermes Agent is mostly I/O bound — it waits on model responses, network webhooks, and disk reads. 1 vCPU is enough for low-volume use; 2 vCPU helps when the browser toolset is rendering pages or skills do CPU-heavy parsing (PDF, video).

Measured on the same 31 containers: an idle Hermes agent sits at 0.2–0.7% CPU. It is doing essentially nothing while it waits. But a container actively generating a response was caught at over 100% — a full core saturated. That gap is the whole story of sizing Hermes: idle cost is close to zero, so what you are really buying is headroom for concurrent bursts. One agent that is busy 5% of the time and 20 idle agents cost about the same.

Disk

The base install is small (under 500 MB), but the workspace at ~/.hermes grows with chat history, embeddings, and any files your agent touches. Enabling the browser toolset pulls a full Playwright Chromium plus per-session profile data, which is the single biggest jump in disk use. For reference, the official multi-arch Docker image is roughly 900 MB compressed before any of your data. Plan on:

2 GB — minimum, chat-only, ephemeral workspace
10 GB — comfortable for browser toolset + memory store
20 GB+ — if you keep long chat history and large skill data

Python Version (Not Node.js)

Hermes Agent is a Python project, and this trips people up constantly because so much of the agent ecosystem is Node. The requirement is Python 3.11 or newer, below 3.14 — the upper bound exists because Rust-backed dependencies like pydantic-core don't ship wheels for 3.14 yet.

You mostly don't install Python yourself. The official installer provisions it through uv without sudo, so a clean box needs no manual Python setup at all.

Node.js does get installed — the installer bundles v22, and the official Docker image builds on Node 26 — but it is a secondary dependency, not a version you choose. It exists to run the browser automation (agent-browser, resolved via npx on first use) and the WhatsApp bridge. If you never enable the browser toolset, Node sits unused. So "what Node version does Hermes need?" is the wrong question to size a box around; Python is the runtime that matters.

OS Support

Linux — first-class, x86_64 and arm64
macOS — Intel and Apple Silicon, dev environments only
Windows — natively, via the PowerShell installer; WSL2 also works
Docker — the official image works on any OS that runs Docker

GPU? No.

Hermes Agent does not run local model inference. Model calls go to remote providers (OpenRouter, Anthropic, OpenAI, etc.) over HTTPS. You do not need a GPU. If you want local inference, point Hermes at a local Ollama or LM Studio endpoint — the GPU lives on the inference server, not the Hermes box.

Network

Outbound 443 to your model provider (required)
Inbound 80/443 if you accept channel webhooks (Telegram, Slack, etc.)
Outbound to ClawHub / skill registries if installing skills at runtime

Sizing Cheat Sheet

Personal bot, chat-only: 1 vCPU / 1 GB RAM / 5 GB disk — any $4–5/mo VPS
Personal bot + browser toolset: 1 vCPU / 2 GB RAM / 10 GB disk
Team bot, 5–10 concurrent users: 2 vCPU / 4 GB RAM / 20 GB disk
Production, 50+ concurrent: 4 vCPU / 8 GB RAM / dedicated node

Skip the Sizing

OpenClaw Launch hosts Hermes Agent on right-sized containers with the browser toolset, memory store, and channel webhooks pre-wired. Plans from $3/mo.

Originally published at openclawlaunch.com.

Pinning an agent harness is harder than pinning its package

Zack Chew — Sat, 15 Aug 2026 13:26:09 +0000

DeepSeek shipped its own agent harness this week. MIT, developer preview, and the architecture is the interesting part: everything in it is a plugin, including the pieces you would expect to be the program.

We had a reason to look closely, because we put it into a container image that other people run. That means pinning it, and pinning it turned out to be a different job from pinning the package.

The launcher is thin

dsh is a small commander-based launcher. It parses a few flags of its own, then hands the rest of the argv to a booted app that has its own parser. Almost nothing you care about is in the launcher.

That matters because dsh depends on its own family through caret ranges. Pin @deepseek-ai/dsh at an exact version and you still get @deepseek-ai/dsh-base and @deepseek-ai/dsh-headless at ^0.1.0-rc.6. The permission rows, which decide what the agent may touch, ship inside dsh-base as a patch layer. The parsing that decides whether your task text is a task or a flag lives in dsh-headless.

So the failure mode is quiet. Rebuild the image a week later, after either dependency publishes, and the behaviour of every run changes. Meanwhile dsh --version prints exactly the version you pinned, and every test that checks the version passes.

The fix is a build-time assert on the whole family rather than the launcher alone.

Two dashes, not one

The second thing cost an hour. Running a task by hand works the way the docs show:

dsh --profile headless "run the tests"

Send the same task through a runner that builds argv programmatically and it arrives as flags instead of a prompt. The launcher consumes one -- separator and the booted app consumes another, so a task passed positionally needs both:

dsh --profile headless -- -- "run the tests"

The reason this is worth writing down rather than shrugging at is the silent-success case. If the task text happens to begin with something that parses as a flag, you do not get an error. You get exit code 0, no output, and a run that did nothing. That is the worst shape a bug can have in an unattended pipeline, because nothing downstream notices.

What the sandbox actually does

The permission mode moves both the approval policy and the sandbox together, which is convenient right up until you assume the sandbox is doing something it is not. In our image it is not. The default confinement relies on bwrap, which is absent there, and on Landlock, which is unreadable in that context. On macOS the same setting confines through Seatbelt and genuinely does what it says.

So the honest description of a container run is that the confinement is advisory. That is fine when the container is the boundary you are relying on, which it is for us, but it is worth knowing which layer is actually holding the line rather than assuming it is the one named in the config.

Where this leaves it

None of this is a complaint about a package that has been public for a couple of days and says plainly that it is a developer preview. It is what a plugin architecture costs on the operations side: when everything is a plugin, the version number of the thing you installed stops describing the thing you are running.

If you want to try it without any of the above, it is npx and a key. If you want it to behave the same next month, assert the family.

Five things I disabled before installing a vendor's agent runtime

Zack Chew — Thu, 13 Aug 2026 08:08:31 +0000

Two services I connected recently both call the thing they ship a "skill". One is a hosted endpoint. The other is a zip file. The review those two need has almost nothing in common, and I do not think the word is doing anyone any favours.

Luckin Coffee runs an MCP server at their own domain. My agent sends JSON-RPC over HTTPS, and their code stays on their machines. The questions there are the familiar ones. What can it see, what scopes did I grant, can it spend my money.

Quark Drive, Alibaba's consumer cloud storage, ships a package instead. You download a zip, unpack Node scripts, and those scripts run inside your agent's process with your filesystem and your egress. The question is no longer what you granted. It is what that code does while it sits there.

Credit where it is due

Quark distributes the runtime from its own manifest and CDN, and authorization goes through an official OAuth endpoint scoped for agents. The token lands in the user's own instance and nobody proxies it.

That matters because the alternative, which I have also written adapters for, is scraping a website's internal endpoints and praying they do not rotate. A vendor that publishes a real package and a real OAuth flow is doing the right thing.

Which is exactly why it is worth reading the package instead of assuming.

What is inside is a CLI's habits

I unpacked version 1.0.11 and read it. What I found is what a desktop command line tool would reasonably ship.

Telemetry sampling is hardcoded at 1, so every event goes up. One call hands the raw user query to the telemetry client. Another reports a session id. The startup chain includes a self updater.

For a tool you open, use, and close, all four are defensible. Full-rate telemetry on a young product is how you find bugs. A self updater means users get fixes without being told to upgrade.

Now move the same code into a process that runs for months, holds a user's cloud storage token, and shares an address space with other skills.

The raw query stops being a search string. In an agent it is frequently the user's actual sentence, which carries filenames and people and reasons. And the self updater means the code you reviewed on Tuesday is not necessarily the code running on Friday. On a desktop that is a feature. For something holding a user's files, I would like to know when it changes.

What the install actually does

Version pinned at 1.0.11. Archive URL and SHA-256 both hardcoded. Download, hash, and abort on mismatch before anything is unpacked.

After unpacking, copy exactly two files, scripts/quark-drive.cjs and scripts/hash-worker.cjs, after asserting both exist. The upstream install.sh never runs.

Then five targeted edits to the runtime:

sampleRate:1 becomes sampleRate:0
the telemetry client constructor becomes a Proxy whose every method is a no-op
the setRawQuery call becomes a discard
the setSessionId call becomes a discard
the self updater is removed from the startup chain

A wrapper sits outside all of it and refuses update, --verbose, --session-input, --session-id and --raw-query with exit code 2. Execution goes through env -i so the child gets HOME, PATH, LANG, BROWSER=false, CI=1 and nothing else.

Upgrades stage into a temp directory, move the old tree aside, and roll it back if the swap fails. The user's existing config.json holds their OAuth token, so it is checked with lstat for being a regular file under 1 MiB before being copied forward, into a 700 directory at 600.

The part worth stealing

Every one of those five edits asserts an exact occurrence count before it applies. Three for the sampling pattern, one each for the rest. If the count is off, the install throws with the label and the number it actually found.

unexpected quark runtime: self updater (0)

Here is why that matters more than the edits themselves. When upstream refactors, a naive string replace matches nothing and reports success. The install completes, the tree looks right, and the telemetry and self updater are running exactly as they always were. You are now shipping a build you believe is hardened and is not.

Counting turns that silent success into a loud failure. I would rather the install break and make me read the new version than have it quietly hand me a false sense of what I disabled.

That generalizes past this package. Any time you patch someone else's code as part of a build, assert the shape you expected to find. A patch that no-ops is worse than a patch that fails, because only one of them tells you.

The question I ask now

Services decoupling from platforms is real. Capability ships as a skill, every agent can read it, and the aggregator in the middle stops being mandatory.

What changed underneath is where the integration lives. Calling someone's API and hosting someone's code are different risks wearing the same word. The worst case for the first is that you do not get your data. The worst case for the second is behaviour you did not ask for, running next to everything your agent can reach.

So the first thing I want to know about a new skill is whose machine it runs on. For a hosted endpoint, read the scopes and find out whether it can spend money. For a package, find out whether the self updater can be turned off, what it reports, and whether you can pin a version and verify it.

The Quark package works well once it is pinned. Search, upload, download, share and save all behave. Its AI summarization sends the selected file's contents back to Quark, which is the sort of thing a user should get to decide for themselves rather than discover later.

I run a small hosted service for agent bots and this is one of about 135 connectors we maintain, so I read a lot of these packages. openclawlaunch.com

Nous Portal, Explained: Plans, Models, Tools, and Hermes Cloud

Zack Chew — Sun, 02 Aug 2026 12:36:29 +0000

What is Nous Portal?

Nous Portal launched on April 27, 2026 as Nous Research’s subscription product for users who want to run Hermes Agent without managing API keys for every model and tool provider. One subscription replaces logins to a model gateway plus Firecrawl, FAL, Krea, Browser Use, OpenAI audio, and Modal — Portal routes all of those behind a single authenticated session. Since then it has also grown a hosting product, Hermes Cloud, covered below.

The free tier is $0/mo and carries $0 in monthly credits — it gives you the free-model catalog and standard rate limits only. Every paid tier adds a credit budget with a 10% bonus, the bundled Tool Gateway, and higher rate limits.

Portal plans

Free: $0/mo, $0 monthly credits (free models only), no rollover, 50 RPM / 500K TPM
Plus: $20/mo, $22 in credits, $10 rollover cap, 400 RPM / 4M TPM
Super: $100/mo, $110 in credits, $50 rollover cap, 800 RPM / 8M TPM
Ultra: $200/mo, $220 in credits, $100 rollover cap, 1,600 RPM / 16M TPM

You can also skip the subscription and top up credits directly (custom amount via Stripe); pay-as-you-go keys without a plan run at 180 RPM / 720K TPM. Plan details live on the Portal info page. Prices verified August 1, 2026.

Why Nous Portal Exists

Running a capable AI agent on your own infrastructure used to mean signing up for and paying multiple providers: a model provider (Anthropic, OpenAI), a web search provider (Tavily or Exa), an image generation provider (FAL), a TTS provider, and optionally a browser automation provider. Each one has its own dashboard, billing, and quota. For users who just want to run Hermes Agent and use it, that’s a lot of plumbing.

Nous Portal collapses that into one subscription. You pay one bill, you authenticate once, and Hermes Agent uses your Portal subscription to call models and tools automatically.

Self-host it, put it on Portal’s own Hermes Cloud, or deploy a managed Hermes Agent here in about 30 seconds — no VPS, no Docker, no credit minimum.

Deploy a Hermes agent

What’s Included

Models

Portal lists 248 models plus 29 embedding models — Anthropic Claude, OpenAI GPT, Google Gemini, Meta Llama, Mistral, DeepSeek, Qwen, xAI Grok, and Nous Research’s own Hermes series, among others. Nous states plainly on its own info page that this catalog is powered by OpenRouter, and the model links on the Portal site point at openrouter.ai. Worth knowing before you compare: for third-party models you are paying Portal to sit in front of OpenRouter, not to replace it.

Nous’s own models are the exception — Hermes-4.3–36B, Hermes-4–70B and Hermes-4–405B (128K context each) run on Nous’s own inference backend at inference-api.nousresearch.com/v1, which is OpenAI-compatible. That endpoint also supports x402 payments in Solana USDC (beta), which lets you make pay-per-request calls with no account and no API key at all.

Some models are free for Portal subscribers; others bill against your monthly credit budget.

Tool Gateway (paid tiers)

Paid Portal subscribers get automatic access to bundled tools, with no extra API keys needed:

Web search & scraping — Firecrawl, billed at $0.0005 per credit
Image generation — FAL (FLUX 2 Pro, Nano Banana Pro, Ideogram v3, Recraft v4, Qwen Image) and Krea, roughly $0.005-$0.26 per image
Video generation — FAL, covering Veo 3.1, Kling v3, Seedance 2.0, PixVerse v6 and LTX-2 ($0.0017-$0.44 per unit)
Speech in and out — OpenAI audio: Whisper transcription at $0.0063 per audio minute, plus GPT-4o transcribe and TTS billed per token
Browser automation — Browser Use at $0.0011 per session minute, plus $4.20/GB proxy bandwidth
Code execution — Modal sandboxes at $0.0495 per CPU-hour and $0.0084 per GiB-hour

These tools route through Nous Research’s gateway. Hermes Agent picks them up automatically when you authenticate with a Portal subscription, no per-tool config required. Every tool call bills against the same credit balance as your models, so a heavy image or video session eats the same budget your inference does.

xAI Grok integration (May 2026)

On May 15, 2026, Nous Research and xAI shipped a Grok integration that lets X Premium+ subscribers use their existing Grok subscription inside Hermes Agent — without paying separately for Grok API access. Grok 4.3, Grok TTS, and Grok Imagine all become available through the OAuth flow. See the launch coverage for details, or the upstream xAI Grok OAuth guide.

Hermes Cloud — Nous now hosts the agent too

The biggest change since Portal launched: it is no longer only a key-and-credits product. Hermes Cloud deploys a hosted Hermes Agent on a dedicated instance with its own workspace and dashboard, billed hourly from your Nous credit. It is currently in preview.

You pick a size, and the instance price covers compute and storage only — inference and tool usage bill separately on top:

Small: 1GB RAM, 2 vCPU, 5 concurrent sessions. $0.29/day running (about $8.70/mo), $0.03/day stopped
Medium: 2GB RAM, 4 vCPU, 10 concurrent sessions. $0.56/day running (about $16.80/mo), $0.03/day stopped
Large: 4GB RAM, 8 vCPU, 20 concurrent sessions. $1.09/day running (about $32.70/mo), $0.03/day stopped

Stopping an instance drops it to the storage-only rate and keeps your data, so an idle agent costs about $0.90/mo to keep alive. Deploying requires an active subscription or a credit balance — the Cloud page states a $10 minimum, while the info page’s getting-started steps say $2, so budget for the higher number. Nous picks the region closest to you from Amsterdam, Stockholm, Mumbai, Paris, Dallas, Frankfurt, Los Angeles, London, Tokyo, Chicago, Singapore, San Jose, Sydney and Toronto.

Feature-wise it is what you would expect from a first-party host: one-click deploy, natural-language scheduling, Telegram / Discord / Slack / email / CLI channels against one shared memory, and an isolated hardened container per agent. On billing, the one rule Nous states unambiguously is the two-rate split: you pay the running rate while the instance is on and the storage rate while it is stopped.

Watch: Nous Portal in 90 seconds

One note before you watch: this was recorded in July 2026, when Portal advertised a 300+ model catalog and five Tool Gateway backends. Nous has since restated the catalog as 248 models and added a sixth backend (Modal sandboxes) plus Hermes Cloud. The walkthrough of the setup flow is still accurate; the numbers above it are the current ones.

https://www.youtube.com/watch?v=VvkBFyF14kk

How to Connect Nous Portal to Hermes Agent

Two paths, depending on whether you’re self-hosting Hermes Agent or running it on managed infrastructure.

Self-hosted Hermes

Subscribe at portal.nousresearch.com
Generate a Portal API key from the dashboard
In Hermes Agent, run hermes with no arguments to enter interactive setup, or edit your config.yaml
Select Nous Portal as the provider and paste the API key
Hermes will list available models from your subscription — pick your default

Once configured, the Tool Gateway features (search, image gen, TTS, browser) are picked up automatically — you don’t need separate API keys for Firecrawl, FAL, or Browser Use anymore.

Do You Actually Need Portal?

Depends on where Hermes runs.

You self-host Hermes

Portal is worth it. One login replaces a model provider, Firecrawl, FAL, a TTS key and Browser Use — and the Tool Gateway comes with it. The setup steps are above.

You’d rather not run a server

You now have two managed options, and it is worth being straight about that. Hermes Cloud is Nous’s own, from $0.29/day plus inference — the tightest possible integration with Portal, though it is in preview and you need a credit balance or a subscription before you can deploy anything. OpenClaw Launch’s Hermes hosting is the alternative: deploy in about 30 seconds with no credit minimum and no card for the free trial, run either Hermes Agent or OpenClaw from the same account, and reach channels Hermes Cloud doesn’t list — WhatsApp and WeChat included. Bring a Portal key if you want, or use our managed models and skip Portal entirely.

Nous Portal vs OpenRouter vs Per-Provider Keys

Nous Portal

Pros: One auth; bundled tools; free models for subscribers; tight Hermes integration

Cons: Locked to Nous as the gateway; routing markup on paid model calls

OpenRouter

Pros: One API key for 300+ models; granular per-model spend control; it is what Portal routes third-party models through anyway

Cons: No bundled tools (search / image / video / speech / browser need separate keys)

Per-provider keys

Pros: Direct billing relationship; no gateway markup; full provider features

Cons: 5+ separate sign-ups, dashboards, and bills to manage

The right answer depends on shape of usage. For a single user running Hermes full-time, Nous Portal’s bundled tools usually win on convenience. For teams running production agents at scale, direct provider keys often come out cheaper.

Frequently Asked Questions

Is Nous Portal free?

There is a free tier, but be clear on what it gives you: $0/mo with $0 in monthly credits, capped at 50 RPM / 500K TPM, and limited to the free-model catalog. It is not a trial of the paid product — the Tool Gateway and the paid model catalog both sit behind a subscription or a credit top-up. Plus at $20/mo is the real entry point, and it returns $22 in credits.

Do I need a Nous Portal subscription to use Hermes Agent?

No. Hermes Agent is open source and free; you can run it with any provider you like — OpenRouter, direct Anthropic / OpenAI / Google keys, local models via Ollama, or Nous Portal. Portal is one option among many, not a requirement.

What models are free on Nous Portal?

Nous Research rotates a list of free-for-subscribers models, typically including their own Hermes model series and select open-weight models from other labs. The current list is in the Portal dashboard — it changes from month to month.

Can I use my X Premium+ Grok subscription with Hermes through Portal?

Yes, since May 15, 2026. The xAI Grok OAuth flow connects your existing X Premium+ subscription to Hermes Agent, giving you Grok 4.3, Grok TTS, and Grok Imagine without separate API billing. See the upstream OAuth guide.

What is Hermes Cloud, and how is it different from a Portal subscription?

A Portal subscription buys models, tools and credits. Hermes Cloud is the hosting layer on top: it runs the agent itself on a Nous-managed instance, billed hourly from the same credit balance, from $0.29/day for the Small size plus whatever inference and tools you use. You can hold a Portal subscription without ever using Hermes Cloud — plenty of people just point a self-hosted Hermes at their Portal key.

Is Hermes Cloud cheaper than managed Hermes hosting elsewhere?

On the instance line alone it looks inexpensive, but compare the whole bill. Hermes Cloud’s day rate excludes inference and tool usage, and you need a credit balance or an active subscription before you can deploy at all. It is also still in preview. If you want to try managed Hermes without funding a balance first, our Hermes hosting has a free trial and no credit minimum — and you can compare the two honestly from there.

Does OpenClaw Launch support Nous Portal?

OpenClaw Launch’s Hermes hosting runs Nous Hermes models on managed OpenClaw infrastructure today via OpenRouter — no Portal key needed. Native Hermes Agent framework hosting is also live today — pick Hermes as your framework in the configurator and deploy in about 30 seconds.

Originally published at openclawlaunch.com/guides/nous-portal, where it is kept up to date.