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.

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:
- One setup command wires it.
hermes chat --setup nousopens 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 manualprovider.<name>.api_keypaste. - The model strings are Nous-namespaced.
Hermes-4-70BandHermes-4-405Bresolve directly; there is no<vendor>/<model>prefix because no aggregator sits in between. The numbers are parameter counts in billions; the-Bis 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:
| Model | Parameters | Use for | Speed floor |
|---|---|---|---|
Hermes-4-70B | 70 billion | Default daily work; drafting, code review, summaries | Fast on the Portal tier |
Hermes-4-405B | 405 billion | Long-context reasoning, structured-output that drifts on smaller models, the “thinking chain” jobs | Slower; 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:
- 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.
- 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 --billingafter 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
nousnorminimaxadds a routing hop. The request goes from Hermes to the vendor’s servers directly. The difference is the auth mechanism:minimaxuses a raw API key the operator manages;noususes the Portal’s OAuth/device-flow exchange and stores the credential in~/.hermes/credentials/. - Model strings are vendor-literal.
MiniMax-M3is MiniMax’s only direct alias;Hermes-4-70BandHermes-4-405Bare Nous’s only direct aliases. There is no<vendor>/namespace on either. If you find yourself typingnous/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.nousonly resolvesHermes-4-70BandHermes-4-405B. There is no Nous-routed Claude or Nous-routed Gemini on this path — those are not whatnousis. To reach other vendors through one credential, useprovider.openrouterand 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 onnousfails 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
openrouterahead ofnousfor 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-405Bwithout testing latency first — the 3-5x slowdown vsHermes-4-70Bis 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
| # | Command | What it proves |
|---|---|---|
| 1 | hermes chat --setup nous (or re-run to refresh) | Portal credential is live |
| 2 | hermes config show --provider nous | nous is in the configured list |
| 3 | hermes chat --provider nous --model Hermes-4-70B -q "Reply with OK" | 70B resolves and answers |
| 4 | hermes 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 token | Credential persisted, not just in-memory |
| 6 | provider_fallback[0] is nous | Direct path configured (not OpenRouter-routed) |
Sources
- Hermes Agent providers
- Nous Portal
- Hermes CLI commands reference
- ABS companion: Hermes Agent Provider: MiniMax M3 (Direct, Not Via OpenRouter)
- ABS companion: Hermes Agent Provider: OpenRouter for Cross-Vendor A/B Tests
- ABS companion: Hermes Agent: Switching Providers Mid-Run When a Provider Fails
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.



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.