What is a system prompt? How it works in LLM apps and coding agents

A system prompt is the set of standing instructions an application gives a language model before any user message: who the model is, what it knows, the rules it follows and the shape of its answers. It applies to every turn of the conversation, and models give it priority over what the user types.

If you have used ChatGPT, Claude or a coding agent, you have already talked to a model through a system prompt you never saw. This guide explains what a system prompt is, where it lives in each major API, what belongs in it, and how coding agents like Claude Code use one.

What does a system prompt do?

A language model on its own just continues text. The system prompt turns it into a specific assistant for a specific job. It typically sets:

• A role. "You are a code reviewer for a TypeScript monorepo."
• Context. Facts the model needs, such as the product, the audience or today's date.
• Rules. What to do and what to avoid, ideally with the reason.
• Output format. Markdown, JSON, a fixed template, a word limit.
• Edge cases. What to do when information is missing or a request is off topic.

Anthropic's prompting best practices put it simply: "Setting a role in the system prompt focuses Claude's behavior and tone for your use case. Even a single sentence makes a difference."

Consumer chat apps use system prompts too. Anthropic publishes the ones behind claude.ai and its mobile apps on its system prompts page, which explains that they "provide up-to-date information, such as the current date, to Claude at the start of every conversation." The same page notes that "These system prompt updates do not apply to the Claude API." When you call the API, you write your own.

How is a system prompt different from a user prompt?

The two play different roles in the same request. OpenAI's text generation guide describes the split well: "developer messages provide the system's rules and business logic, like a function definition," while "user messages provide inputs and configuration to which the developer message instructions are applied."

That priority is the point. OpenAI's guide says developer messages are "prioritized ahead of user messages," and that anything passed in its instructions parameter "will take priority over a prompt in the input parameter."

Where does the system prompt go in each API?

Each provider has its own field for it. The idea is the same everywhere.

Here is the shape of a Claude request, taken from Anthropic's docs:

message = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=1024,
    system="You are a helpful coding assistant specializing in Python.",
    messages=[
        {"role": "user", "content": "How do I sort a list of dictionaries by key?"}
    ],
)

Google's Gemini text generation docs say: "You can guide the behavior of Gemini models with system instructions. Pass a system_instruction parameter to configure the model's behavior."

One detail worth knowing on OpenAI: "the instructions parameter only applies to the current response generation request." If you chain responses, send the instructions again each time.

What should you put in a system prompt?

Anthropic's guidance for current Claude models boils down to a few habits:

1. Explain why, not just what. The docs contrast "NEVER use ellipses" with a version that says the response will be read aloud by a text-to-speech engine. "Claude can generalize from the explanation."
2. Show examples. "Examples are one of the most reliable ways to steer Claude's output format, tone, and structure." The docs suggest 3 to 5 and wrapping them in <example> tags.
3. Separate parts with XML tags. Tags like <instructions>, <context> and <input> reduce misreading when a prompt mixes several kinds of content.
4. Write at the right altitude. Anthropic's post on context engineering says system prompts "should be extremely clear and use simple, direct language that presents ideas at the right altitude for the agent," avoiding both brittle hard-coded logic and vague guidance.
5. Do not shout. The prompting guide notes that Claude Opus 4.5 and Opus 4.6 "are also more responsive to the system prompt than previous models," and suggests replacing "CRITICAL: You MUST use this tool when..." with "Use this tool when..."

A small, complete example:

You are a code reviewer for a Next.js app written in strict TypeScript.
Review only the diff you are given. For each problem, give the file, the line,
what is wrong and a fix. Our users are on slow mobile networks, so flag anything
that adds client-side JavaScript. If the diff looks fine, say so in one sentence.

For more starting points, see our system prompt examples.

How do coding agents use system prompts?

Coding agents layer several kinds of instructions, and only some of them are the system prompt.

In Claude Code, the output styles docs explain that by default "Claude works from Claude Code's standard system prompt, which is written for software engineering tasks." Your project file is separate. The memory docs state: "CLAUDE.md content is delivered as a user message after the system prompt, not as part of the system prompt itself."

If you need something at the system prompt level, Claude Code's CLI reference lists flags for it:

claude --append-system-prompt "Always use TypeScript"

Other pieces change the instructions too. An output style is sent "with every request" and sets role, tone and format for a session. Each subagent "runs in a separate context with its own system prompt." For lasting project conventions, the docs point you to CLAUDE.md instead. Codex and other tools read AGENTS.md for the same job.

Is a system prompt a security boundary?

No, and treating it as one is a common mistake. The OWASP Top 10 for LLM applications has an entry on system prompt leakage that says "the system prompt should not be considered a secret, nor should it be used as a security control."

In practice:

• Never put credentials in it. API keys, database names and internal URLs can leak.
• Enforce permissions in code. OWASP says privilege separation and authorization checks "must not be delegated to the LLM, either through the system prompt or otherwise."
• Assume instructions can be overridden. Untrusted text the model reads can try to change its behavior; see prompt injection in coding agents.

Claude Code's docs make the same point about its instruction files: Claude treats them "as context, not enforced configuration." To block an action no matter what, use a hook.

Does the system prompt cost tokens?

Yes. Anthropic's context windows guide says "Everything in the request counts toward the context window: the system prompt, every message in messages (including tool results, images, and documents), and your tool definitions." A long system prompt is paid for on every request.

Because it sits at the start and rarely changes, the system prompt is a natural fit for prompt caching. The flip side: Anthropic's API reports a system_changed cache miss reason when a request's system differs from the previous one, so editing it mid-session costs you the cache. See Claude Code prompt caching and LLM tokens explained for how that adds up.

Where should you keep your system prompts?

System prompts are code in all but name: you revise them, compare versions and reuse good ones across projects. Kipt keeps prompts and Agent Skills as Markdown in a private GitHub repo you own, with {{name}} blanks for the parts that change and Cmd+K search to find them again. If a system prompt has grown into a repeatable procedure, the free SKILL.md generator can turn it into a skill.

What should you read next?

To see what else lands in a model's context besides the system prompt, read context engineering. For how the model picks its words once it has its instructions, see LLM temperature. And when the model needs facts it was never trained on, what is RAG explains how apps fetch them at run time.