The system slot — your sticky instruction

Of the three API slots, system is the one that changes how every reply feels. Treat it like the model's job description. It is the only field the model reads on every single turn, regardless of how long the conversation gets.

A minimal API call looks like this:

{
  "model": "claude-sonnet-4-5",
  "system": "You are a Cairo specialty coffee assistant for Bayt Coffee.",
  "messages": [
    { "role": "user", "content": "Recommend a beginner-friendly bean." }
  ]
}

The system string is your sticky instruction. It defines who the model is, what it must do, what it must refuse, and how it should sound. It does not appear in the chat transcript the user sees — but it shapes every word the model produces.

Three properties that make system different from a user message

1. Persistence. A user message is read once, in context. A system message is re-applied on every turn. Even after 50 back-and-forth messages, the system instruction is still pinning down behaviour.
2. Priority. The model is trained to weight system instructions higher than user instructions when they conflict. If your system prompt says "never discuss pricing" and the user begs for a price, a well-tuned model holds the line.
3. Privacy. The user does not see your system prompt. This is where business logic, voice rules, and refusal lists live.

What belongs in the system slot — and what does not

Things that belong: role, voice, hard rules ("never use the word X"), refusal scope, output format defaults, examples of good output.

Things that do not belong: the actual user question, fast-changing facts ("today is Tuesday"), or anything that varies per request. Those go in the messages array.

A simple test: if removing this line would change what kind of assistant this is, it goes in system. If removing this line would only change today's answer, it goes in the user message.

Next: same task, two prompts — and the live model output for each. :::