Management UI
Provider-specific system prompts in LLM Proxy Settings
Store each provider's text model and system prompt with its managed provider configuration.
Users who need different instructions for different upstream providers.
The problem
A single global system prompt can be too blunt when different providers are used for different jobs or when provider-selected requests need their own context.
How LLM Proxy helps
LLM Proxy stores text model and provider-specific system prompt settings with each managed provider profile.
How it works
- Open the selected-provider editor in Settings.
- Choose the provider to configure.
- Set the provider text model and provider system prompt.
- Leave the changed field or switch providers; the selected provider settings autosave without a separate save action.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Provider-owned settings | Model and prompt live with the selected provider record. | Provider-specific routing context is explicit. |
| Runtime injection | Managed provider-selected requests can use the saved model and prompt when request fields are omitted. | Callers can stay concise. |
| Clear removal | Removing a provider key also removes provider settings. | The destructive boundary is explicit. |
Use-case examples
Concise OpenAI answers
A user stores an OpenAI system prompt that asks for concise responses.
DeepSeek default model
A user saves a DeepSeek model for provider-selected requests.
Provider cleanup
A user removes a provider key and settings after a trial ends.
Objections and limitations
- Request-level system instructions take precedence over server-injected defaults.
- Provider settings are scoped to the selected tenant owned by the authenticated TAuth subject.
- Autosave responses return masked key status; raw retrieval requires the separate owner-authenticated reveal action.
FAQ
What is the main job of provider-specific system prompts?
LLM Proxy stores text model and provider-specific system prompt settings with each managed provider profile.
Who should read this management ui resource?
Users who need different instructions for different upstream providers.
Does this page claim provider performance or pricing advantages?
No. The supported claim is about LLM Proxy's documented routing, configuration, management, security, usage, and deployment contracts. Provider cost, speed, rankings, and benchmark claims are not made here.
Where should setup details come from?
Use the main README and implementation notes for current command, config, and endpoint details. This page summarizes the workflow without replacing LLM Proxy documentation.
What should I read next?
A closely related resource is Self-service LLM key management for internal teams, which covers self-service LLM key management.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference