Does Onyx support of user header mapping where something like X-OpenWebUI-User-Id?

[tnndclub]

Hello,

LiteLLM is my setup acting as a proxy between the AI client and models router.
I want to do tracking per user usage in LiteLLM.
LiteLLM supports of User Info Header from Open WebUI and thus user's query can be correctly mapped and tracked.
Does Onyx provide something similar?

[crosscore]

For per-user usage tracking, the first setting to try is SEND_USER_METADATA_TO_LLM_PROVIDER=true on the Onyx backend. Onyx has a user-metadata path, although it is different from automatically generating Open WebUI's headers.

In the current Onyx implementation, this setting adds a user parameter to the LiteLLM call. The chat path uses the signed-in user's email, falling back to their user ID; anonymous requests share anonymous_user. The setting is disabled by default.

For a self-hosted deployment:

1. Add SEND_USER_METADATA_TO_LLM_PROVIDER=true to the backend service's environment, then recreate/restart that service so it receives the new value. Merely adding it to a host .env file will not help unless your Compose configuration passes it into the container.
2. Send one chat from each of two signed-in test accounts.
3. Check whether the JSON arriving at your LiteLLM proxy contains different user values. LiteLLM supports this field for Customer Usage tracking; you do not need an X-OpenWebUI-User-Id header if that field arrives correctly.

There is a compatibility caveat: #10461 reports user being dropped for some custom OpenAI-compatible model names by the bundled LiteLLM SDK. Onyx adding the parameter internally therefore does not prove that your proxy receives it. If the setting is enabled but attribution is still missing, the Onyx version, configured provider type, model alias, and inbound request's user field are the useful things to check first. Onyx's internal metadata.session_id also should not be assumed to reach the proxy.

If you specifically need headers, Onyx additionally has LITELLM_PASS_THROUGH_HEADERS, for example:

LITELLM_PASS_THROUGH_HEADERS=["x-litellm-end-user-id"]

This forwards a header already present on the incoming chat request; it does not derive an identity from Onyx's login session or rename headers. The chat endpoint extracts the configured headers, and LiteLLM recognizes x-litellm-end-user-id. Use this route only with a trusted authentication layer that sets/overwrites the identity header. LITELLM_EXTRA_HEADERS supplies static values, so one shared value would group all users together.

For your stated goal, I would start with the metadata setting and the two-account check. This enables attribution; it does not turn the shared proxy API key into per-user JWT authentication.

[tnndclub]

Thank you for your feedback, @crosscore.
This is very helpful.
Previously, I tried SEND_USER_METADATA_TO_LLM_PROVIDER in .env but didn't see the user parameter added to the LiteLLM call.
Following your guidance and adding the setting to the backend service instance, I can see the parameter now.
Here comes additional question, it seems not adding the user parameter to every LiteLLM call but the first call of a session. is this expected?

[crosscore]

Good to hear that setting it on the backend service made the user field appear.

For the normal chat-answer path, I don't see an intentional “send it only on the first call of a session” rule. I checked current Onyx main at 98c48cd:

• build_chat_turn constructs the identity for both new and existing chat sessions.
• The chat loop passes that identity into each main LLM step. The request helper adds user whenever the setting and identity are present, without checking whether this is the first turn.

However, one chat message can produce several model requests, and the metadata setting does not guarantee coverage of every internal call. For example, chat-title generation calls llm.invoke(...) without user_identity. That can explain a mixture of requests with and without user; it does not establish why a second main chat answer would lose it.

A useful check would be:

1. Send two short messages in the same conversation, using the same model and with search/tools disabled where possible.
2. Inspect the requests arriving at your LiteLLM proxy from Onyx, rather than only the proxy's outgoing provider requests or dashboard. For each, note the timestamp, model, stream value, and whether the top-level user field is present. Use these to distinguish the main answers from auxiliary calls; stream alone is not definitive.
3. If the second main answer is missing user, please share your Onyx version/image tag, configured provider type/model alias, and that small redacted comparison. No prompt text, email addresses, or credentials are needed.

The custom-model filtering issue #10461 is another possible layer to investigate, but the current evidence does not establish that it causes this particular first-call-only pattern. The source above is current main; I haven't reproduced this on your deployed version.