# Nous Portal support is broken in v0.5.1 — no UI to add API key, dropdown selection silently fails, credential pool saves with wrong schema

[iandabeast333]

Nous Portal support is broken in v0.5.1 — no UI to add API key, dropdown selection silently fails, credential pool saves with wrong schema

TL;DR

The Providers tab lists "Nous Portal" in the inference-provider dropdown, but offers no working way for a user to authenticate it from the UI:

• No API Key card for Nous Portal in the LLM Providers section.
• No Sign in card for Nous Portal in the Subscription / OAuth Plans section.
• The Credential Pool dropdown does include "Nous Portal", but when a key is added it writes a malformed schema that the gateway can't consume.
• Selecting "Nous Portal" from the inference provider dropdown writes model.provider: "nous" to config.yaml (the OAuth variant) — so the gateway proceeds to run, the user starts chatting, and only then sees Hermes is not logged into Nous Portal. Run hermes model to re-authenticate.

The end result is that a non-technical user can't get Nous Portal working through the desktop UI at all on Windows. The only fix is to drop into PowerShell and edit .env / run hermes auth add nous by hand.

Environment

• Hermes Desktop: v0.5.1
• Hermes Engine: v0.14.0 (released 2026-05-16)
• OS: Windows 11
• Python: 3.11.15 (bundled with engine)
• Profile home: C:\Users\<user>\Desktop\Hermes\profiles\<profile> (HERMES_HOME points to a profile dir, not ~/.hermes)

Bugs (in priority order)

1. Missing "Nous Portal API Key" card in LLM Providers section

The engine plugin at plugins/model-providers/nous/__init__.py declares:

nous = NousProfile(
    name="nous",
    aliases=("nous-portal", "nousresearch"),
    env_vars=("NOUS_API_KEY",),
    ...
)

NOUS_API_KEY is also referenced by hermes_cli/doctor.py, hermes_cli/dump.py, and several test files — it's a first-class env-var-based credential. The Credential Pools doc on the Hermes website (/user-guide/features/credential-pools) explicitly says:

"For providers that support both API keys and OAuth (Anthropic, Nous, Codex), the add flow asks which type."

But in OfficeSpace v0.5.1, scrolling the entire Providers tab shows API key cards for ~22 providers (OpenRouter, OpenAI, Anthropic, Groq, z.ai, Kimi/Moonshot, MiniMax, OpenCode Zen/Go, Hugging Face, DeepSeek, Together AI, Fireworks, Cerebras, Mistral, Perplexity, NVIDIA, Custom, Google AI Studio, xAI Grok…) — none of which is Nous Portal. There is no UI to set NOUS_API_KEY.

2. Missing "Nous Portal" card in Subscription / OAuth Plans section

The OAuth section has cards for ChatGPT (Codex Plan), xAI Grok (OAuth), Qwen (OAuth), Gemini (CLI OAuth), and MiniMax (OAuth). Inspecting the bundled renderer JS confirms OAUTH_PROVIDERS only contains those five entries — Nous Portal is omitted, despite having auth_type="oauth_device_code" registered in hermes_cli/auth.py::PROVIDER_REGISTRY.

This means a user with a Nous Portal subscription has no UI button to trigger the OAuth login flow either. They have to drop to PowerShell and run hermes auth add nous --type oauth manually.

3. Credential Pool saves Nous keys with the wrong schema

The Credential Pool does expose Nous Portal in its dropdown, so users gravitate to it as the only visible Nous-related input. After adding a key, the resulting auth.json looks like this:

{
  "version": 1,
  "providers": {},
  "credential_pool": {
    "nous": [
      {
        "key": "sk-nous-...",
        "label": "Key 1"
      }
    ]
  }
}

Compare to a correctly-saved entry (auto-seeded from OPENROUTER_API_KEY):

{
  "id": "cc23e6",
  "label": "OPENROUTER_API_KEY",
  "auth_type": "api_key",
  "priority": 0,
  "source": "env:OPENROUTER_API_KEY",
  "access_token": "sk-or-v1-...",
  "base_url": "https://openrouter.ai/api/v1",
  "request_count": 0,
  "last_status": null,
  ...
}

Differences:

• API key field is named key instead of access_token → the engine's credential resolver (hermes_cli/auth.py::resolve_nous_runtime_credentials and credential pool entry parsing) reads access_token and finds nothing.
• No auth_type field, so the engine can't distinguish API-key entries from OAuth entries inside the same nous pool.
• No base_url, no id, no priority, no source, no request_count, no status fields. The pool entry is missing every metadata field used for rotation, telemetry, and error backoff.
• Stored under provider id "nous" (whose engine auth_type is "oauth_device_code"). Even if the entry were complete, it would conflict with the OAuth path. Per setup.py, the API-key variant is "nous-api" (display name "Nous Portal API key").

Net effect: when the gateway looks for credentials for model.provider: "nous", it finds the malformed entry, can't parse it, and falls through to the OAuth path → "Hermes is not logged into Nous Portal."

4. Selecting "Nous Portal" from the provider dropdown silently mis-configures the profile

The Provider dropdown in the MODEL card of the Providers tab includes "Nous Portal". Picking it writes:

# config.yaml
model:
  provider: "nous"

There's no follow-up dialog that says "you've picked Nous, now sign in" or "set NOUS_API_KEY". The user assumes the dropdown also handles authentication (because that's how every other provider in this UI works) and the failure mode is invisible until they try to chat.

A non-technical user on Windows hits this exact sequence:

1. Opens Providers tab. Picks Nous Portal in the dropdown. Picks a model. Closes the page.
2. Pastes their sk-nous-... key into the only field labeled "Nous Portal" — the credential pool dropdown.
3. Sees "Key 1: sk-nous-...d0xe" appear with a "Remove" button. Assumes setup is complete.
4. Goes to Chat. Sees Internal server error: Hermes is not logged into Nous Portal. Run hermes model to re-authenticate.
5. Has no clue why, because the UI told them they were done.