[FEATURE] Runtime-selectable custom header per chat — configurable dropdown in third-party inference settings, with static or helper-script-provided values

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Desktop in third-party (3P) inference mode already supports custom request headers via inferenceCustomHeaders, but the value is static for the entire profile: it is set once in the managed/bootstrap configuration and applies identically to every request from every chat. Changing it requires editing the configuration and restarting the app.

We need the user to be able to choose the value of such a header at runtime, per individual chat.

Proposed Solution

Add the ability to define a configurable dropdown from the third-party inference settings, specifying:

• Header name — the custom header to attach to requests (e.g. X-Team-Id)
• Dropdown label — the name shown in the chat UI next to the model picker

The list of selectable values should be resolvable in either of two ways:

1. Statically — an explicit list provided in the configuration, or
2. Dynamically — an absolute path to a helper script that prints the available values, allowing the list to be computed at runtime rather than baked into the profile

The selected value is then sent as the configured header on every inference request originating from that specific chat, independently of the selected model or effort level.

Credential passing to the helper script

For the dynamic case, it is essential that Claude Desktop can pass the helper script the same credentials it uses for inference. The helper typically needs to query an authenticated endpoint to determine which values the current user is entitled to, and duplicating or separately provisioning credentials just for the helper defeats the purpose. This would mirror the existing inferenceCredentialHelper pattern, but in the opposite direction — credentials flowing to the helper rather than being produced by it.

Re-run model discovery with the selected header

Once the dropdown is active, when the user create a new chat, Claude Desktop should issue a GET /v1/models request carrying the default value of that header (eg. the first value).
Also, when the user expands it and manually selects a value, Claude Desktop should issue a new GET /v1/models request carrying that header, so the gateway can return the model list appropriate for the selected value.

The model picker would then reflect only the models actually available in that context.

Environment

• Claude Desktop, 3P inference mode, gateway provider (Anthropic Messages API), Amazon Bedrock upstream
• macOS and Windows, managed via MDM

Happy to provide more detail on our setup if useful.

Alternative Solutions

• inferenceCustomHeaders — static and global to the profile; requires an app restart to change. No per-chat granularity.
• One inferenceModels entry per team per model — pollutes the model picker with routing/billing metadata unrelated to model capability, multiplies every tier by the number of teams, and still cannot express "this whole chat belongs to team X." It also cannot express team-dependent model availability, since the list is fixed at configuration time.
• Separate configuration profiles per team — requires a full app restart to switch context, and cannot support two chats in different team contexts at the same time.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

Scenario

A user belongs to multiple teams/projects:

• Every inference request must carry a header identifying which team/project the inference is being performed for — this drives cost attribution, budget isolation, and access boundaries on our side.
• The model list returned by /v1/models can itself depend on the team/project — different teams have access to different model sets.

Our deployment routes through an in-house gateway implementing the Anthropic Messages API, with Amazon Bedrock upstream. The team/project context cannot be inferred from the model ID or from the user's identity alone, because the same user legitimately works across several of them in the same day.

Additional Context

_No response_