Skip to main content
LibreChat is a self-hosted chat front-end your whole organisation shares. Unlike the other tools on this page it runs as a server you deploy, not as a CLI on an engineer’s machine — so there is no valar librechat on command, and everything below is configuration you make once, in LibreChat’s own config, rather than per person. Because it is shared, attribution is the part worth getting right: without it every request in the deployment arrives as one anonymous stream. LibreChat knows who its users are, and it can pass that through.

​
What Valar needs

Three headers, set once in your LibreChat endpoint config. {{LIBRECHAT_USER_EMAIL}} and {{LIBRECHAT_BODY_CONVERSATIONID}} are LibreChat’s own template variables, substituted per request.
Send librechat, not your deployment’s name. X-Valar-Harness accepts a fixed set of tool names — claude, codex, cursor, gemini, opencode, pi, copilot, librechat. Anything else is ignored rather than rejected, and unidentified traffic on this path is recorded as Claude Code — which also means it is served on Claude Code’s routing configuration. If you call your install something else internally, that name belongs in your own dashboards, not in this header.

​
Use the email, not the username

X-Valar-Client-Id is normalised to [a-z0-9._@+-], and characters outside that set — including spaces — are dropped rather than replaced. {{LIBRECHAT_USER_NAME}} = “Jane Doe” becomes janedoe, which is hard to reconcile with a real person and collides with anyone else whose name flattens the same way. {{LIBRECHAT_USER_EMAIL}} survives intact (@ and + are both kept) and is already unique. Prefer it.

​
Connecting

LibreChat reaches Valar through the Anthropic Messages API. Point it at an AI gateway you already run — the setup is the gateway’s, and both of ours carry the same header contract:
  • Portkey — add Valar as an Anthropic provider with a custom host, provision every Valar model, then name the three headers in the Config’s forward_headers. LibreChat can select the auto-router with @valar/valar-auto or a direct model such as @valar/zai-org/GLM-5.3. Portkey does not forward client headers unless you list them, and omitting one fails silently. If the Portkey key behind LibreChat also fronts other providers, read what a pinned Config does to them first. A Config naming a provider routes every request through it and discards the @slug/ prefix LibreChat sent.
  • LiteLLM — enable forward_client_headers_to_llm_api and every x--prefixed header passes through together.
Whichever you use, the headers go in LibreChat’s endpoint config alongside your gateway’s own:
Only the Anthropic Messages path is supported. LibreChat can also be configured as an OpenAI-compatible endpoint, which reaches a different Valar ingress. That path is untested for ValarCode and Valar’s automatic model selection may pick a target it cannot serve. If you need it, tell us rather than working around it.

​
Verify it worked

In the Valar analytics dashboard, after a few requests:
  • Users appear individually, under their email address.
  • Their harness list shows LibreChat — not Claude Code.
If everything lands under Claude Code, X-Valar-Harness is not arriving: either your gateway is not forwarding it, or it is carrying a value outside the supported set. If usage appears but is not attributed to anyone, X-Valar-Client-Id is not arriving. Both fail silently — a request with neither header still returns a correct answer — so the dashboard is the only place the problem shows up.

​
What you get

Once both headers land, analytics breaks the deployment down per user: spend, tokens, which models served them, and savings against the Claude tier each request stood in for. LibreChat appears as its own tool in routing, separate from your engineers’ coding tools, and gets its own Auto or Manual choice: leave it on Auto and Valar picks a model per request, or switch it to Manual and map each Claude size to the model you want it served by. Changing it affects LibreChat only — your coding tools keep whatever they are set to.