What is a system prompt?
A system prompt is the block of instruction text supplied to a language model before any user input, telling it how to behave, what role to take, what to avoid, and how to format its answers. It sits above the conversation itself: the model reads it first, treats it as higher-priority guidance than the user's messages, and applies it to every turn that follows.
How it fits into a request
Most chat-style model APIs accept a conversation as a sequence of messages, and the system prompt is typically the first one, tagged separately from user and assistant turns. It might set a persona ("you are a customer support agent for X"), a constraint ("never provide medical advice"), a output format ("respond only in valid JSON"), or background context the model should treat as given. The user never has to repeat any of that; it's established once, and it applies for the whole session.
Who controls it depends on who's hosting
On a self-hosted deployment, the operator sets the system prompt directly, as a config value or file passed to the inference server, and it's exactly what they wrote, nothing more. On a hosted API product, there's often a second, invisible layer: the vendor's own system instructions, which get combined with whatever the developer supplies, ahead of it. Those hidden instructions typically aren't published in full, and can change without notice as the vendor updates its product. A developer building on a hosted API is layering their instructions on top of an unknown baseline they don't control.
Why that difference matters for self-hosted deployments
Running your own model means the system prompt you write is the entire system prompt; there's no vendor layer added underneath or around it. That's a real, practical difference for anyone who needs predictable behavior: what you write is what runs, and a later change to a hosted vendor's hidden instructions can't quietly alter a self-hosted deployment's behavior out from under you. It also means you can audit and version the exact instructions in use, which matters if behavior needs to be reproducible or explained after the fact.
What it doesn't do
A system prompt shapes behavior; it doesn't enforce it the way a hard-coded rule in application logic would. A well-written system prompt makes deviation less likely, but a model can still be pushed off its instructions by adversarial or unusual input, particularly with weaker or smaller models. Anything that must never happen, regardless of what a user types, generally needs a check outside the model itself, not just a stronger sentence in the prompt.
System prompts vs other kinds of instruction
A system prompt is distinct from a user message, which comes from whoever is chatting with the model in that turn, and from a developer-supplied function or tool definition, which describes what actions the model can take rather than how it should behave generally. Some APIs also distinguish a "developer" role from a "system" role, splitting instructions from the application builder and the end user's own custom instructions into separate priority tiers. The exact naming varies between providers and inference engines, but the underlying idea, instructions that apply to the whole conversation rather than a single turn, stays the same across all of them.
Where GPUwerk fits
Every model you run on a GPUwerk Spark is served through an inference engine you configure directly, which means the system prompt is whatever you set, with no hidden vendor layer added on top. See our glossary for related terms, or the private LLM hosting page for how deployments are set up.