#nous auth dont work

1 messages · Page 1 of 1 (latest)

simple sonnet
#

rakaarwaky@raka:~$ hermes model

Current model: xiaomi/mimo-v2-pro
Active provider: Nous Portal

Showing 1 curated models — use "Enter custom model name" for others.
Select default model:
In Out Cache /Mtok

xiaomi/mimo-v2-pro free free free ← currently in use
Enter custom model name
Skip (keep current)

Choice [1-3] (default: skip): 1
Default model set to: xiaomi/mimo-v2-pro (via Nous Portal)

this is not working on me

⚠ API call failed (attempt 1/3): BadRequestError [HTTP 400]
🔌 Provider: nous Model: xiaomi/mimo-v2-pro
🌐 Endpoint: https://inference-api.nousresearch.com/v1
📝 Error: HTTP 400: This request is not valid. Check the model name and other parameters. Additional info: Provider returned error
📋 Details: {'status': 400, 'message': 'This request is not valid. Check the model name and other parameters. Additional info: Provider returned error'}
⚠ Non-retryable error (HTTP 400) — trying fallback...
❌ Non-retryable error (HTTP 400): HTTP 400: This request is not valid. Check the model name and other parameters. Additional info: Provider returned error
❌ Non-retryable client error (HTTP 400). Aborting.
🔌 Provider: nous Model: xiaomi/mimo-v2-pro
🌐 Endpoint: https://inference-api.nousresearch.com/v1
💡 This type of error won't be fixed by retrying.
─ ⚕ Hermes ─────────────────────────────────────────────────────────────────────

