Grok's Default System Prompt and Persona

xAI is the only major lab that publishes its assistant system prompts in a public repository. Almost none of what it publishes is what you get from the API, and confusing the two produces a persona nobody asked for.

xAI publishes its prompts, mostly

The xai-org/grok-prompts repository on GitHub holds the system prompts for xAI’s own products. The files are Jinja templates and plain text, versioned in the open, and they cover the chat assistant on grok.com and X, the @grok bot that replies to posts, and the Grok Explain button on X.

They are worth reading — they are the most detailed public example of how a frontier lab writes a product persona, and they contain the instructions people quote when they describe Grok as having an attitude. They are also, for an API user, the wrong document. The repository sorts its files by surface, and the assistant prompts are labelled for grok.com and X.

The API is not grok.com

The behavioural difference people notice first is tone: the same question asked on grok.com and asked through /v1/chat/completions comes back in different registers. That is not a different model. It is a product prompt that the API request does not carry.

The API’s message array is the prompt. In the OpenAI-compatible shape that is messages, in the Responses shape it is input, and in both a system-role entry sets behaviour for the conversation. xAI’s own quickstart uses exactly this — a system message reading “You are Grok, an AI agent built to answer helpful questions.” — which is instructive precisely because xAI has to write it out. If a persona came for free, the example would not need one.

{
  "model": "grok-4.5",
  "input": [
    { "role": "system",
      "content": "You are a release-notes editor. Answer in British English, in at most three sentences, and never speculate about unreleased features." },
    { "role": "user", "content": "What changed in 2.4.1?" }
  ]
}

One further wrinkle specific to xAI: the Responses endpoint supports optional stateful conversations, where prior input, reasoning content and responses are stored on xAI’s servers and referenced by response id, retrievable for 30 days. You can turn that off with store: false. It changes what you have to resend, not what the model is — the system message still governs the turn either way.

The injected prefix

The claim “the API adds nothing” is too strong, and the repository is what disproves it. Alongside the product prompts, xAI publishes three files it labels as injected system prompt prefixes for API models — safety prefixes attached to specific model slugs rather than to a chat product.

Two consequences follow, and they are the practical content of this page. First, there is a small amount of model-side instruction you do not control and cannot see in your own request. Second — and this is the part that catches people — those files are named for particular slugs, so the prefix is a property of the model version, not of the API. Change model and you may change the prefix. That is one more reason a pinned dated snapshot behaves more consistently than an alias.

What your system message overrides

Be precise about the layering, because “override” is doing two different jobs in most explanations of this.

• Persona: yours wins, because there is nothing to beat. The grok.com voice is not present in an API call, so a system message defines the register from scratch rather than arguing with a default.
• Safety: yours does not win. A model-side prefix and the training behind it are not addressable from the message array, and attempting to talk past them is a named prohibited use in xAI’s acceptable use policy, not merely a technique that fails.
• Format: yours wins, and weakly. A system message is an instruction, and instructions are followed probabilistically. If the output must parse, constrain it with a schema rather than asking.
• Reasoning: yours does not reach it. On a reasoning model you are instructing the answer, not the trace. See how the think output differs from the answer.

Writing one that holds

Because there is no default persona to fight, a Grok system message does more work per word than the equivalent on a product-tuned surface, and the failure mode is under-specification rather than conflict.

Put the durable things in it — role, audience, language variant, format contract, refusal policy, what to do when the answer is not in the context — and keep per-request facts in the user turn. That split is not stylistic. A stable system prefix is exactly what a prompt cache can reuse, and xAI bills cached input at roughly a sixth of the uncached rate on grok-4.3. Rewriting the system message on every request throws that away, and does so silently: nothing fails, the invoice is just larger.

The mechanism behind that is worth being concrete about, because it decides how you order a prompt. A cache works on a prefix: it can reuse the computation for the longest run of leading tokens that is byte-identical to something it has already processed. One changed character early in the system message invalidates everything after it, so a timestamp, a request id or a shuffled list of tool definitions at the top of the prompt is worth exactly as much as having no cache at all. Stable content first, variable content last, and nothing dynamic in the system message. xAI also documents a prompt_cache_key parameter for sticky routing and cache optimisation — sending a consistent key for a given conversation or tenant helps requests that share a prefix land where that prefix is already warm. Whether it is helping is visible in usage.prompt_tokens_details.cached_tokens, which is the number to watch rather than the parameter.

One more reason to read xAI’s published prompts even though they do not apply to you: they are a worked example of length. The chat assistant prompts are long, specific, and full of instructions about what to do in named edge cases rather than adjectives about tone. If your system message is three sentences of “be helpful and concise”, the gap between that and what a lab ships is the gap you are asking the model to guess at.

One thing xAI does not document is a precedence rule for multiple system messages, or an equivalent of a distinct developer role. Send one system message and keep it first. That behaviour is well-defined everywhere; anything else is an assumption you would be making on the reader’s behalf.