LibreChat is one of the best open-source AI chat and agent surfaces for teams that want self-hosting, MCP support, flexible model backends, and a real product surface instead of a demo UI.
Lynkr is an open-source LLM gateway built for coding assistants, agents, and MCP-heavy workflows. It gives you one OpenAI-compatible endpoint in front of multiple providers, with routing, caching, and cleaner model infrastructure behind it.
Put together, they make a clean split:
That is why this pairing works so well. LibreChat already supports custom OpenAI-compatible endpoints, and Lynkr is a strong fit for the kind of multi-provider, tool-using, agentic traffic LibreChat users actually generate.
This article is the practical follow-up to the architecture case: the goal here is to get LibreChat talking to Lynkr with a minimal working setup.
I built Lynkr, so founder disclosure applies. I’m keeping this grounded to what LibreChat and Lynkr support today.
There are plenty of tools that can sit between an app and a model provider, but Lynkr is a particularly strong fit for LibreChat for a few reasons:
That means this setup is not just “put any proxy in front of LibreChat.” It is specifically about using a gateway that matches the workload.
Before starting, you need:
Repo references:
Two details matter here:
/v1
endpointThat’s the seam we’re using.
The setup we want looks like this:
Browser
↓
LibreChat
↓
Lynkr (OpenAI-compatible endpoint)
↓
OpenAI / Bedrock / OpenRouter / Ollama / Anthropic-compatible backends / others
In other words:
Install Lynkr globally:
npm install -g lynkr
Now create a minimal .env
for Lynkr.
MODEL_PROVIDER=ollama
OLLAMA_ENDPOINT=http://localhost:11434
OLLAMA_MODEL=qwen2.5-coder:latest
FALLBACK_ENABLED=false
PORT=8081
PROMPT_CACHE_ENABLED=true
SEMANTIC_CACHE_ENABLED=true
Then start Lynkr:
lynkr start
MODEL_PROVIDER=openrouter
OPENROUTER_API_KEY=your_openrouter_key
FALLBACK_ENABLED=false
PORT=8081
PROMPT_CACHE_ENABLED=true
SEMANTIC_CACHE_ENABLED=true
Then start it:
lynkr start
Before touching LibreChat, you can test Lynkr directly with a simple OpenAI-compatible request:
curl http://localhost:8081/v1/chat/completions \
-H "Content-Type: application/json" \
-H "Authorization: Bearer dummy-key" \
-d '{
"model": "gpt-4o-mini",
"messages": [{"role": "user", "content": "Say hello in one sentence."}]
}'
If that succeeds, the gateway path is working before LibreChat is added on top.
Once Lynkr is running, verify the endpoint responds:
curl http://localhost:8081/
You should get a JSON response showing the service is running.
At this point, Lynkr should expose an OpenAI-compatible base URL at:
http://localhost:8081/v1
That is the URL LibreChat should talk to.
LibreChat supports custom endpoints and also lets users provide a custom baseURL
for supported endpoint flows.
For this setup, the important part is simple:
/v1
base URLSo the mental model is:
LibreChat config → one base URL → Lynkr
Lynkr config → actual providers, routing, fallback, cache
That separation is the whole point.
The exact UI path can differ depending on how you run LibreChat and how you expose custom endpoints, but the working shape is the same.
In LibreChat, configure a custom OpenAI-compatible endpoint with:
http://localhost:8081/v1
Endpoint Type: Custom OpenAI-compatible endpoint
Base URL: http://localhost:8081/v1
API Key: dummy-key
Model: gpt-4o-mini
If your LibreChat instance and Lynkr instance run on different hosts, replace localhost
with the actual reachable host:
http://lynkr.internal:8081/v1
or
https://lynkr.yourdomain.com/v1
If you are running LibreChat in Docker and Lynkr on the host machine, you may need to use a host-reachable name rather than localhost
, for example:
http://host.docker.internal:8081/v1
That’s one of the most common gotchas.
This part trips people up more than it should.
LibreChat wants a model name. Lynkr also needs to know what to do with that model name.
There are two clean ways to handle this.
Use a model name that corresponds to the backend you want Lynkr to use.
Example:
gpt-4o-mini
or
claude-3-5-sonnet
This is the simplest starting point if Lynkr is forwarding traffic in a straightforward way.
A better long-term pattern is to let LibreChat use a stable name like:
chat-fast
or
chat-quality
Then map those choices in the gateway layer.
That way:
Even if you do not formalize that on day one, this is the direction I’d recommend.
Once the endpoint is configured, test a simple chat request first.
Use something cheap and easy to inspect, like:
Write a Python function that reverses a string.
If that works, test a second request that makes backend behavior easier to reason about, like:
Summarize the difference between Redis and PostgreSQL in 5 bullets.
What you’re looking for:
If this works, the base integration is done.
This is where the setup becomes more useful than direct provider wiring.
A good first pattern is:
Conceptually, the setup looks like this:
LibreChat user chooses: chat-fast
→ Lynkr routes to cheaper tier
LibreChat user chooses: chat-quality
→ Lynkr routes to stronger tier
Even without exposing every provider in LibreChat, you still get flexibility behind the gateway.
That’s cleaner than giving end users six raw vendor choices and expecting them to know when each one is appropriate.
Do not start with fallback complexity on the first try. Get one provider working first.
After that, the next useful improvement is fallback.
Example pattern:
or
This gives you a much better operational story than “LibreChat is hardwired to one provider and breaks when that provider has a bad day.”
That’s one of the clearest reasons to keep failover logic below the app layer.
Here’s what this looks like in practice.
LibreChat → OpenAI directly
If you want to change providers, add fallback, or introduce routing, those concerns start leaking into the app layer.
LibreChat → Lynkr → OpenRouter
↘ Bedrock fallback
LibreChat stays pointed at one endpoint.
That means:
Here are the ones most likely to waste your time.
If you point LibreChat at:
http://localhost:8081
instead of:
http://localhost:8081/v1
you may hit endpoint mismatches depending on how the OpenAI-compatible client path is built.
Use the /v1
base URL.
If LibreChat runs in Docker, localhost
usually means the container itself, not your host machine.
Use a network-reachable host such as:
http://host.docker.internal:8081/v1
or a proper internal hostname.
If LibreChat sends a model string Lynkr does not recognize or route correctly, requests will fail even though the endpoint is reachable.
When debugging, simplify:
Don’t try to validate all of these at once:
Get the base chat completion path working first.
Then expand.
LibreChat is excellent at the user/product layer.
But if you keep using the app layer to own provider switching, cost control, and failover, you lose the main architectural benefit of using a gateway underneath it.
Keep the responsibilities split.
Even the minimal version gives you a better foundation than direct provider wiring.
You get:
And as your setup grows, that separation only gets more valuable.
If you just want the shortest possible version, this is it:
8081
http://localhost:8081/v1
is reachablehttp://localhost:8081/v1
LibreChat already gives you the hard part: a good open-source surface for chat, agents, MCP, and self-hosting.
Lynkr gives you the missing infrastructure layer under it.
That combination is stronger than pushing all model concerns into the app itself.
If you’re building a self-hosted AI stack that needs to survive provider churn, model changes, and growing workflow complexity, this is the shape I’d use.
If this article was useful, star the repos and let me know if you want the next one to go deeper on: