[Enhancement]: Allow `tokenConfig` on built-in endpoints (anthropic, openAI, google) so operators can correct context windows for models newer than the token map

[Odrec]

Follow-up to #15919, where @danny-avila confirmed the agents-endpoint parameter pick is intended (the agent's saved parameters are the source of truth) and suggested an operator-level tokenConfig for built-in endpoints as a separate feature request. This is that request.

The gap

tokenConfig already exists and already works — it's just scoped to custom endpoints only.

• Defined on the custom endpointSchema: packages/data-provider/src/config.ts L1382-1392
• Populated only in packages/api/src/endpoints/custom/initialize.ts L250-306
• Honoured by getModelMaxTokens (packages/api/src/utils/tokens.ts L673-694), which checks the override before the static map
• Already read on the agents path (packages/api/src/agents/initialize.ts L1405-1413)

So the plumbing is complete end-to-end. The only thing missing is that built-in endpoints never populate endpointTokenConfig. anthropicEndpointSchema (config.ts L1614-1621 on dev) carries only vertex and models.

Why it matters

New models are released faster than LibreChat releases. Between a model's launch and the release that adds it to anthropicModels (packages/api/src/utils/tokens.ts), that model falls back to the generic 'claude-' key at 100k.

For plain chat an operator can paper over this with modelSpecs[].preset.maxContextTokens. For agents — correctly, per #15919 — they cannot, because the agent's own parameters are authoritative. That leaves no operator-level lever at all for built-in endpoints, only per-agent manual entry by each agent's owner.

Concretely, on our instance before upgrading: 46 agents, 0 with maxContextTokens set, 6 on claude-sonnet-5/claude-opus-5 silently running at 100k instead of 1M. Nothing surfaces this to the user or the operator — the agent simply has a tenth of the context its owner expects.

The workarounds that exist today each have a real cost:

• Upgrade — correct, and what we're doing, but it only fixes models already in the shipped map; the next model reopens the gap.
• Route through a custom endpoint to get tokenConfig — gives up the built-in Anthropic endpoint's Vertex integration and prompt-caching handling.
• Per-agent manual entry — doesn't scale, and depends on every agent owner knowing the value.

Proposal

Accept tokenConfig on the built-in endpoint schemas and wire it into endpointTokenConfig, exactly as the custom endpoint path already does:

endpoints:
  anthropic:
    tokenConfig:
      claude-sonnet-5:
        context: 1000000

This is an operator-level default, not a client-supplied request parameter, so it doesn't conflict with the #15919 principle: an agent's own saved maxContextTokens still wins, since getModelMaxTokens is consulted only when the agent hasn't set one (agents/initialize.ts L1405-1413). It fills the gap between "the agent specified a value" and "the static map happens to know this model."

Scope could reasonably be just context at first — the pricing fields matter less for this use case.

Environment

Self-hosted, Docker, LibreChat v0.8.7 and v0.8.8-rc2, Anthropic via Google Vertex AI.

[Odrec]

One point worth making explicit, since it's the crux for operators on stable builds:

Upgrading fixes a model only once the release that knows it has shipped and we can deploy that release. We don't put -rc builds in front of users, so for us claude-sonnet-5 is unknown to the token map on v0.8.7 today, and stays unknown until a non-rc v0.8.8. That window is open right now and there is no operator-level lever for agents during it — only per-agent manual entry by each agent's owner, which relies on them knowing the correct value.

tokenConfig would close exactly that window without touching the agents-parameter model confirmed in #15919: it's an operator default, consulted only where getModelMaxTokens is already reached, so an agent's own saved value still wins.