Error: Error code: 400 - {'status': 400, 'message': 'This request is not
valid. Check the model name and other parameters. Additional info: Provider
returned error'}

slim ivy
#

Please send /debug from the profile that is failing.

The model selection itself looks fine from what you pasted, so the next step is the actual request/response log for the failing turn. That will tell us whether this is a bad runtime credential, a bad request shape, or a provider-side validation error coming back from the Nous endpoint.

simple sonnet
slim ivy
#

This does not look like a Nous login failure.

Your dump already shows Hermes is configured on provider: nous and repeatedly reaching https://inference-api.nousresearch.com/v1, but the actual agent turn is being rejected with the same non-retryable HTTP 400 every time:

This request is not valid. Check the model name and other parameters. Additional info: Provider returned error

So the next issue is not “Hermes is not logged into Nous.” It is “the Nous backend is rejecting the request shape Hermes is sending for that turn.”

Also, api_keys.nous: not set is expected here for Nous Portal OAuth. Hermes uses Portal auth + a short-lived agent key, not a static NOUS_API_KEY env var.

Please send the newest request dump from the failed turn so we can see the exact payload field the provider is rejecting:

ls -t ~/.hermes/sessions/request_dump_*.json | head -1

and then send that file.

There are also a couple of separate issues in your logs that are not the main Nous 400, but are worth fixing separately:
your Telegram/Discord tokens are invalid in the gateway logs,
and Hermes is hitting OSError: [Errno 5] Input/output error on ~/.hermes/skills/research/research-paper-writing/SKILL.md.

For this thread though, the thing we need next is the latest request_dump_*.json, because that will tell us exactly what the Nous endpoint is rejecting.

simple sonnet
#

Hermes telegram work. Cli dont work well

I ask telegram hermes about what happen. And tgis is the answers

Here's the Discord message to send:

Bug: HTTP 400 on xiaomi/mimo-v2-pro via Nous Portal OAuth

Hey team, I'm getting consistent HTTP 400 errors when using xiaomi/mimo-v2-pro through Hermes CLI with Nous Portal OAuth auth.

Error:
HTTP 400: This request is not valid. Check the model name and other
parameters. Additional info: Provider returned error

Setup:

What I found in the request dump:

The request body includes extra_body.reasoning:
"extra_body": {
"reasoning": { "enabled": true, "effort": "medium" },
"tags": ["product=hermes-agent"]
}

My hypothesis is that the Nous inference backend doesn't accept the reasoning parameter for mimo-v2-pro and rejects the entire request with 400 instead of ignoring the unsupported field.

Request dump file:
~/.hermes/sessions/request_dump_20260415_091928_201a5f_20260415_091933_849008.json

Key fields from the dump:

  • Auth header: Bearer sk-uud4j...vvsw (valid agent_key, not expired)
  • Model: xiaomi/mimo-v2-pro
  • Messages: simple system + user ("halo")
  • Tools: ~100+ function definitions attached
  • Extra body includes reasoning: {enabled: true, effort: "medium"}

Question: Is reasoning supported for mimo-v2-pro on the inference API? If not, could the backend ignore unsupported params instead of returning 400?

warm plume
#

@harsh current Still havent determined if this is my side, your side, or xiaomi's side 😄

#

related issue as well

simple sonnet
#

i ask hermes to selfdebug here hte result . cli work well rn

Summary: HTTP 400 on xiaomi/mimo-v2-pro — resolved as transient Nous infrastructure issue

What happened:
Hermes CLI was consistently failing with HTTP 400 when calling xiaomi/mimo-v2-pro through Nous Portal OAuth auth, while the Telegram gateway appeared to work.

Error:
HTTP 400: This request is not valid. Check the model name and other
parameters. Additional info: Provider returned error

Debugging steps:

  1. Verified Hermes auth — Nous Portal OAuth with device_code flow. Access token and agent_key were both present and valid. Not an auth issue.

  2. Checked the request dump at ~/.hermes/sessions/request_dump_*.json — the CLI was sending reasoning: {enabled: true, effort: "medium"} in extra_body. Initial hypothesis was that mimo-v2-pro doesn't support reasoning params, causing the 400.

  3. Verified _supports_reasoning_extra_body() in run_agent.py — it unconditionally returns True for all Nous Portal URLs without checking the model name. This looked like the root cause.

  4. Compared upstream NousResearch/hermes-agent with the local fork — code is identical. Confirmed this is not a fork-specific issue.

  5. Compared CLI vs Gateway request dumps — both had identical extra_body (reasoning + tags), same model, same auth. The gateway was ALSO failing with HTTP 400 during the same time window.

  6. Checked all request dumps from the outage window (~08:35–09:19 WIB / 01:35–02:19 UTC on 2026-04-15):

    • CLI: 400
    • Gateway: 400
    • Cron: 400
    • All with the same error, same request shape

  7. Issue resolved itself around 11:20 WIB with no code or config changes on our side. CLI started working normally.

Conclusion:
This was a transient issue on the Nous inference API backend, not a Hermes bug. All request paths (CLI, gateway, cron) were affected equally during the outage window and recovered simultaneously.

harsh current
#

Weird. If you're getting a 400 back, that not a sign of inference issue - that's something wrong with the API request. I wonder what was up. Possibly the session was corrupted somehow? I can take a look at the logs when I'm back at a computer.

harsh current
#

So, trawling through the logs, all I can say for sure is that we were getting malformed inference requests, and the API rejected them. I'm not sure how that could happen in Hermes Agent, but I would guess starting a new conversation/session would fix it.

warm plume
#

@simple sonnet can you go to your ~/.hermes/sessions directory and take the latest file in there that starts with request_dump

#

and then share it here

#

if not, run hermes debug share or /debug in the messenger you talk to it with, and share the links you get

simple sonnet
# warm plume <@395559919597649933> can you go to your `~/.hermes/sessions` directory and take...

{
"timestamp": "2026-04-15T09:19:33.848989",
"reason": "non_retryable_client_error",
"request": {
"url": "https://inference-api.nousresearch.com/v1/chat/completions",
"body": {
"model": "xiaomi/mimo-v2-pro",
"messages": [{"role":"system","content":"..."}, {"role":"user","content":"halo"}],
"tools": [38 tool definitions],
"extra_body": {
"reasoning": {"enabled": true, "effort": "medium"},
"tags": ["product=hermes-agent"]
}
}
},
"error": {
"status_code": 400,
"message": "This request is not valid. Check the model name and other parameters. Additional info: Provider returned error"
}
}

warm plume
#

I think cthulu went to bed, but we will resolve asap when he's back 🙂

simple sonnet
#

no problem. now hermes cli is running smoothly i also don't understand how hermes from telegram repairs itself

warm plume