System Prompts in the API (Every Provider Compared)

TL;DR: Call it the system parameter: the API field that carries a model's persistent instructions. OpenAI's Responses API names it instructions; Anthropic's Messages API names it system; Google splits it into systemInstruction on generateContent and system_instruction on the newer Interactions API. None of the four shapes are interchangeable, and a fifth, the Assistants API's own version, shut down August 26, 2026.

Everything below was checked against each vendor's own documentation on September 3, 2026, with the URL and exact wording given. A same-cohort post on this site covers the ChatGPT- and Claude.ai-specific side of system prompts (consumer surfaces, not raw API calls); this page is the cross-provider API comparison.

What is the system parameter in an API call?

Every chat-shaped LLM API lets you send two broad kinds of text: the turn-by-turn conversation, and a separate channel meant to hold standing instructions that apply across the whole exchange. That second channel is the system parameter. It's where you put a role description, a tone constraint, an output format rule, or anything else you want the model to treat as background context rather than something the user just said.

The idea is old. The name, shape and location of the field are not stable across vendors, and two of the three moved the goalposts within the last eighteen months. OpenAI now runs three different shapes across its history (system role, developer role, and a top-level instructions string), one of which, the Assistants API's version, no longer exists at all. Google runs two shapes at once, in two APIs it actively maintains side by side. Anthropic is the most stable of the three, and even it changed the field's official guidance mid-2026 when Claude's older models deprecated the classic sampling parameters and pushed prompting, including the system prompt, forward as the primary control surface instead.

Vendors are not even consistent about what to call the general concept. "System message", "system prompt" and "system instruction" show up interchangeably across the three vendors' own documentation, sometimes on the same page, and none of them map cleanly to a single field name once you account for every API a given vendor runs. Treat this page as a translation table between that loose terminology and the literal field you have to type.

Does a browser chat window use the same system parameter?

No, and that distinction matters before anything else here. ChatGPT's custom instructions, Claude.ai's Projects, and Gemini's Gems all build a system-prompt-equivalent behind the scenes, but none of them expose the raw API field this page documents; the consumer surface writes its own wrapper prompt, often combining your text with product-level instructions you never see, and hands the result to the same API parameters covered below. A same-cohort post on this site covers that consumer-surface side directly, for Claude specifically. This page is scoped to the raw API call: the field you send yourself, in your own request, with nothing else in between.

How does OpenAI represent the system prompt?

Three answers, because OpenAI runs three parameter shapes depending which era of its API you're calling.

Responses API (current). A top-level instructions string. OpenAI's own reference describes the field plainly: "A system (or developer) message inserted into the model's context." It is deliberately scoped to the current call rather than to a conversation: "When using along with previous_response_id, the instructions from a previous response will not be carried over to the next response. This makes it simple to swap out system (or developer) messages in new responses."

Chat Completions (still live, older shape). No separate top-level field; instead, a message inside the messages array carries the role system or developer. The two are near-duplicates with a migration note attached. The developer role's own description reads: "Developer-provided instructions that the model should follow, regardless of messages sent by the user." And the two roles cross-reference each other directly: "With o1 models and newer, developer messages replace the previous system messages." If you're targeting a reasoning model, send developer, not system.

Assistants API (shut down). This one is now history rather than an option. The Assistant object carried its own instructions field, described in the schema as "The system instructions that the assistant uses. The maximum length is 256,000 characters." OpenAI's deprecations page states the shutdown plainly: "On August 26th, 2025, we notified developers using the Assistants API of its deprecation and removal from the API one year later, on August 26, 2026." The listed replacement is the Responses API and the Conversations API, both of which use the instructions shape above, not the Assistant object's field.

How does Anthropic represent the system prompt?

One shape, and Anthropic is unambiguous that it is the only one. The Messages API takes a top-level system parameter, either a plain string or an array of text blocks. The reference describes it directly: "System prompt. A system prompt is a way of providing context and instructions to Claude, such as specifying a particular goal or role."

There is no equivalent to OpenAI's message-array approach. Anthropic's guide to including a system prompt is direct about the reason: you use the top-level system parameter because there is no "system" role for input messages in the Messages API at all. A messages array on Anthropic's API only ever carries user and assistant turns.

The array form of system buys you one thing string form doesn't: per-block cache_control, so a long standing system prompt (house style, a product's full feature list, a large ruleset) can be cached instead of re-billed as fresh input on every call.

One structural note worth stating plainly, because it affects every field on the request, not only system: "The Messages API can be used for either single queries or stateless multi-turn conversations." There is no server-side memory here at all. Whatever you put in system, you resend it, byte for byte, on every request.

How does Google represent the system prompt?

Two shapes, on two APIs Google runs at the same time, and the casing itself is the tell that they're not the same interface wearing a different label.

generateContent (the established API). A top-level systemInstruction field, camelCase, typed as a Content object rather than a plain string. Google's own reference describes it in six words: "Developer set system instruction(s). Currently, text only." In practice that Content object is the same shape Google uses for a conversation turn: a parts array of text (or other modality) blocks, so a minimal system instruction is {parts: [{text: "..."}]} rather than a bare string, which is easy to get wrong if you're used to Anthropic's or OpenAI's plain-string versions.

