guide · ai

Hermes Agent Provider: Nous Portal (Hermes-4-70B, Hermes-4-405B, First-Class)

Wiring the first-class nous provider on Hermes v0.18.2 — hermes chat --setup nous, the Portal OAuth/API-key exchange, Hermes-4-70B and Hermes-4-405B, and how it differs from MiniMax and OpenRouter.

July 14, 2026 · By Alastair Fraser

A retro robot at a small kiosk labeled NOUS PORTAL holding two model cards — one tagged HERMES-4-70B, one tagged HERMES-4-405B — with a Free Tier sign and a small meter ticking toward Metered.

What “first-class nous” means in v0.18.2

Hermes v0.18.2 (2026.7.7.2) ships with a dedicated nous provider — not a generic OpenAI-compatible stub, not an aggregator hand-off, not a community plugin. It is the Hermes research team’s own model family, served through the Nous Portal, registered in the same way as minimax or anthropic. Two practical consequences:

  1. One setup command wires it. hermes chat --setup nous opens the Portal exchange (browser OAuth on most desktops, copy/paste device-flow on headless boxes), pulls the model catalog, and writes the credential to ~/.hermes/credentials/nous.json. No env file, no manual provider.<name>.api_key paste.
  2. The model strings are Nous-namespaced. Hermes-4-70B and Hermes-4-405B resolve directly; there is no <vendor>/<model> prefix because no aggregator sits in between. The numbers are parameter counts in billions; the -B is literal.

This guide documents the working setup on the operator’s VPS as of 2026-07-14.

Step 1: run the setup command

hermes chat --setup nous

On a desktop the command opens a browser to https://portal.nousresearch.com/, completes the OAuth round-trip, and returns a token. On a VPS or any headless host, the command prints a URL and a short code instead — paste the URL into a laptop browser, approve, then paste the resulting token back into the terminal prompt. Both paths end at the same place: a credential stored locally and a prompt asking which model to pin as default.

If the command reports “browser failed to launch,” set --no-browser and use the device-flow path. If it reports “callback port already in use,” another Hermes session is mid-auth — wait it out, then retry.

Step 2: pick the model

The Portal exposes two models today:

ModelParametersUse forSpeed floor
Hermes-4-70B70 billionDefault daily work; drafting, code review, summariesFast on the Portal tier
Hermes-4-405B405 billionLong-context reasoning, structured-output that drifts on smaller models, the “thinking chain” jobsSlower; pay for it in latency

Pick Hermes-4-70B unless you have a specific reason to need 405B’s longer reasoning — the size gap shows up as 3-5x slower first-token time on the same prompt. The CLI prompts for the default during setup; change it later with hermes config set provider.nous.default_model "Hermes-4-70B" (or "Hermes-4-405B").

Step 3: verify

hermes chat --provider nous --model Hermes-4-70B -q "Reply with OK"
hermes chat --provider nous --model Hermes-4-405B -q "Reply with OK"

Both replies should arrive in under a few seconds on a healthy Portal tier. A 401 means the OAuth token expired — re-run hermes chat --setup nous to refresh. A 404 on the model name almost always means a typo (hermes-4-70b lowercase fails; the canonical form is mixed-case with a literal -B).

The cost tier

The Nous Portal runs two phases on a single credential:

  1. Early-access free tier. While the provider is in early access, requests are unmetered and rate-limited only by fairness (a generous per-minute token budget, no daily cap). This is the window most operators will set up in.
  2. Metered tier. Once early access closes, the same credential moves to per-token billing. The rate card is published on the Portal; Hermes surfaces it in hermes config show --provider nous --billing after the cutover.

The cost line in this post is Free during early-access; metered per-token after — that’s the only honest summary until the cutover date lands. Watch the Portal changelog; the migration is credential-preserving, so no re-setup is required when billing flips on.

How nous differs from MiniMax

