LibreChat Custom Endpoint: Models, Titles and API Costs
Add a LibreChat custom endpoint with a small model allowlist, keep credentials server-side, and account for title generation and other background calls.
Published 2026-09-29 · Updated 2026-09-29 · KeepRouter Editorial · 5 minute read

Add a compatible API under endpoints.custom in LibreChat's existing configuration, referencing a server environment variable for the key. Begin with an explicit model list and a simple text conversation. Treat title generation, memory, tools and document retrieval as separate callers that may need their own model settings.
The goal is to add a reversible connection to an existing deployment. Do not replace the entire LibreChat configuration with a short endpoint snippet, because authentication, storage and other application settings belong to the existing installation.
Add a named endpoint
The LibreChat custom-endpoint reference defines baseURL, environment-variable credentials, model selection and title settings. Merge this fragment into your existing librechat.yaml, preserving its version and other endpoints:
endpoints:
custom:
- name: KeepRouter
apiKey: '${KEEPROUTER_API_KEY}'
baseURL: https://keeprouter.com/v1
models:
default:
- free
fetch: false
titleConvo: false
# titleModel: current_model # Set when enabling titles
modelDisplayLabel: KeepRouterSet KEEPROUTER_API_KEY in the server environment through your deployment's secret mechanism. The literal ${KEEPROUTER_API_KEY} in the file is a reference, not a key to send as text. Apply configuration changes using the procedure for your LibreChat deployment and confirm that the new endpoint appears.
Starting with fetch: false and one explicit model keeps the trial easy to understand. It is not a claim that the destination cannot provide model discovery. Expand or dynamically fetch the list only after confirming which model types the chat interface can actually use.
Keep the display label separate from the API model
The endpoint name helps users select a connection; the model ID determines the actual request. A friendly label does not create a model alias on the API server. Keep an inventory mapping the visible option to its real catalog ID and endpoint.
| Local configuration | Meaning | Initial check |
|---|---|---|
| Endpoint name | UI connection identity | Select KeepRouter explicitly |
| Base URL | API prefix | Avoid duplicating /v1 |
| Model list | Choices offered by this connection | Start with a supported chat ID |
| Display label | Human-readable presentation | Do not mistake it for a server ID |
| Title model | Background conversation-title generation | Leave disabled for the first fixture |
Run a new conversation with a supplied fact and check that the response completes. The free model is a connection fixture. A paid model must be selected and evaluated on the task your users actually perform; support for basic text says little about its tool or attachment behavior.
Make background requests visible in your budget
Automatic titles can create extra model calls around a conversation. Memory, summarization and retrieval may also have separate configurations. LibreChat's memory documentation describes its own endpoint and model settings; do not assume changing the chat endpoint updates them all.
For a hypothetical day with 100 conversations and five user messages each, there are 500 visible turns. One title request per new conversation would add 100 calls if enabled. That is a request-count example, not a prediction of token cost: a short title call and a long document answer can consume very different amounts.
Re-enable titles after the main chat path works. Choose a supported title model explicitly and check whether its output is useful. If the title model is missing, a main chat can succeed while the interface still reports a background error.
Keep unsupported parameters from becoming silent changes
Custom endpoints can expose parameter controls and transformations. Use them to match a documented API contract, not to delete every field that causes an error. Dropping a stop sequence, for example, may change the application's expected output rather than merely fixing transport.
Capture the minimal failing request shape, excluding credentials and private messages. Compare it with the KeepRouter API reference. Identify whether the field is unsupported by the gateway, the selected model or the particular operation. Only remove it when the application can accept the changed behavior.
If a model requires native features beyond a standard chat contract, consider retaining its provider-specific integration for that feature. A custom endpoint is useful for common behavior; it is not proof that every vendor-specific workflow can move unchanged.
Test user access as well as model access
An administrator can configure a working connection that the intended user cannot select. Test with the actual role that will use the application. Confirm that the visible model list matches the intended access and that users cannot accidentally select a paid route outside the trial's scope.
Keep the provider key on the server side for this shared connection. Avoid embedding it in shared conversation URLs or prompts. The security guide and your LibreChat access configuration serve different layers, and both matter for a shared deployment.
Use a small fixture containing a normal question, a follow-up and one deliberately unsupported operation. Record the visible answer and background errors separately. An unsupported image or tool request should fail clearly rather than being mistaken for a successful text-only answer.
After basic validation, select a paid candidate from the model catalog, use the cost calculator for a first estimate, and compare total charges with useful conversations. Keep the original endpoint enabled until the new configuration and its background callers pass the trial.
Frequently asked questions
Does fetch: false mean the API lacks model discovery?
No. Here it intentionally keeps a small explicit list for the first test. You can evaluate discovery separately once the chat model selection is understood.
Why disable conversation titles initially?
It isolates the main chat request. Re-enable titles with a supported model after basic access works, and count those background calls in the budget.
Can I paste this over my whole config file?
No. It is an endpoint fragment to merge into the existing configuration, preserving the schema version, other endpoints and deployment settings.
Sources reviewed
Article last reviewed 2026-09-29