> ## Documentation Index
> Fetch the complete documentation index at: https://docs.valarhq.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# LibreChat

> Route a self-hosted LibreChat deployment through Valar, with usage attributed per user and per app

[LibreChat](https://www.librechat.ai) 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.

| Header | Value | What it buys |
| - | - | - |
| `X-Valar-Client-Id` | `{{LIBRECHAT_USER_EMAIL}}` | attributes usage to the individual user |
| `X-Valar-Harness` | `librechat` | attributes usage to the app |
| `X-Session-Id` | `{{LIBRECHAT_BODY_CONVERSATIONID}}` | groups a conversation's requests together |

`{{LIBRECHAT_USER_EMAIL}}` and `{{LIBRECHAT_BODY_CONVERSATIONID}}` are LibreChat's own template variables, substituted per request.

<Warning>
  **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.
</Warning>

### 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](/valarcode/portkey)** — add Valar as an Anthropic provider with a custom host, [provision every Valar model](/valarcode/portkey#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](/valarcode/portkey#if-one-portkey-key-serves-other-backends) first. A Config naming a provider routes every request through it and discards the `@slug/` prefix LibreChat sent.
* **[LiteLLM](/valarcode/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:

```yaml theme={"system"}
headers:
  x-valar-client-id: "{{LIBRECHAT_USER_EMAIL}}"
  x-valar-harness: "librechat"
  x-session-id: "{{LIBRECHAT_BODY_CONVERSATIONID}}"
```

<Note>
  **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](mailto:support@valarhq.ai) rather than working around it.
</Note>

## 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](/valarcode/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](/valarcode/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.