Interactions API (the newer one). A top-level system_instruction field, snake_case, and typed far more simply. Google's reference gives it a one-line description: "System instruction for the interaction." A plain string, with no Content wrapper. It is also explicitly scoped to a single turn rather than a conversation, even when you're using the Interactions API's own server-side history feature. The overview guide states: "The previous_interaction_id parameter preserves only the conversation history (inputs and outputs) using previous_interaction_id. The other parameters are interaction-scoped and apply only to the specific interaction you are currently generating". system_instruction is named on that list, alongside tools and generation_config.

Every provider's system-prompt field, side by side

Six rows, five still-live shapes, four different field names for what is conceptually the same idea. If you're porting a system prompt from one of these to another, the string content usually survives unchanged; the wrapper around it never does.

Notice, too, that only one row in that table is a message with a role, rather than a dedicated top-level field: OpenAI's Chat Completions. Every other live shape, on every other API, treats the system prompt as its own request parameter, separate from the conversational array entirely. That's the direction all three vendors have converged on for their newer APIs, even though they didn't converge on what to name the result or how to type it.

Does the system prompt persist across multiple turns?

Not automatically anywhere, and the mechanism differs by whether the API has server-side conversation state at all.

OpenAI Responses supports optional server-side state through previous_response_id, but instructions is explicitly carved out of what that carries forward, per the quote above. Every new response's instructions come from the new request, not the chain.

OpenAI Chat Completions has no server-side state of any kind. You resend the full messages array, system or developer entry included, on every call. There is nothing to opt out of, because there is nothing kept.

Anthropic Messages is the same story from a different angle: "stateless multi-turn conversations" per the quote above, meaning you manage the entire history, system included, on your own side and resend it every time.

Google Interactions supports optional server-side state through previous_interaction_id, and here too system_instruction is explicitly named as interaction-scoped rather than conversation-scoped, alongside tools and generation_config. Resend it on any turn where you want it to keep applying.

Google generateContent has no session concept at all. Every call carries its own full contents array and its own systemInstruction.

The pattern across all five: a system-prompt-equivalent field is either resent on every call by design (no state exists), or explicitly excluded from what a stateful session carries forward. No provider auto-persists it, which is a deliberate design choice on OpenAI's and Google's part, not an oversight: it makes swapping the standing instructions between turns of the same conversation a one-field change rather than a full-history rewrite.

Does the system prompt override the user's message?

Briefly, because a full answer is a separate page. OpenAI documents an explicit hierarchy: the developer role's own description states its instructions apply "regardless of messages sent by the user", and OpenAI's broader Model Spec ranks a small number of authority tiers against each other in detail. Anthropic and Google don't publish an equivalent ranking for their own system fields; the silence is itself informative; treat the ordering as strong influence rather than a documented rule where a vendor hasn't stated one.

The full breakdown of who wins on each provider, including the o1-and-later developer-replaces-system change and what happens with tool output and retrieved documents, is post 115's subject. If you're deciding what to actually put in the field versus in the user turn, post 08 covers the ChatGPT-specific version of that question, and if you're structuring a longer Claude system prompt specifically, post 163 on XML tags is the relevant follow-on.

Copy-paste: the same system prompt, four ways

Same instruction, sent the way each live API actually wants it as of September 3, 2026.

# OpenAI — Responses API. Top-level `instructions`, does not carry over previous_response_id.
curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "instructions": "You are a terse support agent. Answer in two sentences or fewer.",
    "input": "My export button is greyed out."
  }'

# OpenAI — Chat Completions. `developer` role for reasoning models; `system` for everything older.
curl https://api.openai.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-5.6",
    "messages": [
      { "role": "developer", "content": "You are a terse support agent. Answer in two sentences or fewer." },
      { "role": "user", "content": "My export button is greyed out." }
    ]
  }'

# Anthropic — Messages API. Top-level `system`, no system role inside `messages`.
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-opus-5",
    "max_tokens": 1024,
    "system": "You are a terse support agent. Answer in two sentences or fewer.",
    "messages": [{ "role": "user", "content": "My export button is greyed out." }]
  }'

# Google — Interactions API. snake_case `system_instruction`, a plain string, interaction-scoped.
curl "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-3.8-flash",
    "system_instruction": "You are a terse support agent. Answer in two sentences or fewer.",
    "input": "My export button is greyed out."
  }'

Swap the model IDs for whatever is current when you read this. The one thing every request above has in common: none of these four field shapes will parse on any of the other three APIs. Copy the string, never the wrapper.

Sources and access dates

Every claim above traces to a primary document, checked September 3, 2026:

• OpenAI: the Responses API reference, the published OpenAPI specification (info.version 2.3.0), and the deprecations page for the Assistants API shutdown.
• Anthropic: the Messages API reference.
• Google: the generateContent API reference and the Interactions API reference, plus the Interactions API overview for the interaction-scoped-parameters note.

Field shapes on all three vendors have moved within the last eighteen months, and the Assistants API disappeared entirely during that window. Check the live reference before shipping anything from this page unchanged. For the rest of each provider's parameters, temperature, effort, caching and structured output included, post 114 has the full cheat sheet.