Skip to content

🎯 fix: Infer Agents Endpoint for Model Specs Naming an Agent - #14889

Open
danny-avila wants to merge 1 commit into
mainfrom
fix/model-spec-agent-endpoint-inference
Open

🎯 fix: Infer Agents Endpoint for Model Specs Naming an Agent#14889
danny-avila wants to merge 1 commit into
mainfrom
fix/model-spec-agent-endpoint-inference

Conversation

@danny-avila

Copy link
Copy Markdown
Owner

Problem

A model spec whose preset names an agent_id but omits endpoint is completely unusable — selecting it fails every time with:

Something went wrong. Here's the specific error message we encountered: Model spec mismatch

The match is strict equality:

export function isModelSpecEndpointMatch(modelSpec, endpoint): boolean {
  return Boolean(modelSpec && endpoint === modelSpec.preset?.endpoint);
}

With preset.endpoint undefined, that is false for every endpoint. There is no code path where such a spec can match, so it is dead on arrival — and the error names neither the spec nor the missing field, which makes it hard to act on.

This is easy to hit when a spec is authored through a UI rather than hand-written YAML, since only the agent_id is strictly meaningful to the author.

The selector had the same gap

Fixing only the server would not have been enough. handleSelectSpec read preset.endpoint directly:

if (isAgentsEndpoint(spec.preset.endpoint)) {
  model = spec.preset.agent_id ?? '';
}
setSelectedValues({ endpoint: spec.preset.endpoint, model, modelSpec: spec.name });

With the endpoint undefined, the client sends no endpoint and skips assigning agent_id to model — so the request is malformed before it reaches the check. Both halves need the same resolution, which is why this lives in librechat-data-provider rather than in either consumer.

Changes

  • Add resolveModelSpecEndpoint to librechat-data-provider: returns preset.endpoint when set, otherwise infers agents when the preset names an agent_id. Only the agents endpoint can serve such a preset, so the inference is unambiguous.
  • Use it for endpoint matching (packages/api/src/modelSpecs) and in the selector, so the menu and the request pipeline resolve a spec identically.

An explicit endpoint always takes precedence, so existing configured specs are unaffected. Nothing is inferred for presets without an agent.

Scoped to agent_id only — assistant_id is intentionally left alone, as assistants are being removed.

Testing

packages/api and client typecheck clean. modelSpecs suite 11 → 14 tests, and the existing buildEndpointOption middleware suite (13 tests) still passes. New cases cover:

  • preset with agent_id, no endpoint → matches agents, not other endpoints
  • explicit endpoint alongside agent_id → explicit wins
  • preset with neither → infers nothing

A model spec whose preset names an `agent_id` but omits `endpoint` was
unusable. `isModelSpecEndpointMatch` compares the request's endpoint to
`preset.endpoint` by strict equality, so an undefined endpoint matched
nothing and every request selecting the spec was rejected with a bare
`Model spec mismatch` — an error naming neither the spec nor the missing
field.

The selector had the matching half of the same gap: `handleSelectSpec`
read `preset.endpoint` directly, so it sent no endpoint and skipped
assigning `agent_id` to `model`. Fixing only the server would leave the
request malformed, so the resolution is shared between both.

- Add `resolveModelSpecEndpoint` to `librechat-data-provider`, inferring
  the agents endpoint when a preset names an agent and none is set. An
  explicit `endpoint` always wins, so configured specs are unaffected.
- Use it for endpoint matching and in the selector, so the menu and the
  request pipeline resolve a spec identically.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant