Cannot Enable Responses API by Default

[jcbartle]

What happened?

With the recent changes to "Upload to Provider" instead of "Upload Image", we want to auto-enable the Responses API toggle so that users have the maximum number of file types available for "Upload to Provider". However, this doesn't seem to be working. If I configure the Responses API to be enabled by default via librechat.yaml as so:

    customParams:
      defaultParamsEndpoint: azureOpenAI
      paramDefinitions:
        - key: useResponsesApi
          default: true

The toggle is on when you start a conversation, but the /responses endpoint is not called - it still calls the /chat/completions endpoint. Only once you toggle Responses API off and on again does it start using the /responses endpoint. I haven't been able to trace what's actually happening behind the scenes to cause this behavior.

This is consistent no matter I fill in for defaultParamsEndpoint. azureOpenAI is above, but I tried openAI and custom as well.

Version Information

v0.8.1-rc1

Steps to Reproduce

Add customParams to your librechat.yaml file like so:

    customParams:
      defaultParamsEndpoint: azureOpenAI
      paramDefinitions:
        - key: useResponsesApi
          default: true

Launch the app.

Start a new conversation.

Verify in the Parameters section that Responses API is toggled on.

Send your query.

View logs to see that the /chat/completions endpoint was called.

Manually toggle Responses API off and on.

Resend your query.

View logs to see that the /responses endpoint was called.

It's very easy to validate that it's calling one endpont or another because, if you use the "Upload to Provider" feature to attach a PDF, it will fail the first time because the /chat/completions endpoint doesn't support files.

What browsers are you seeing the problem on?

Microsoft Edge

Relevant log output

I also validated in Firefox.

Screenshots

No response

Code of Conduct

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

[danny-avila]

customParams is for custom endpoints only.

You should use model specs and a default model spec for certain parameter combinations made easily available to users.

There are other ways to address what you're suggesting that are planned, see: #10054

[jcbartle]

Morning, @danny-avila. We are using a custom endpoint with the customParams feature. Sorry for not including that information up front.

custom:
- name: "Azure AI Foundry"
  apiKey: "your_api_key"
  baseURL: "https://ai-gateway.yourorg.com/azure-openai-v1"
  customParams:
    defaultParamsEndpoint: azureOpenAI
      paramDefinitions:
        - key: useResponsesApi
          default: true
  models:
    default:
	- "gpt-5-chat-2025-10-03"
	- "gpt-4.1-nano-2025-04-14"
    fetch: false
  summarize: false
  titleConvo: true
  titleModel: "gpt-4.1-nano-2025-04-14"

However, the useResponsesApi setting does not function correctly, as described in the original report. This seems to be a bug.

modelSpec does not meet our need, as it has two side effects (unless I'm mistaken). The first is that the modelSelect dialog cannot be grouped, which makes the list extremely long if you have many models for which you would need to default to the Responses API. The second is that parameters cannot be adjusted (or even viewed) when selecting an item from the modelSelect dialog which uses a modelSpec. This doesn't allow users to see or adjust parameters. Based on your suggestion, I did test this, and I can confirm that the Responses API setting does work correctly when set via modelSpec using something like this (cut down for brevity):

modelSpecs:
  enforce: false
  prioritize: false
  addedEndpoints:
    - "Azure AI Foundry"
  list:
    - name: "gpt-5-chat-2025-10-03"
      label: "gpt-5-chat-2025-10-03"
      default: true
      preset:
        endpoint: "Azure AI Foundry"
        model: "gpt-5-chat"
        useResponsesApi: true

It's great that this works, but it doesn't address the initial bug report.

Thank you for highlighting #10054; however, this doesn't seem to address the situation. customParams allows you to specify default values which can be adjusted. addParams / dropParams occurs after submission and the user has no control over these. I think this is a great and useful feature (and we're using it elsewhere), but it doesn't address the situation here.

[danny-avila]

Thanks for the additional info. Just want to add that addParams / dropParams influences how the payload is built, post-user submission but pre-API interaction, so useResponsesApi can be specified.

In any case, I will try to reproduce with a similar Azure setup.

[jcbartle]

Thanks so much, @danny-avila - I appreciate it.

[danny-avila]

I implemented this here, merging to main soon:

#10457

In this case, it will apply default params in the backend as well, if the param is not explicitly configured

[jcbartle]

Thank you for the amazingly fast fix! 💯 I've confirmed this did the trick!