[Enhancement]: Composable modelSpecs — let admins define orthogonal option groups (prompt, reasoning effort) that users select independently of the model

[thekk1]

What features would you like to see added?

What features would you like to see added?

Today, modelSpecs.list is the only place where an administrator can pin down
a model together with promptPrefix and model parameters such as
reasoning_effort. Because a spec is a single flat object, every combination
of these properties has to be materialised as its own list entry.

With M models, P admin-provided system prompts and E reasoning-effort levels,
this requires M x P x E entries. In our deployment (3 models, 4 prompts,
3 effort levels) that is 36 near-identical entries, and the model selector
becomes an unusable flat list in which the actual model is the least visible
part of the label.

I would like to declare each property once, and let the user combine them:

• Admin defines the available models (as today).
• Admin defines named option groups, e.g. a "Role" group holding several
  promptPrefix values, and an "Effort" group holding several
  reasoning_effort values.
• The user picks a model, then picks one choice per option group.

Expected behaviour

• The model selector lists only the entries of modelSpecs.list (3 entries in
  the example, not 36).
• Each referenced option group renders as its own control, next to the model
  selector or in the parameters panel, showing its label and choices.
• A spec omitting optionGroups behaves exactly as today. Existing
  configurations are unaffected; the feature is purely additive.
• The resolved combination is persisted with the conversation, so reopening an
  old chat restores model plus selected options.
• enforce: true keeps its meaning: the user may only pick among the offered
  choices and cannot supply free-form values.
• Option groups referenced by a spec but not defined are reported at startup
  as a config error rather than silently ignored.

More details

Proposed configuration

modelSpecs:
  optionGroups:
    - name: 'role'
      label: 'Role'
      default: 'general'
      choices:
        - name: 'general'
          label: 'General assistant'
          preset:
            promptPrefix: |
              You are a helpful assistant.
        - name: 'code-review'
          label: 'Code review'
          preset:
            promptPrefix: |
              You review Java code. Be terse and cite line numbers.

    - name: 'effort'
      label: 'Reasoning effort'
      default: 'medium'
      choices:
        - name: 'low'
          label: 'Fast'
          preset:
            reasoning_effort: 'low'
        - name: 'medium'
          label: 'Balanced'
          preset:
            reasoning_effort: 'medium'
        - name: 'high'
          label: 'Thorough'
          preset:
            reasoning_effort: 'high'

  list:
    - name: 'qwen3-27b'
      label: 'Qwen3 27B'
      preset:
        endpoint: 'local-llm'
        model: 'qwen3-27b'
        temperature: 0.85
      optionGroups: ['role', 'effort']

    - name: 'gpt-5'
      label: 'GPT-5'
      preset:
        endpoint: 'openAI'
        model: 'gpt-5'
      optionGroups: ['role']        # no effort selector for this model

Merge order, applied deterministically and documented:
spec.preset -> option groups in the order listed on the spec.
A later group overrides an earlier one for the same key.

Optional refinements

• showInMenu per option group, so an admin can pin a value without exposing
  the selector.
• A permissions/role filter per choice, so some prompts are only offered to
  certain roles.
• Support for arbitrary preset keys inside a choice, not just promptPrefix
  and reasoning_effort — the mechanism is generic.

Alternatives considered

• Generating the cross product. Works (see discussion Models defined in modelSpecs not visible in UI #10442, which
  generates modelSpecs with minijinja and yq), but it only shrinks the YAML
  source. The user-facing selector still contains every combination.
• User presets. Presets are user-owned and cannot be centrally curated or
  enforced by an administrator.
• Agents. An agent bundles instructions with tools and a model. It solves
  the "curated role" half but reintroduces the same multiplication as soon as
  the same role should be available on several models or effort levels, and it
  is heavier than what is needed for a plain system-prompt choice.

Related

• Discussion Models defined in modelSpecs not visible in UI #10442 (composable prompt presets / cross-product generation)
• Discussion Model Specs Settings a little buggy #3187 (modelSpecs flexibility)
• Discussion LibreChat Configuration: Prefix Prompts and Custom Endpoint Setup #10948 (promptPrefix only configurable via modelSpecs)

Which components are impacted by your request?

No response

Pictures

No response

Code of Conduct

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