ModelRefs / Message Role — AI Glossary

Message Role — AI Glossary

The designation (system, user, assistant, tool) of a message in a chat completion request, controlling how the model interprets its content.

Overview

Standard roles: system (behavioral instructions, invisible to users), user (human input), assistant (model output, used for few-shot prefilling), tool (result returned from a function call). Anthropic uses an equivalent structure. Some providers add: function (legacy OpenAI), developer (differentiated instructions vs. operator instructions in newer APIs).

Reference details

Topicecosystem
Last reviewed2026-06-24

How it works

  1. Each message in the request carries a role tag, and the serialiser wraps its content in the role-specific delimiter tokens the model was trained on.
  2. Those delimiters are learned during instruction tuning, so the model's differing treatment of a system and a user message is a trained behaviour rather than an enforced rule.
  3. System content is positioned first and is trained to be treated as standing instruction, which is why it influences every later turn without being restated.
  4. User and assistant messages alternate to form the dialogue history, and writing synthetic assistant turns is how few-shot examples and output prefilling are expressed.
  5. Tool messages carry a call identifier that binds a result back to the specific tool invocation that requested it, which is what lets several parallel calls return out of order.
  6. Because the whole structure is a prefix, a stable system block sits at a stable offset and becomes cacheable, while the same text placed in each user turn does not.

Example: Why the role a string sits in has a price

Take a 1,800-token instruction block and 50,000 requests a day. Put it in the system role where it stays byte-identical across requests and it is a cacheable prefix: the prefill is charged at the cached-read rate on all but the first request of each cache lifetime. Put the same 1,800 tokens inside each request's user turn, after conversation history that differs per request, and no two requests share a prefix, so it is charged as ordinary input every time. The volume is identical either way: 1,800 x 50,000 = 90,000,000 tokens a day. At $3 per million that is $270 a day uncached, and at a cached-read rate of $0.30 per million it is $27 a day, so the difference is $243 a day — which is 243 x 365 = $88,695 a year for text that has not changed a word. The behavioural consequence runs alongside the cost. Instructions in the system role persist as standing context, whereas instructions in a user turn compete with the most recent user turn for precedence, and models trained on this structure give later user content more weight. So putting standing policy in the user role both pays full price and gets progressively less adherence as a conversation lengthens.

// Standing policy in the system role: stable prefix, cacheable.
messages: [
  { role: "system", content: POLICY },          // 1,800 tokens, byte-identical
  { role: "user", content: question },
  { role: "assistant", content: draft },         // prefill or few-shot turn
  { role: "tool", tool_call_id: "call_1", content: result },
]

// Same text, wrong role: prefix differs per request, nothing caches.
messages: [
  ...history,
  { role: "user", content: POLICY + "\n\n" + question },
]

Commonly confused with

A message role is not a permission boundary, and treating it as one is the root of most prompt-injection incidents. The system role is a trained convention about how to weigh content, not an enforcement mechanism: text placed there is not protected, and text arriving in a tool result is not sandboxed. If a retrieved document contains instructions and lands in a tool message, the model may well follow them, because the role tells it where the content came from and not whether to trust it. The second confusion is between the system role and a developer or operator role as introduced in newer APIs, which exists precisely because one tier of instruction proved insufficient once applications needed to layer their own policy above an end user's but below the provider's.

When to use it

Reach for it when:

  • System for standing behaviour, which both persists across turns and keeps the prefix stable enough to cache.
  • Assistant for few-shot demonstrations and output prefilling, which is the supported way to constrain format without describing it.
  • Tool with the originating call identifier, so parallel results bind back to the right invocation.
  • User strictly for content originating with the user, which keeps the structure honest about provenance.

Reach for something else when:

  • As a trust boundary, since no role prevents the model from acting on instructions embedded in its content.
  • With standing instructions duplicated into each user turn, which cost $88,695 a year in the case above and get weaker adherence.
  • Putting retrieved documents in the system role to raise their priority, which removes the provenance signal and makes injection easier.
  • Assuming role semantics transfer unchanged across providers, where the available roles and their trained weighting differ.

Continue your research

Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Message Role — AI Glossary.

Frequently asked questions

What is Message Role?

The designation (system, user, assistant, tool) of a message in a chat completion request, controlling how the model interprets its content.

What concepts are related to Message Role?

Closely related concepts include system message, user message, assistant message.