If you repeat the same setup in every conversation, you are losing time and getting inconsistent results. The system prompt exists for that: setting the frame the model works in, once and for all.
It is the first thing to configure when you move from occasional to regular use. It is also what turns a generic assistant into something closer to a colleague who knows your rules.
Definition
The system prompt is a permanent instruction, placed ahead of any conversation, defining the model's role, tone, rules and limits. Unlike an ordinary Prompt, which covers one request, it applies to every answer in the session.
The clearest comparison is a job description. The system prompt says who you are, how you work and what you do not do. The prompts that follow are the day-to-day requests.
Models give more weight to the system prompt than to conversation messages. That is deliberate: it lets safety or tone rules survive a contrary request made mid-exchange.
What goes in it
| Element | Example |
|---|---|
| Role | "You are the support assistant for invoicing software aimed at freelancers" |
| Tone | "Short sentences, no technical jargon" |
| Rules | "Answer in three paragraphs at most. Always end with the next step to take" |
| Prohibitions | "Never give tax advice. Never promise a fix deadline" |
| Fallback | "If the information is not in the supplied documentation, say so and offer to pass it to a human" |
That last line is the most important and the most often forgotten. Without an explicit fallback, a model faced with a question outside its scope will invent a plausible answer rather than admit ignorance. That is the direct mechanism behind Hallucination.
Best practices
Write checkable rules. "Three paragraphs maximum" can be verified, "be concise" cannot. The more measurable a rule, the better it is followed.
Keep it short. A three-page system prompt consumes Token on every call and is followed less well than fifteen well-chosen lines. If everything is important, nothing is.
Put prohibitions at the end. What sits at the start and the end is respected better than what sits in the middle. The rules you care about most deserve those positions.
Version it. A system prompt that evolves without history quickly becomes impossible to debug. Keep a record of changes, as with any production setting.
Test on your edge cases. A frame is judged on awkward requests, not easy ones. Take your five most painful customer questions and check the behaviour.
Never treat the system prompt as an absolute security barrier. A well-turned Prompt injection can work around it. Anything that truly must not get out has no business being in the model's context: filter it upstream, in your code or your tool, not in a sentence of instruction.
Frequently asked questions
Where do you actually set it?
In consumer interfaces it often goes by another name: custom instructions, preferences, or project instructions. In an automation tool or in direct model access, it is a dedicated field, separate from the user message.
Is it billed on every message?
Yes, it is resent on every call and therefore counts towards input tokens. At high volume that justifies keeping it short, and using prompt caching where your provider offers it.
Can it enforce a strict format?
Only up to a point. For a genuinely constrained format, use the Structured output mechanisms providers offer, which guarantee the shape where an instruction merely requests it.
How do you build a solid frame for professional use?
By starting from the cases that cause trouble rather than the ideal case, and adding one rule at a time. Our Claude Cowork course covers that gradual construction, including how to test each rule before adding it.