API contract
System prompt handling without ambiguous inputs
Keep system instructions explicit across prompt bodies, v2 messages, tenant defaults, and provider settings.
Developers who need predictable system-instruction behavior across providers.
The problem
System instructions can collide when a request sends both a body system_prompt and a system role message, or when tenant defaults also exist.
How LLM Proxy helps
LLM Proxy validates ambiguous system prompt inputs and applies tenant or provider system prompts only when request-level instructions are absent.
How it works
- Use body system_prompt only on compatibility POST / prompt-style requests.
- Use system role messages on POST /v2.
- Avoid sending both body system_prompt and a system message.
- Configure tenant defaults or provider-specific system prompts for omitted request instructions.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Ambiguity rejection | Bodies that combine system_prompt with system messages return 400. | The proxy avoids guessing instruction precedence. |
| Tenant default prompt | A tenant default system prompt can be prepended when submitted messages lack a system message. | Default behavior is server-owned. |
| Provider-specific prompt | Managed provider settings can store a system prompt for provider-selected requests. | Provider context travels with the saved provider. |
Use-case examples
Canonical /v2
A chat app sends a system role message and no body system_prompt.
Managed provider route
A request selects provider=deepseek and omits system instructions, so the saved provider prompt can apply.
Conflict cleanup
A migration removes duplicate system_prompt from bodies that already contain system messages.
Objections and limitations
- Server-injected system prompts are not echoed in response metadata.
- POST /v2 rejects body system_prompt by design.
- Provider-specific prompt behavior applies to managed provider-selected requests when request-level instructions are omitted.
FAQ
What is the main job of LLM system prompt handling?
LLM Proxy validates ambiguous system prompt inputs and applies tenant or provider system prompts only when request-level instructions are absent.
Who should read this api contract resource?
Developers who need predictable system-instruction behavior across 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 Canonical /v2 chat messages API for LLM calls, which covers v2 chat messages API.
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