hermes - 💡(How to fix) Fix Expose response metadata and SSE comments to context engine plugins [1 participants]

Feature request

Please expose provider response metadata to Hermes plugins/context engines, especially response headers and final SSE metadata comments.

Motivation

Some OpenAI-compatible routing proxies can switch the actual upstream model at runtime through fallback, routing, or model-combo strategies. A Hermes context-engine plugin needs to know the actual served model so it can keep the effective context window and compression threshold accurate after routing/model switching.

Concrete example: OmniRoute exposes the actual routed model as response metadata:

• Non-streaming/streaming response header: X-OmniRoute-Model: <actual model>
• Streaming final metadata comments such as : x-omniroute-model=<actual model>

A context engine such as RouterCtx can already resolve model-specific context windows when it receives a truthful served model. However, Hermes currently appears to call the context engine with token usage only, e.g. prompt/completion/total tokens, so plugins cannot see response headers, response.model, or SSE comments.

Requested capability

Add an upgrade-safe plugin/context-engine API path that passes response metadata into context engines, for example:

usage_dict = {
    "prompt_tokens": prompt_tokens,
    "completion_tokens": completion_tokens,
    "total_tokens": total_tokens,
    "response_model": getattr(response, "model", None),
    "response_headers": dict(response_headers or {}),
    "sse_metadata": sse_metadata or {},
}
context_engine.update_from_response(usage_dict)

Or preferably a structured object/event such as:

context_engine.update_from_response({
    "usage": usage,
    "model": requested_model,
    "provider": provider,
    "response_model": response_model,
    "headers": response_headers,
    "sse_comments": parsed_sse_comments,
})

Desired behavior

• For non-streaming responses, expose response headers and response.model if available.
• For streaming responses, expose response headers and any final/metadata SSE comments observed during stream processing.
• Preserve backward compatibility with existing context engines that only expect usage token fields.
• Avoid requiring modifications to Hermes core for router-specific integrations.

Use case

When Hermes requests gpt-5.5 through a local router, the router may fall back to claude-sonnet-4.5. If the router exposes X-OmniRoute-Model: claude-sonnet-4.5, a context-engine plugin can update the effective context window from the requested model's context to the actual served model's context.

Without this metadata handoff, plugins can only see the requested model and token counts, which makes silent server-side fallback impossible to handle reliably.

Related integrations

• OmniRoute: exposes X-OmniRoute-Model and x-omniroute-model SSE metadata comments.
• RouterCtx: context-engine plugin that can consume served-model metadata if Hermes passes it through.

Thanks!