Skip to content

fix: forward modelLabel to AgentClient so it reaches the model - #15332

Open
AyushCipher wants to merge 23 commits into
danny-avila:devfrom
AyushCipher:fix/modelspec-modellabel-context
Open

fix: forward modelLabel to AgentClient so it reaches the model#15332
AyushCipher wants to merge 23 commits into
danny-avila:devfrom
AyushCipher:fix/modelspec-modellabel-context

Conversation

@AyushCipher

@AyushCipher AyushCipher commented Aug 29, 2026

Copy link
Copy Markdown
Contributor

modelSpecs.list[].preset.modelLabel was resolved and displayed correctly in the UI, but was never actually sent to the model for any endpoint (custom endpoints like OpenRouter included, since all endpoints now route through the unified AgentClient).

api/server/services/Endpoints/agents/initialize.js already computed the display sender name from endpointOption.model_parameters.modelLabel, but never forwarded the raw value into the options object passed to new AgentClient(...). AgentClient (client.js) already expected this.options.modelLabel in several places but most importantly to set assistantName in formatMessage(), which stamps a name field onto outgoing assistant messages, making the label visible to the model, so the value was silently undefined the whole time.

Fixes #14968

Summary

Forward the already-resolved modelLabel into the AgentClient constructor options in api/server/services/Endpoints/agents/initialize.js, so it reaches formatMessage()'s assistantName and is included in the model-visible message context, matching the documented behavior. No other files needed changes. The value was already being parsed and resolved correctly everywhere else.

Change Type

  • Bug fix (non-breaking change which fixes an issue)

Testing

Added a test case in api/server/services/Endpoints/agents/initialize.spec.js that simulates a custom-endpoint (OpenRouter-style) ephemeral agent with model_parameters.modelLabel set, and asserts the value reaches the captured AgentClient constructor args.

Ran:

  • jest server/services/Endpoints/agents/initialize.spec.js — 50/50 passing (including the new test)
  • eslint on both touched files — clean
  • prettier --check on both touched files — clean
  • The repo's static-checks pre-commit hook (lint-staged, circular-dependency check) — passed

Test Configuration:

Node v22 (repo declares >=24.0.0; ran with a slightly older local Node, no issues observed), Windows.

Checklist

  • My code adheres to this project's style guidelines
  • I have performed a self-review of my own code
  • I have commented in any complex areas of my code
  • My changes do not introduce new warnings
  • I have written tests demonstrating that my changes are effective or that my feature works
  • Local unit tests pass with my changes

modelSpecs.list[].preset.modelLabel was resolved and displayed correctly
in the UI, but was never actually sent to the model for any endpoint
(custom endpoints like OpenRouter included, since all endpoints now
route through the unified AgentClient).

api/server/services/Endpoints/agents/initialize.js already read
endpointOption.model_parameters.modelLabel to compute the display
sender name, but never forwarded the raw value into the options object
passed to `new AgentClient(...)`. AgentClient (client.js) already
expected `this.options.modelLabel` in several places - most importantly
to set `assistantName` in formatMessage(), which stamps a `name` field
onto outgoing assistant messages, making the label visible to the
model - so the value was silently undefined the whole time.

Fixes danny-avila#14968
Copilot AI lite review requested due to automatic review settings August 29, 2026 13:22

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟢 Approval recommended

The change is narrowly scoped, matches the documented/expected data flow, and includes a targeted test asserting the forwarding behavior.

Pull request overview

This PR fixes a gap in the unified Agents endpoint flow where modelSpecs.list[].preset.modelLabel was correctly resolved/displayed in the UI but never forwarded into the AgentClient options, preventing it from reaching model-visible message context (via formatMessage()’s assistant name).

Changes:

  • Forward endpointOption.model_parameters.modelLabel into the new AgentClient(...) constructor options so client.js can use this.options.modelLabel (including for formatMessage() and getSaveOptions()).
  • Add a Jest test that simulates a custom endpoint ephemeral agent (OpenRouter-style) and asserts the AgentClient constructor receives modelLabel.
File summaries
File Description
api/server/services/Endpoints/agents/initialize.js Passes modelLabel through to AgentClient options so it can be applied to outgoing assistant messages and persisted in save options.
api/server/services/Endpoints/agents/initialize.spec.js Adds coverage to ensure model_parameters.modelLabel is forwarded for custom endpoint ephemeral agents.
Review details
  • Files reviewed: 2/2 changed files
  • Comments generated: 0
  • Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@github-actions
github-actions Bot changed the base branch from main to dev August 31, 2026 20:25
@github-actions

Copy link
Copy Markdown
Contributor

👋 Thanks for the contribution! LibreChat merges all changes into dev first — main only moves at release time — so this pull request's base branch was switched from main to dev automatically.

Nothing is needed from you; your commits, reviews and discussion are unchanged. If the diff now shows files you did not touch, rebase onto dev:

git remote add upstream https://github.com/danny-avila/LibreChat.git
git fetch upstream dev
git rebase upstream/dev
git push --force-with-lease

Maintainers: apply the target: main label and restore the base branch if this one genuinely belongs on main.

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.

[Bug]: modelLabel is displayed in the UI but not passed to the model

2 participants