[Enhancement]: Support Anthropic API for Custom Endpoints in Agents or Allow Provider-Specific Agent Endpoints

[Byung-sun]

What features would you like to see added?

Problem

I'm trying to restrict access to certain Claude models (Opus) to admin users only while allowing regular users to access only Sonnet models. My goal was to use a custom endpoint for agents that points to the Anthropic API, but this currently fails with a 404
error.

More details

Current Behavior

When configuring a custom endpoint pointing to Anthropic API in librechat.yaml:

custom:

• name: 'Claude-Private'
  apiKey: '${ANTHROPIC_API_KEY}'
  baseURL: 'https://api.anthropic.com/v1'
  headers:
  anthropic-version: "2023-06-01"
  models:
  default:
  - 'claude-opus-4-1-20250805'
  - 'claude-opus-4-5-20251101'
  modelDisplayLabel: 'Claude-Private'
  dropParams: ['stop', 'frequency_penalty', 'presence_penalty', 'logit_bias', 'user']

agents:
allowedProviders: ["openAI", "anthropic", "google", "OpenRouter", "Claude-Private"]

Error: 404 Not Found - MODEL_NOT_FOUND

Root Cause Analysis:

Looking at the code in api/server/services/Endpoints/index.js, custom endpoints are automatically converted to use the OpenAI provider:

} else if (!getOptions) {
customEndpointConfig = getCustomEndpointConfig({ endpoint: provider, appConfig });
if (!customEndpointConfig) {
throw new Error(Provider ${provider} not supported);
}
getOptions = initCustom;
overrideProvider = Providers.OPENAI; // <-- Forces OpenAI provider
}

This causes LangChain to try calling the Anthropic API using the OpenAI client, which fails because Anthropic's API is not OpenAI-compatible.

Expected Behavior

One of the following solutions would resolve this issue:

Option 1: Allow custom endpoints to specify which provider/client to use
custom:

• name: 'Claude-Private'
  provider: 'anthropic' # Specify which provider client to use
  apiKey: '${ANTHROPIC_API_KEY}'
  baseURL: 'https://api.anthropic.com/v1'

  ...

Option 2: Auto-detect provider based on baseURL

• If baseURL contains anthropic.com, use Anthropic client
• If baseURL contains openai.com, use OpenAI client
• etc.

Option 3: Support agent-only endpoint configurations
endpoints:
anthropic:
models:
default: ['claude-sonnet-4-5-20250929'] # Available to all users
agentModels:
default: ['claude-opus-4-1-20250805'] # Only available in agents

Use Case

• Regular users: Should only access Sonnet models through the main UI
• Admin users with agent creation permission: Should be able to use Opus models in agents
• Rationale: Cost control - Opus models are more expensive and should be restricted

Environment

• LibreChat version: v0.8.0
• Deployment: Docker (pre-built image ghcr.io/danny-avila/librechat-dev:latest)
• Cannot modify source code (using pre-built images)

Workaround Attempted

Adding models to ANTHROPIC_MODELS environment variable works, but exposes them to all users, which defeats the purpose of role-based access control.

Proposed Solution Priority

1. Option 2 (Auto-detect) - Least breaking change, works immediately
2. Option 1 (Explicit provider) - Most flexible, clearest intent
3. Option 3 (Agent-only models) - Most aligned with use case

Would appreciate any guidance or consideration for this feature!

Which components are impacted by your request?

No response

Pictures

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[danny-avila]

Related: #10590 (comment)

[pablo-kitz]

Would be great to have this capability for other cases such as custom wiring OpenCode Zen/Go endpoints which use the anthropic /v1/messages api

[danny-avila]

This is planned!

[Martin-SwDevOp]

Related but distinct from the provider-routing aspect of this issue — flagging it here since #13713 was closed as a duplicate of this one.

Even once custom endpoints can properly target the Anthropic API (the core of this issue), there's a separate gap for reverse-proxy setups on the built-in anthropic endpoint: the request currently forwards metadata.user_id but no conversation identifier. A reverse proxy (PII pseudonymization, auditing, request correlation) therefore can't tell which requests belong to the same conversation — and user_id alone doesn't help, since it's constant across all of a user's conversations.
The conversation ID already exists server-side (req.body.conversationId, a UUID) but is never propagated into the metadata sent to the proxied client.

One important constraint I confirmed empirically: Anthropic's native /v1/messages rejects unknown metadata keys with a hard 400 — metadata.conversation_id: Extra inputs are not permitted, so any solution must be gated on reverseProxyUrl (or use an outgoing header, which Anthropic simply ignores).

I wrote up the specific problem and a minimal, gated, backward-compatible fix (3 small type-safe changes, plus a header alternative) in #13713 — happy to open a PR if a maintainer indicates the preferred mechanism.

[Huaian666]

need this badly. every time i hit this limitation i have to context switch to another tool

[danny-avila]

@Martin-SwDevOp the plan is to allow both Anthropic provider as a custom endpoint as well as make the headers configurable for the existing Anthropic endpoint. Both options can leverage exactly what you need and there is already a convention for forwarding the conversationId:

https://www.librechat.ai/docs/configuration/librechat_yaml/object_structure/custom_endpoint#headers