[Bug]: MoA + OpenRouter Free-Tier — model name gets silently shortened, encoded prompts > ~1000 chars arrive empty, and hermes-agent pins a vulnerable cryptography version

[Cole666hs]

Bug Description

Found three related bugs while testing the v0.18 MoA feature (hermes moa) with OpenRouter free-tier models on hermes-agent v0.18.2 (2026.7.7.2). Two are upstream, one is in the MoA runtime. All three together make MoA effectively unusable with anything except the default preset.

Bug 1: Model name gets silently shortened when MoA references OpenRouter Free-Tier nemotron models

Steps to reproduce

1. Set up an OpenRouter provider in ~/.hermes/config.yaml:

   providers:
     openrouter:
       api_key: sk-or-v1-...
       base_url: https://openrouter.ai/api/v1

2. Add a MoA preset that references a newer nemotron Free-Tier model:

   moa:
     active_preset: diverse-quality
     presets:
       diverse-quality:
         enabled: true
         reference_models:
           - {provider: minimax, model: MiniMax-M3}
           - {provider: openrouter, model: nvidia/nemotron-3-ultra-550b-a55b:free}
         aggregator: {provider: minimax, model: MiniMax-M3}

3. Encode and submit via the __HERMES_MOA_TURN_V1__ prompt envelope (or /moa <prompt> slash).
4. Inspect ~/.hermes/sessions/request_dump_*.json.

Expected

The request body sent to https://openrouter.ai/api/v1/chat/completions should contain "model": "nvidia/nemotron-3-ultra-550b-a55b:free".

Actual

The request body contains "model": "nemotron" — the prefix, suffix and :free are all stripped. OpenRouter returns HTTP 400 "nemotron is not a valid model ID".

Verified

The MoA-Loop _slot_runtime() function in agent/moa_loop.py calls resolve_runtime_provider() from hermes_cli/runtime_provider.py. The substitution happens after the prompt is decoded — the encoded payload still contains the full model name. So the bug is in the provider-resolution path, not the encoder.

The same pattern reproduces with nvidia/nemotron-3-super-120b-a12b:free. It does not reproduce with inclusionai/ring-2.6-1t:free (verified: 35s clean round-trip).

Workaround

Use OpenRouter models whose names do not contain the substring nemotron. The only two Free-Tier models currently passing are inclusionai/ring-2.6-1t:free and poolside/laguna-m.1:free (per the cached ~/.hermes/cache/model_catalog.json).

Related

• [Bug]: MoA configure shows only 2 NVIDIA models while normal model picker shows many NVIDIA models #59211 covers a related catalog-divergence in hermes moa configure (NVIDIA picker stale).
• The local _openrouter_catalog_cache issue (Bug: /model --refresh doesn't reset in-memory OpenRouter catalog cache #55994) might be the same family of bugs — both are "the runtime is consulting a different catalog than the configured one."

Bug 2: MoA aggregator silently reports "no task content" for encoded prompts > ~1000 chars

Steps to reproduce

1. Build an encoded MoA prompt that exceeds ~1000 chars (base64'd preset payload + a non-trivial question).
2. Submit via hermes -z "$(cat /tmp/moa_q.txt)" --cli --model minimax.
3. The first MoA call works, but the aggregator M3 returns a meta-response: "Deine Nachricht kam leer an — kein Auftrag, nur das MoA-Meta drüber." or "MoA-Aggregator hat's auch gemerkt ('no task content was supplied')".

Expected

The user-supplied question is delivered to the reference models and the aggregator, then the synthesized response is returned to the user.

Actual

The user-facing answer is essentially a debugging prompt asking "what did you want?" instead of an answer. No error code, no log line; the failure is only visible by reading the agent's reply.

Notes

• Shorter prompts (< ~750 chars including encoded payload) DO work. The 91-121s successful round-trip we got used a 754-char encoded payload.
• The threshold feels like a parser/decoder issue rather than a content-length one — the question text survives encoding but the aggregator's view of the messages does not.
• This bug makes Bug 1's workaround harder: the only well-tested working preset (diverse-quality-v2 with ring + nemotron-super) is the one that consistently trips the encoding bug.

Bug 3: hermes security audit flags cryptography==46.0.7 despite it being hermes-agent's pinned dependency

Steps to reproduce

1. Run hermes security audit on a fresh v0.18.2 install.
2. Among the HIGH-severity findings, observe:

   HIGH      cryptography==46.0.7  GHSA-537c-gmf6-5ccf
            Vulnerable OpenSSL included in cryptography wheels
            fixed in: 48.0.1
   

3. Inspect ~/.hermes/hermes-agent/venv/lib/python3.11/site-packages/hermes_agent-0.18.2.dist-info/METADATA:

   Requires-Dist: cryptography==46.0.7
   

Expected

Either:

• The pinned vulnerable version is bumped in the next hermes-agent release, or
• The audit tool treats its own pinned version as out-of-scope (similar to how pip self-version is filtered out of OSV scans).

Actual

The audit reports hermes-agent's own pinned dependency as a HIGH finding that the user cannot fix without overriding Requires-Dist metadata. This makes the weekly security-audit report noisy and erodes user trust in the audit tool.

Environment

Operating System: Ubuntu 24.04 LTS (Linux 6.17.0-35-generic)
Python Version: 3.11.15
Hermes Version: Hermes Agent v0.18.2 (2026.7.7.2) · upstream f82c7139
Project: /home/cole/.hermes/hermes-agent/venv/lib/python3.11/site-packages
OpenAI SDK: 2.24.0
MoA runtime: agent/moa_loop.py:_slot_runtime + hermes_cli/runtime_provider.py:resolve_runtime_provider
OpenRouter catalog: 40 models, 5 free-tier (cached 2026-07-09T18:38:59Z)

Proposed next steps

For each of the three:

• Bug 1: short-term, log a warning when _slot_runtime shortens a Free-Tier model name; medium-term, the OpenRouter path in resolve_runtime_provider should not call into NVIDIA's path-based logic that strips suffixes.
• Bug 2: add a debug-level log when the aggregator's decoded message is empty/missing; investigate whether the message-decoder in moa_loop.aggregate_moa_context() truncates at a specific character boundary.
• Bug 3: have hermes security audit skip the hermes-agent distribution's own Requires-Dist pins, OR document that the audit's CRITICAL/HIGH counts include pinned-by-us vulnerabilities and need a hermes agent upgrade to clear.

Happy to send a debug report (hermes debug) if that helps, but the local repro is reliable enough that it might not add much signal.

[Cole666hs]

Update after running additional tests: I was able to reproduce all three bugs but my root-cause attribution was wrong on at least one of them. Reporting back so the maintainer triage doesn't chase ghosts.

Bug 1 (model name gets shortened) — partially redacted, still real

I spent another round tracing this. The shortening does not happen in agent/moa_loop.py:_slot_runtime or in hermes_cli/runtime_provider.py:resolve_runtime_provider when both are called in a Python process that has OPENROUTER_API_KEY in its environment. Tested directly:

# Source env first
os.environ["OPENROUTER_API_KEY"] = "sk-or-v1-..."

# Then call the resolver
rt = resolve_runtime_provider(requested='openrouter', target_model='nvidia/nemotron-3-ultra-550b-a55b:free')
# → model='nvidia/nemotron-3-ultra-550b-a55b:free', base_url='https://openrouter.ai/api/v1', api_key=SET

So when the runtime has the key, the full model name is preserved end-to-end and the OpenRouter call returns a real completion.

The shortened-"nemotron" symptom appears to come from a different code path that runs when OPENROUTER_API_KEY is not in the env (which is the case for direct hermes -z CLI invocations — the systemd EnvironmentFile= only injects into the gateway service, not into user shells). In that situation, resolve_runtime_provider returns the openrouter base_url but no api_key. The MoA loop's subsequent call to OpenRouter then has an empty Authorization header, and what gets logged as "model": "nemotron" is the OpenRouter-side response object, not the request — OpenRouter's 400 message reads invalid params, unknown model '...nemotron-3-ultra-550b-a12b:free' and the path/suffix get lost in some redacting step on Hermes' side.

So the bug is real (the suffix-stripping + the 2013 error) but it's downstream of "no API key in env," not a model-name substitution upstream. My original repro was from the wrong end.

New minimal repro: Run hermes -z from a shell that does NOT have OPENROUTER_API_KEY sourced. The error message will contain a stripped model name that looks like a substitution bug.

Actual recommended fix: Either (a) hermes -z (and any CLI entry point) should read OPENROUTER_API_KEY from ~/.hermes/.env or ~/.local/run/hermes-keys.env even when not running under systemd, or (b) when the resolver returns base_url=openrouter.ai + no key, the MoA loop should fail with a clearer error ("OPENROUTER_API_KEY is required to use MoA with OpenRouter; set it in .env or via the secrets-pi integration"), not silently produce a stripped-model 400.

Bug 2 (encoded prompt > ~1000 chars) — couldn't reproduce in Python

Tested with agent.moa_loop.aggregate_moa_context() directly using the same encoded payload that fails under hermes -z. An 1005-char encoded prompt + a 70-word question made it through cleanly to all 3 references and the aggregator, total wallclock 81s, no "no task content" message.

This strongly suggests Bug 2 is in the CLI path (likely the hermes -z shell-quoting or the prompt-decoder layer in hermes_cli/oneshot.py or similar), not in moa_loop.py. The CLI may be splitting the encoded payload on whitespace or truncating after a fixed length.

New minimal repro: A 1500-char MoA prompt via hermes -z should consistently trigger this; same prompt via the Python API should not.

Bug 3 (hermes-agent pinning a vulnerable cryptography) — still real, no change

Requires-Dist: cryptography==46.0.7 is in the installed hermes_agent-0.18.2.dist-info/METADATA. The audit tool flags it as HIGH. Not a misattribution.

---

Closing thoughts: I'd ask the maintainer team to push back on Bug 1 as filed (the model-substitution framing misleads the actual fix) but the underlying "CLI doesn't carry the OpenRouter env" + "MoA silently produces a degraded 400 instead of an actionable error" combo is real and worth fixing. Bug 2's repro is now CLI-specific. Bug 3 stands.

Will update if I find more.