Presets and System Prompts in LM Studio

A preset is a named bundle of a system prompt and the sampling settings around it. That is a small feature with an outsized effect, because the settings it carries are exactly the ones people forget they changed, and a preset chosen in the chat interface is still in force when a request arrives over HTTP.

What a preset carries

LM Studio’s documentation describes a preset as a way to bundle a system prompt and other parameters into a single configuration reusable across chats, and says that every parameter under the advanced configuration sidebar can be recorded in a named preset. In practice that is two groups of things.

• The system prompt. The instruction block prepended to the conversation. This is why most presets exist, and it is the setting whose effect is most obvious and whose presence is easiest to forget.
• Sampling parameters. Temperature, top-p, the repetition controls and the output token limit — the settings that decide how the sampler draws from the distribution the model produces. What each one does is covered in sampling parameters; the point here is that a preset pins all of them at once.

A preset is therefore a description of how you want a model to behave, deliberately independent of which model you use it with. The same “terse code reviewer” preset is meant to apply to whatever is loaded, which is what makes it worth having and also what makes the next section necessary.

What it deliberately does not carry

Load parameters are excluded from the preset format. Context length, GPU offload and flash attention are not in a preset; the documentation places them in the per-model defaults instead, reached from the model list rather than the preset manager.

That split is correct and worth understanding rather than working around. Load parameters are properties of a particular file on particular hardware — the right offload for a 13 GB model on a 12 GB card is not a preference, it is a constraint, and it is meaningless applied to a different model. Sampling parameters are the opposite: they are preferences, and they transfer. A format that mixed the two would make every preset machine-specific.

The consequence for you is that reproducing somebody’s setup takes two things, not one. A colleague’s preset gives you their prompt and their sampling; it does not give you their context length, and if their prompt depends on a long document fitting, you will get different behaviour from the identical preset. Configuring the load side is covered in the GPU offload slider.

Where it overrides you

Presets are a chat-interface feature that also affects the API, and that is where the surprises live.

• An omitted field is not a neutral field. A request to /v1/chat/completions that does not set temperature does not get a provider default — it gets whatever the loaded configuration has, which a preset may have put at 0.2 or at 1.4. Two machines running identical code can produce visibly different output for that reason alone, and nothing in the response says so.
• A system prompt can arrive twice. If a preset carries a system prompt and your request also sends a system message, the model may see both. The failure mode is contradiction: a preset saying “always answer in English” against a request asking for German produces one of the two, inconsistently.
• The preset is invisible from the client side. No field in the API response names the configuration that was applied. The only way to see it is from the server side, which is what lms log stream is for — it shows the fully rendered prompt, so a system prompt you did not send appears there plainly.
• Stop strings are the quiet one. A stop sequence that made sense for one model will truncate another model’s output mid-sentence, and that looks exactly like the model failing rather than like a setting.

The files on disk

Presets are JSON files in the LM Studio directory: ~/.lmstudio/config-presets on macOS and Linux, and %USERPROFILE%\.lmstudio\config-presets on Windows. That makes three things easy that the interface does not obviously offer.

• Version control. A preset is text. Committing the ones your team relies on to a repository is the honest way to make a prompt reproducible, and a diff answers “what changed” in a way clicking through panes cannot.
• Sharing. Copying the file is the whole operation, on any platform.
• Auditing. When output is unexpectedly strange, this directory is the faster answer: open the active preset and read what is actually in it.

Edit them while the app is running at your own risk — it holds state in memory and may write over your change on exit. Quit first, or make the edit in the interface and treat the file as the record rather than the input.

Using them without surprises

The pattern that avoids most of the above is to decide which layer owns the behaviour and then keep the other layer empty.

For interactive use, presets are the right place: a handful of named configurations, switched deliberately, with sampling settings recorded rather than remembered. For anything programmatic, do the reverse — keep a deliberately neutral preset active and send temperature, the system message and any stop sequences explicitly in every request. Explicit fields cost nothing and remove the entire class of “works on my machine” that a saved preset creates.

If you have inherited a machine and cannot account for its behaviour, the fastest diagnosis is to load a model with no preset applied, send one request with every parameter specified, and compare against what you were seeing. Anything that differs from that baseline is configuration rather than the model, and you now know which half of the problem you have. The server surface it all arrives through is covered in LM Studio’s local server.