Hermes Agent System Requirements: Can I Run It On This Machine?

NousResearch publishes a resource table in the Docker guide, and it is refreshingly small: 1 GB of memory minimum with 4 GB recommended, 1 CPU core minimum with 2 recommended, and 500 MB on the data volume with 2 GB or more recommended because sessions and skills pile up. One caveat is called out explicitly: browser automation through Playwright and Chromium is the most memory hungry feature, and with browser tools active you should allocate at least 2 GB.

The toolchain is handled for you. On Linux and macOS the only prerequisite is Git, plus curl and xz-utils on Linux since the installer downloads Node as a compressed archive. The installer then places Python 3.11 through uv and Node.js v22 for the browser and WhatsApp tooling. Supported targets are Linux, macOS, WSL2, native Windows and Android through Termux. If you plan to build the desktop app you also need g++ or build-essential for the native modules.

This is the half of the hermes agent system requirements picture that most write ups cover, and if you are pointing the agent at a hosted provider it is the whole story. The reason it feels too easy is that it is: the framework is an orchestration loop around somebody else's inference. All the weight sits in the second floor.

Source: NousResearch Hermes Agent Docker resource limits and the installation prerequisites.

Hermes Agent requires a model with at least 64,000 tokens of context, and models below that are rejected at startup rather than degraded. The stated reason is that the system prompt, tool schemas and working conversation state need room before multi step tool calling is reliable. Hosted models clear it without anyone noticing. On your own hardware it changes the arithmetic completely, because context is not free: it is a KV cache, and the cache scales linearly with the window.

Work it through on the 8B. Every Hermes model published so far uses grouped query attention with 8 key value heads and a head dimension of 128, so one token costs 2 (for K and V) times the layer count times 8 times 128 times 2 bytes at fp16. The 8B has 32 layers, which is 128 KB per token. Multiply by 64,000 and the cache alone is 8.39 GB. The Q4_K_M weights are 4.92 GB. The cache is bigger than the model.

That single fact reorders the usual advice. An RTX 4060 with 8 GB looks like it should host a 4.92 GB file comfortably, and it would, right up to the point where the agent asks for its mandatory window and the card runs out. This is why the checker above refuses to report a fit based on file size, and why it reports the total working set instead. A model that loads but cannot serve 64K is a model Hermes will not run.

There is one honest lever. llama.cpp can store the cache at 8 bit with --cache-type-k q8_0, which halves the KV term for a small quality cost. The precision switch in the checker applies it, and on borderline machines it is often the difference between a fit and an offload.

Source: the 64K minimum is stated in the Hermes Agent quickstart and repeated in the provider setup guide.

This one catches people who did everything right. Ollama does not serve a model's full context window by default. It picks a size from available VRAM: under 24 GB you get 4,096 tokens, from 24 to 48 GB you get 32,768, and only at 48 GB and above does it open up to 256,000. Since Hermes needs 64,000, every consumer card below 24 GB lands in the rejected bucket by default, and so does a 24 GB card even though 32,768 sounds generous.

The trap is that the fix is not where you would look for it. Context length cannot be set through the OpenAI compatible endpoint that Hermes talks to, so no amount of editing the agent config helps. It has to be set on the Ollama server: start it with OLLAMA_CONTEXT_LENGTH=64000, add that variable to the systemd unit, or write a Modelfile with a num_ctx parameter and create a derived model. Running ollama ps and reading the CONTEXT column is the quickest way to confirm it took.

Worth noting the interaction with everything above: raising the window to 64K is what creates the large KV cache in the first place. You cannot dodge it by leaving the default in place, because then the agent will not start. That is precisely why the checker treats 64K as fixed rather than as a slider.

Source: Hermes Agent provider guide, Ollama section.

The published half of the hermes agent system requirements is transcribed, not modelled. Those numbers come from the resource table in the Hermes Agent Docker guide and the prerequisites list in the installation guide, both linked above, and we changed nothing.

Model weights are the exact file sizes shown on each Hugging Face repo, not estimates from a bytes per parameter rule. We fetched the file listings directly so that a Q4_K_M row reads 4.92 GB rather than a rounded guess.

The KV cache term is derived. For each model we read num_hidden_layers, num_key_value_heads and head_dim from its config.json, then applied the standard formula: 2 for the key and value tensors, times layers, times key value heads, times head dimension, times 64,000 tokens, times 2 bytes at fp16 or 1 byte at q8_0. Every published Hermes model turns out to use 8 key value heads and a head dimension of 128, so the layer count is what separates them.

One number is ours rather than anyone's published figure, and we would rather say so than bury it: the flat 1 GB runtime buffer added to each row. It stands in for the llama.cpp compute buffer and loader headroom, both of which vary with batch size and backend. Treat rows within a gigabyte of your capacity as uncertain, and prefer the q8_0 cache setting if you are that close.

What this checker deliberately does not do: predict tokens per second, price hardware, or estimate a cloud breakeven. Throughput depends on memory bandwidth and backend choices we cannot see from here. If you want the procurement side of the question, the self hosted AI hardware calculator covers GPU picks, power draw and breakeven months.