Management UI
Provider-specific system prompts in the tenant dashboard
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
- Select a tenant and one of its connected providers.
- Open the connection details below the map.
- Enter the tenant provider prompt.
- Select Save provider prompt. Save a default model through its separate action.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Tenant provider profiles | The model and prompt belong to the tenant provider profile. | Sharing credentials preserves separate tenant prompts. |
| Runtime injection | Managed provider-selected requests can use the saved model and prompt when request fields are omitted. | Callers can stay concise. |
| Preserved profiles | Detaching a connection preserves the tenant provider prompt and model. | Dependent default routes require explicit clearing during detachment. |
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 detaches a trial connection. Its other tenant assignments remain intact.
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.
- Connection responses contain masked credentials. The provider prompt remains a tenant property.
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