Problem or Use Case

Hi Hermes team,

I am integrating Hermes Agent through the API Server with a third-party Web UI. I found a mismatch between the CLI/gateway session model and the API Server interface.

Hermes CLI/gateway already appears to support two distinct concepts:

• session_key: a stable per-chat/per-channel identity used as the long-term gateway session/memory scope.
• session_id: the short-term transcript/session id, regenerated by /new or /reset.

This design works well for the native gateway flow: the same session_key can survive across multiple session_ids, so users can start fresh short-term conversations while still keeping the same long-term memory scope.

However, the API Server currently only exposes X-Hermes-Session-Id. I could not find a way to provide a stable session_key to the API Server and have it passed into AIAgent(gateway_session_key=...).

This makes third-party Web UI integrations hard to implement correctly. The desired behavior is:

• one stable assistant/channel-level session_key
• multiple independent UI conversations with different session_ids
• /new and /reset should rotate only the session_id
• long-term memory providers such as Honcho should still be scoped by the stable session_key

Could the API Server support something like X-Hermes-Session-Key and pass it through to AIAgent(gateway_session_key=...), while keeping X-Hermes-Session-Id for transcript continuity?

This would let API-based integrations match the CLI/gateway memory semantics without patching Hermes locally.

Proposed Solution

Hi Hermes team,

I am integrating Hermes Agent through the API Server with a third-party Web UI. I found a mismatch between the CLI/gateway session model and the API Server interface.

Hermes CLI/gateway already appears to support two distinct concepts:

• session_key: a stable per-chat/per-channel identity used as the long-term gateway session/memory scope.
• session_id: the short-term transcript/session id, regenerated by /new or /reset.

This design works well for the native gateway flow: the same session_key can survive across multiple session_ids, so users can start fresh short-term conversations while still keeping the same long-term memory scope.

However, the API Server currently only exposes X-Hermes-Session-Id. I could not find a way to provide a stable session_key to the API Server and have it passed into AIAgent(gateway_session_key=...).

This makes third-party Web UI integrations hard to implement correctly. The desired behavior is:

• one stable assistant/channel-level session_key
• multiple independent UI conversations with different session_ids
• /new and /reset should rotate only the session_id
• long-term memory providers such as Honcho should still be scoped by the stable session_key

Could the API Server support something like X-Hermes-Session-Key and pass it through to AIAgent(gateway_session_key=...), while keeping X-Hermes-Session-Id for transcript continuity?

This would let API-based integrations match the CLI/gateway memory semantics without patching Hermes locally.

Alternatives Considered

No response

Feature Type

Gateway / messaging improvement

Scope

None

Contribution

• I'd like to implement this myself and submit a PR

Debug Report (optional)