MiniMax on this install is wired through provider.minimax, with the key pasted into /opt/data/.env and the model string MiniMax-M3 typed by hand. The two routes are similar in shape but different in plumbing:

  • Built-in, not an aggregator. Neither nous nor minimax adds a routing hop. The request goes from Hermes to the vendor’s servers directly. The difference is the auth mechanism: minimax uses a raw API key the operator manages; nous uses the Portal’s OAuth/device-flow exchange and stores the credential in ~/.hermes/credentials/.
  • Model strings are vendor-literal. MiniMax-M3 is MiniMax’s only direct alias; Hermes-4-70B and Hermes-4-405B are Nous’s only direct aliases. There is no <vendor>/ namespace on either. If you find yourself typing nous/Hermes-4-70B, you’ve slipped into OpenRouter syntax — wrong provider, different cost.
  • Rate limits and quotas live in different places. MiniMax usage is on the MiniMax dashboard; Nous usage is on the Portal. The two never share a quota.

If the operator’s preferred default is “the cheapest reliable path for ordinary chat,” the choice between nous and minimax is currently “free Portal tier vs per-token MiniMax” — which makes nous the default during early access, and likely a strong second after.

How nous differs from OpenRouter

OpenRouter is an aggregator that fronts many vendors under one key. The nous provider is the opposite shape:

  • One provider, one model family. provider.nous only resolves Hermes-4-70B and Hermes-4-405B. There is no Nous-routed Claude or Nous-routed Gemini on this path — those are not what nous is. To reach other vendors through one credential, use provider.openrouter and the <vendor>/<model> namespace.
  • No aggregator markup. Direct is direct. There is no ~5% per-token surcharge layered on top of the Portal price; the cost line is whatever the Portal publishes.
  • Auth is Portal-native. OpenRouter wants a raw sk-or-... key; Nous wants the OAuth/device-flow exchange. The two credential stores do not interop. Reusing an OpenRouter key on nous fails with a clean “credential type mismatch” error — that is the intended behavior.

Use nous for daily work on Hermes-4; use openrouter for cross-vendor A/B tests where the model string is the question. The two providers belong at different positions in the fallback chain.

What to put in the fallback chain

A reasonable chain on this install, with nous as the early-access default:

provider_fallback:
  - nous          # Hermes-4-70B / Hermes-4-405B via Portal
  - minimax       # direct MiniMax-M3 (per-token)
  - openrouter    # aggregator (last resort, cross-vendor)
  - ollama_local  # network-disconnected fallback

nous first while the free tier is unmetered. minimax second because direct is cheaper than the aggregator. openrouter third because its slot is reserved for cross-vendor routing, not for reaching MiniMax or Nous. ollama_local last because when every public API is unreachable, the local model still answers — slowly, but it answers.

What not to do

  • Don’t reuse an OpenRouter key on provider.nous — the credential types do not match.
  • Don’t type the model strings lowercase (hermes-4-70b) or with an aggregator prefix (nous/Hermes-4-70B) — both fail.
  • Don’t put openrouter ahead of nous for ordinary work while the Portal free tier is live — that is a surcharge you don’t need.
  • Don’t run a production cron against Hermes-4-405B without testing latency first — the 3-5x slowdown vs Hermes-4-70B is real.
  • Don’t store the Portal token outside ~/.hermes/credentials/nous.json; rotating it requires the same setup command, not a manual edit.

Verification checklist

#CommandWhat it proves
1hermes chat --setup nous (or re-run to refresh)Portal credential is live
2hermes config show --provider nousnous is in the configured list
3hermes chat --provider nous --model Hermes-4-70B -q "Reply with OK"70B resolves and answers
4hermes chat --provider nous --model Hermes-4-405B -q "Reply with OK"405B resolves and answers
5~/.hermes/credentials/nous.json exists with a non-empty tokenCredential persisted, not just in-memory
6provider_fallback[0] is nousDirect path configured (not OpenRouter-routed)

Sources

Last verified: 2026-07-14 against Hermes v0.18.2 (2026.7.7.2) on the senior-dev profile. Live models: Hermes-4-70B (default), Hermes-4-405B (manual pin). Re-run hermes --version before following a flag whose number may have shifted.

Sources

#hermes#nous#nous-portal#Hermes-4-70B#Hermes-4-405B#provider#first-class#free-tier

Submit a take

Have a different read on this? Drop a comment below — your email isn't published, and I read every one. Nothing leaves the site until I approve it.

Your email address will not be published. Required fields are marked.