{"slug": "how-to-configure-librechat-with-lynkr-using-a-custom-openai-compatible-endpoint", "title": "How to Configure LibreChat with Lynkr Using a Custom OpenAI-Compatible Endpoint", "summary": "A developer built Lynkr, an open-source LLM gateway that provides a single OpenAI-compatible endpoint for multiple model providers, and configured it to work with LibreChat, an open-source AI chat platform. The setup enables teams to self-host a chat interface with flexible model backends, routing, caching, and MCP support. The developer provides a step-by-step guide to integrate LibreChat with Lynkr using a custom endpoint.", "body_md": "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.\n\n[Lynkr](https://github.com/Fast-Editor/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.\n\nPut together, they make a clean split:\n\nThat 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.\n\nThis 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.\n\nI built Lynkr, so founder disclosure applies. I’m keeping this grounded to what LibreChat and Lynkr support today.\n\nThere 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:\n\nThat means this setup is not just “put any proxy in front of LibreChat.” It is specifically about using a gateway that matches the workload.\n\nBefore starting, you need:\n\nRepo references:\n\nTwo details matter here:\n\n`/v1`\n\nendpointThat’s the seam we’re using.\n\nThe setup we want looks like this:\n\n```\nBrowser\n  ↓\nLibreChat\n  ↓\nLynkr (OpenAI-compatible endpoint)\n  ↓\nOpenAI / Bedrock / OpenRouter / Ollama / Anthropic-compatible backends / others\n```\n\nIn other words:\n\nInstall Lynkr globally:\n\n```\nnpm install -g lynkr\n```\n\nNow create a minimal `.env`\n\nfor Lynkr.\n\n```\nMODEL_PROVIDER=ollama\nOLLAMA_ENDPOINT=http://localhost:11434\nOLLAMA_MODEL=qwen2.5-coder:latest\nFALLBACK_ENABLED=false\nPORT=8081\nPROMPT_CACHE_ENABLED=true\nSEMANTIC_CACHE_ENABLED=true\n```\n\nThen start Lynkr:\n\n```\nlynkr start\nMODEL_PROVIDER=openrouter\nOPENROUTER_API_KEY=your_openrouter_key\nFALLBACK_ENABLED=false\nPORT=8081\nPROMPT_CACHE_ENABLED=true\nSEMANTIC_CACHE_ENABLED=true\n```\n\nThen start it:\n\n```\nlynkr start\n```\n\nBefore touching LibreChat, you can test Lynkr directly with a simple OpenAI-compatible request:\n\n```\ncurl http://localhost:8081/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: Bearer dummy-key\" \\\n  -d '{\n    \"model\": \"gpt-4o-mini\",\n    \"messages\": [{\"role\": \"user\", \"content\": \"Say hello in one sentence.\"}]\n  }'\n```\n\nIf that succeeds, the gateway path is working before LibreChat is added on top.\n\nOnce Lynkr is running, verify the endpoint responds:\n\n```\ncurl http://localhost:8081/\n```\n\nYou should get a JSON response showing the service is running.\n\nAt this point, Lynkr should expose an OpenAI-compatible base URL at:\n\n```\nhttp://localhost:8081/v1\n```\n\nThat is the URL LibreChat should talk to.\n\nLibreChat supports custom endpoints and also lets users provide a custom `baseURL`\n\nfor supported endpoint flows.\n\nFor this setup, the important part is simple:\n\n`/v1`\n\nbase URLSo the mental model is:\n\n```\nLibreChat config → one base URL → Lynkr\nLynkr config → actual providers, routing, fallback, cache\n```\n\nThat separation is the whole point.\n\nThe exact UI path can differ depending on how you run LibreChat and how you expose custom endpoints, but the working shape is the same.\n\nIn LibreChat, configure a custom OpenAI-compatible endpoint with:\n\n`http://localhost:8081/v1`\n\n```\nEndpoint Type: Custom OpenAI-compatible endpoint\nBase URL: http://localhost:8081/v1\nAPI Key: dummy-key\nModel: gpt-4o-mini\n```\n\nIf your LibreChat instance and Lynkr instance run on different hosts, replace `localhost`\n\nwith the actual reachable host:\n\n```\nhttp://lynkr.internal:8081/v1\n```\n\nor\n\n```\nhttps://lynkr.yourdomain.com/v1\n```\n\nIf you are running LibreChat in Docker and Lynkr on the host machine, you may need to use a host-reachable name rather than `localhost`\n\n, for example:\n\n```\nhttp://host.docker.internal:8081/v1\n```\n\nThat’s one of the most common gotchas.\n\nThis part trips people up more than it should.\n\nLibreChat wants a model name. Lynkr also needs to know what to do with that model name.\n\nThere are two clean ways to handle this.\n\nUse a model name that corresponds to the backend you want Lynkr to use.\n\nExample:\n\n```\ngpt-4o-mini\n```\n\nor\n\n```\nclaude-3-5-sonnet\n```\n\nThis is the simplest starting point if Lynkr is forwarding traffic in a straightforward way.\n\nA better long-term pattern is to let LibreChat use a stable name like:\n\n```\nchat-fast\n```\n\nor\n\n```\nchat-quality\n```\n\nThen map those choices in the gateway layer.\n\nThat way:\n\nEven if you do not formalize that on day one, this is the direction I’d recommend.\n\nOnce the endpoint is configured, test a simple chat request first.\n\nUse something cheap and easy to inspect, like:\n\nWrite a Python function that reverses a string.\n\nIf that works, test a second request that makes backend behavior easier to reason about, like:\n\nSummarize the difference between Redis and PostgreSQL in 5 bullets.\n\nWhat you’re looking for:\n\nIf this works, the base integration is done.\n\nThis is where the setup becomes more useful than direct provider wiring.\n\nA good first pattern is:\n\nConceptually, the setup looks like this:\n\n```\nLibreChat user chooses: chat-fast\n  → Lynkr routes to cheaper tier\n\nLibreChat user chooses: chat-quality\n  → Lynkr routes to stronger tier\n```\n\nEven without exposing every provider in LibreChat, you still get flexibility behind the gateway.\n\nThat’s cleaner than giving end users six raw vendor choices and expecting them to know when each one is appropriate.\n\nDo not start with fallback complexity on the first try. Get one provider working first.\n\nAfter that, the next useful improvement is fallback.\n\nExample pattern:\n\nor\n\nThis gives you a much better operational story than “LibreChat is hardwired to one provider and breaks when that provider has a bad day.”\n\nThat’s one of the clearest reasons to keep failover logic below the app layer.\n\nHere’s what this looks like in practice.\n\n```\nLibreChat → OpenAI directly\n```\n\nIf you want to change providers, add fallback, or introduce routing, those concerns start leaking into the app layer.\n\n```\nLibreChat → Lynkr → OpenRouter\n                    ↘ Bedrock fallback\n```\n\nLibreChat stays pointed at one endpoint.\n\nThat means:\n\nHere are the ones most likely to waste your time.\n\nIf you point LibreChat at:\n\n```\nhttp://localhost:8081\n```\n\ninstead of:\n\n```\nhttp://localhost:8081/v1\n```\n\nyou may hit endpoint mismatches depending on how the OpenAI-compatible client path is built.\n\nUse the `/v1`\n\nbase URL.\n\nIf LibreChat runs in Docker, `localhost`\n\nusually means **the container itself**, not your host machine.\n\nUse a network-reachable host such as:\n\n```\nhttp://host.docker.internal:8081/v1\n```\n\nor a proper internal hostname.\n\nIf LibreChat sends a model string Lynkr does not recognize or route correctly, requests will fail even though the endpoint is reachable.\n\nWhen debugging, simplify:\n\nDon’t try to validate all of these at once:\n\nGet the base chat completion path working first.\n\nThen expand.\n\nLibreChat is excellent at the user/product layer.\n\nBut 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.\n\nKeep the responsibilities split.\n\nEven the minimal version gives you a better foundation than direct provider wiring.\n\nYou get:\n\nAnd as your setup grows, that separation only gets more valuable.\n\nIf you just want the shortest possible version, this is it:\n\n`8081`\n\n`http://localhost:8081/v1`\n\nis reachable`http://localhost:8081/v1`\n\nLibreChat already gives you the hard part: a good open-source surface for chat, agents, MCP, and self-hosting.\n\nLynkr gives you the missing infrastructure layer under it.\n\nThat combination is stronger than pushing all model concerns into the app itself.\n\nIf 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.\n\nIf this article was useful, star the repos and let me know if you want the next one to go deeper on:", "url": "https://wpnews.pro/news/how-to-configure-librechat-with-lynkr-using-a-custom-openai-compatible-endpoint", "canonical_source": "https://dev.to/lynkr/how-to-configure-librechat-with-lynkr-using-a-custom-openai-compatible-endpoint-3423", "published_at": "2026-06-16 05:02:25+00:00", "updated_at": "2026-06-16 05:17:26.824095+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "ai-infrastructure"], "entities": ["LibreChat", "Lynkr", "OpenAI", "Ollama", "OpenRouter", "Bedrock", "Anthropic"], "alternates": {"html": "https://wpnews.pro/news/how-to-configure-librechat-with-lynkr-using-a-custom-openai-compatible-endpoint", "markdown": "https://wpnews.pro/news/how-to-configure-librechat-with-lynkr-using-a-custom-openai-compatible-endpoint.md", "text": "https://wpnews.pro/news/how-to-configure-librechat-with-lynkr-using-a-custom-openai-compatible-endpoint.txt", "jsonld": "https://wpnews.pro/news/how-to-configure-librechat-with-lynkr-using-a-custom-openai-compatible-endpoint.jsonld"}}