Claude API System Prompt Examples & Custom Instructions

What a system prompt actually does in the Claude API

The system parameter in the Claude API is where you set custom instructions that apply to every message in a conversation, separate from the messages array. It's the mechanism for defining persona, tone, output format, constraints, and domain knowledge once, instead of repeating it in every user turn. If you're searching for "claude api custom instructions system prompt examples," you're likely trying to figure out exactly how to structure that field and what good instructions look like in practice.

The short answer: the system prompt is a plain string (or array of content blocks) passed alongside messages, and it's most effective when it's specific, structured, and testable — not a vague paragraph of adjectives. Below are concrete examples you can adapt, plus the patterns that make system prompts reliable across many requests.

Basic structure of a request with a system prompt

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "system": "You are a senior backend engineer. Answer in concise bullet points. Never suggest deprecated APIs.",
    "messages": [
      {"role": "user", "content": "How should I handle retries for a flaky HTTP client?"}
    ]
  }'

The pattern is consistent: system sets the rules, messages carries the conversation. Everything below just changes what goes inside that string.

Persona and tone examples

Persona instructions work best when they name a role and a constraint, not just an adjective like "friendly."

You are a customer support agent for a B2B SaaS billing platform.
Tone: direct, calm, no corporate filler phrases.
Never apologize more than once per response.
If you don't know an answer, say so and offer to escalate.

You are a technical writer producing API documentation.
Use active voice and second person ("you").
Avoid marketing language entirely.
Every code example must be runnable as-is.

Output format constraints

This is one of the highest-value uses of custom instructions — forcing a consistent, parseable shape.

Always respond in valid JSON matching this schema:
{"summary": string, "action_items": string[], "risk_level": "low"|"medium"|"high"}
Do not include any text outside the JSON object.

Respond only in Markdown.
Use ## for section headers and numbered lists for steps.
Never use emoji.

If your application parses Claude's output programmatically, this kind of strict format instruction in the system prompt is more reliable than asking for it in the user message, because it persists across the whole conversation without re-stating it.

Domain and knowledge-scoping instructions

System prompts are also where you restrict what the model is allowed to talk about or assume.

You are a support assistant for a legal tech product.
You are not a lawyer and must not give legal advice.
If asked a legal question, provide general information and recommend consulting counsel.
Only answer questions about the product's features, pricing, and onboarding.

You only answer questions about Python 3.11+ standard library usage.
If asked about third-party libraries, state that you don't cover them and suggest checking the library's docs.

Multi-step behavior and reasoning instructions

For agents or tools that need consistent step-by-step behavior, put the procedure in the system prompt rather than repeating it per request.

Before answering, silently check:
1. Is the question about billing, technical setup, or account access?
2. Does it require data you don't have access to?
If (2) is true, ask a clarifying question instead of guessing.
Otherwise, answer directly without restating these steps.

This pattern — instructions the model follows internally without echoing them back — is one of the more common things people get wrong. Be explicit that the steps are internal if you don't want them repeated in the output.

Combining system prompts with tool use

If you're using Claude's tool-calling features, the system prompt is also where you clarify tool-selection policy, since the tool schema itself only defines inputs/outputs, not when to use them.

You have access to a `search_orders` tool.
Only call it when the user references an order number or asks about order status.
Do not call it for general product questions.

See /docs/tools for how tool definitions and system instructions work together in a single request.

Testing and iterating on system prompts

A few practical habits that save time:

• Version your prompts. Keep system prompts in source control like any other config, not hardcoded inline strings scattered across your codebase.
• Test with edge cases, not just the happy path — ambiguous questions, off-topic requests, and adversarial inputs reveal whether your constraints actually hold.
• Keep it shorter than you think you need. Long, repetitive system prompts don't make instructions "stronger" — they often introduce contradictions that confuse the model.
• Separate persistent rules from per-request context. Put stable instructions (tone, format, scope) in system, and put conversation-specific data in messages.

If you're running this in production across a team — multiple people iterating on prompts, multiple applications hitting the same underlying Claude access — managing raw API keys and tracking which prompt version produced which output gets messy fast. SubToAPI turns your existing Claude access into a standard HTTPS API with application-scoped keys (sub_live_...), so each service or environment can have its own key and usage trail while you iterate on system prompts without touching shared credentials. Check /docs/quickstart for the setup, or /docs/messages for the request format if you're migrating existing Claude API code.

A reusable template

You are [role] for [product/context].
Primary goal: [what success looks like].
Tone: [2-3 adjectives, not more].
Format: [exact output structure].
Constraints: [what to never do].
Unknowns: [what to do when information is missing].

Fill in each line explicitly rather than writing a paragraph. Explicit, line-by-line instructions are easier to test, debug, and hand off to teammates than prose.

Questions

Can I change the system prompt mid-conversation? Yes — the system field is sent with every request, so you can update it between calls. Claude doesn't "remember" an old system prompt once you send a new one; each request is evaluated with whatever system value you include that time.

Should custom instructions go in the system prompt or the first user message? Stable, reusable rules (persona, format, scope) belong in system. Context specific to one conversation — like a user's current order ID — belongs in messages. Mixing the two makes prompts harder to reuse across requests.

Do longer system prompts cost more? Yes — the system prompt's content counts toward input tokens like any other text, so longer instructions mean a slightly higher cost per request. See /pricing if you're also evaluating cost alongside design when routing traffic through SubToAPI.