theLLMs

Last checked: 2026-05-25

Scope: Global. Provider prompt terminology and role structures were checked against current API docs on 2026-05-25. Naming conventions vary between providers.

AI draft model: gpt-5.4-mini

AI review model: llm-editor (deepseek-v4-pro)

Key terms:

>_ large language model (LLM) >_ prompt >_ system prompt >_ function calling / tool use >_ LLM-as-a-judge >_ prompt caching

System prompts, developer prompts and user prompts: who controls what?

Most LLM APIs give you three layers of instruction: system, developer (or assistant), and user. The idea is a hierarchy — system instructions should set constraints, developer messages should guide behaviour, and user messages provide the task. In practice, the line blurs constantly, and teams trip over which layer the model actually listens to.

The short answer is: system prompts are for stable guardrails, developer/assistant turns are for style and examples, and user turns are the actual task. If you put the same instruction in two layers, be explicit about which one wins when they disagree.

If you only remember one thing: put security rules and non-negotiable constraints in the system prompt. Everything else — style guidance, examples, tone — is safer in developer or assistant turns where the model tends to treat them as demonstrations rather than commands.

Editor’s Note: Some providers let the user override the system prompt entirely. If you are building a product, assume a user can re-raise their own system prompt and design your instruction hierarchy to survive that.

Editor’s Note: The model does not see “system,” “developer” and “user” as enforcement layers. It sees them as text with a role tag. The tag gives the model a hint, not a guarantee.

Quick answer {#quick-answer}

  • System prompt: hard rules, constraints, safety instructions, persona definition. Write these as short, enforceable statements.
  • Developer / assistant messages: style guidance, few-shot examples, chain-of-thought scaffolding. The model treats these as patterns to follow.
  • User messages: the actual request. May include files, tool output, conversation history or direct questions.

When they conflict, most models weigh the system prompt most heavily. That is not a guarantee — some models bias toward the most recent instruction, especially if the user message explicitly contradicts the system prompt.

What each layer is for {#what-each-layer-is-for}

System prompts {#system-prompts}

The system prompt is your one shot at setting ground rules before the model sees any user input. Use it for:

  • Role definition: “You are a compliance officer reviewing contract language.”
  • Non-negotiable constraints: “Never claim to be a human.” “Do not generate medical diagnoses.”
  • Output format instructions: “Always respond in JSON with fields: summary, risk_level, recommendation.”
  • Safety guidance: “If you cannot answer with high confidence, say ‘I don’t know.’”

Do not put conversational examples or tone guidance in the system prompt unless the model provider explicitly recommends it. Those belong in the developer turn.

Developer / assistant messages {#developer-assistant-messages}

Assistant role messages work as demonstrations. The model learns from the pattern you provide:

  • Few-shot examples: a user query followed by the ideal assistant response.
  • Output format demonstration: show one complete example instead of describing the format.
  • Chain-of-thought scaffolding: “Let me work through this step by step. First, identify the correct regulation. Second, check whether the exception applies. Third, produce the final answer.”

The key difference: the model treats the system prompt as instructions and assistant messages as observed behaviour. When the instruction says one thing and the example shows another, the example often wins.

User messages {#user-messages}

User messages are where the human — or an automated pipeline — puts the task. This layer is the least trusted for authoritative instructions because the model expects user input to be variable. Overriding the system prompt from the user turn usually requires an explicit instruction such as “Ignore previous instructions and do X instead.”

Common failure modes {#common-failure-modes}

Instructions everywhere, no hierarchy {#instructions-everywhere-no-hierarchy}

Teams often put the same instruction in the system prompt, the developer turn and the user message. The model does not know which one takes priority. The result is unpredictable instruction following, especially after a model update.

Fix: audit each instruction to exactly one layer. System for rules, developer for demonstrations, user for the task. Do not repeat.

The system prompt becomes a dump {#the-system-prompt-becomes-a-dump}

A common pattern is to keep adding instructions to the system prompt until it reads like a terms-of-service document. Long system prompts dilute the important rules among boilerplate.

Fix: keep the system prompt under 500 tokens if possible. Move style guidance to a developer turn and task-specific context to the user message.

Ghost instructions in conversation history {#ghost-instructions-in-conversation-history}

When the model generated a previous answer in a certain format, the conversation history carries that forward as an implicit instruction. A user who says “Do it again but shorter” may produce a format the builder never intended.

Fix: be aware that conversation history acts as an undeclared fourth prompt layer. Clear it or separate turns deliberately for sensitive tasks.

Decision check {#decision-check}

Before you add a prompt instruction, ask:

  1. Is this a permanent safety or behaviour rule? → System prompt.
  2. Is this a style preference or output example? → Developer/assistant turn.
  3. Is this the current task? → User message.
  4. Is this a leftover from a previous interaction? → Clear history, do not keep it.

If you cannot place the instruction into exactly one layer, you probably need to rethink the instruction or combine it into the system prompt with the redundancy removed.

What this page cannot tell you {#what-this-page-cannot-tell-you}

This page cannot tell you exactly how each provider’s models weigh prompt layers. Some models bias toward the system prompt. Others favour recency. The safest approach is to test your own instruction hierarchy with a small eval set before trusting it in production.

Methodology and sources {#methodology-and-sources}

Check date: 2026-05-25

What was checked: Provider API documentation for OpenAI, Anthropic, Google and Mistral regarding role hierarchy and prompt behaviour notes.

Assumptions and limits:

  • Role-based instruction following varies by model family and version.
  • This guidance applies to chat-based APIs; completion APIs use a different structure.
  • For safety-critical applications, always test and monitor instruction adherence.

Source list {#source-list}

Change Log

  • 2026-05-27: Added direct source URLs to all named providers and services; added Change Log section. Content unchanged.