LM Studio 0.4.28: Debug Chat Template Problems with lms Logs and API Tests (2026)
Last updated: November 1, 2026. A local model that suddenly repeats prompt markers, ignores earlier turns, or produces broken tool calls may not be “bad at reasoning.” The problem can sit in the chat template—the formatting layer that converts your messages into the token sequence the model was trained to read.
LM Studio 0.4.28 was listed in the official changelog on October 31, 2026. Its release notes list two focused fixes: chat-template parsing for the Flint model, and a macOS update issue where “Restart to apply update” could reopen the current version instead of installing the new one. This is a narrow release note, not a claim that every template or every model is now fixed. This guide shows how to update carefully, reproduce a template problem, inspect the actual prompt, and run a small repeatable API regression check.
Intended audience: developers using local GGUF/MLX models in LM Studio, especially anyone diagnosing strange formatting, multi-turn chat, or tool-call behavior. This is a troubleshooting workflow—not a claim that we tested a Flint model on live hardware.
What changed in LM Studio 0.4.28?
The official LM Studio changelog lists version 0.4.28 dated October 31, 2026. Build 1 fixes chat-template parsing for the Flint model. Build 2 fixes a macOS “Restart to apply update” path that could reopen the current version instead of installing the update.
Why this matters: a chat template is responsible for turning roles and messages into the special tokens, separators, and control markers expected by a particular model. If the template is parsed incorrectly, a model may receive a different input than you intended. Symptoms can look like poor instruction following, but template compatibility is only one possible cause.
Do not infer from the changelog that all Flint variants, all quantizations, all custom templates, or every API path have been independently verified. Confirm the exact model artifact and test your own workload after updating.
Prerequisites
- LM Studio installed on macOS, Windows, or Linux. The update-restart fix is specifically a macOS item; the Flint parsing fix is the other listed 0.4.28 change.
- A model already downloaded in LM Studio. If you are investigating Flint, use the exact Flint model artifact that produced the issue.
- A terminal and permission to update LM Studio.
- Optional: Python 3 and the
requestspackage, or justcurlfor the API smoke test.
Keep a note of the current model name, quantization, runtime, context length, sampler settings, and a prompt that reliably reproduces the issue. Changing several settings at once makes the result hard to interpret.
Step 1 — Confirm the installed version and update deliberately
- Open LM Studio and check the version in the application’s About/version area.
- Compare it with the official changelog. Confirm that the installed version is 0.4.28 or later before attributing behavior to this fix.
- If updating through the app on macOS, verify the version again after the restart. The 0.4.28 notes specifically mention a bug where the restart action could reopen the existing version.
- Do not delete and re-download model files as a first troubleshooting step. The release note describes a parsing fix, not a requirement to replace weights.
Expected result: the app reports the intended version after restart. If the version did not change, use the official download/update route and check the version again before testing model behavior.
Step 2 — Establish a clean baseline before changing the template
In a new chat, send a short prompt with an easily checked answer, for example:
Reply with exactly this text and nothing else: TEMPLATE-CHECK-731Then run a multi-turn check:
User: My test label is ORBIT-17. Remember it for this chat.
Assistant: (response)
User: Return only the test label I gave you.Record whether the response is malformed, contains unexpected template markers, loses the label, or simply answers incorrectly. Repeat the same prompts after updating. Keep temperature and other generation settings unchanged for the comparison.
A single answer is not proof of a template defect. If the model responds normally in the UI but fails only through your application, the issue may instead be the request payload, API model identifier, or client-side message history.
Step 3 — Find the model key and load it with a stable identifier
LM Studio’s CLI is included with the app. Run LM Studio at least once before using the CLI. The official CLI guide documents commands for listing models, checking loaded models, loading a model, and managing the local server.
lms --help
lms ls
lms psUse the exact model key shown by lms ls when loading it. The key varies by downloaded artifact, so do not copy a model identifier from an unrelated tutorial.
lms load YOUR_MODEL_KEY --identifier flint-regression --context-length 4096
lms psThe identifier gives your local API tests a stable name even if the underlying model key is long. Adjust context length to a value your machine can support; 4096 is only an example, not a universal recommendation. If loading fails or memory pressure is high, try the app’s resource estimate and use a smaller context or a suitable quantization rather than assuming the template fix failed.
Step 4 — Start the API on loopback only
LM Studio can serve local models through OpenAI-compatible endpoints. The official local server guide documents the server, and the server-start CLI reference documents the bind and port options.
lms server start --port 1234 --bind 127.0.0.1Binding to 127.0.0.1 keeps the service on the local machine. Avoid 0.0.0.0 unless you intentionally need network access and have configured authentication and firewall rules.
List the models exposed by the server:
curl http://127.0.0.1:1234/v1/modelsCopy the model ID returned by this endpoint. Depending on how the model is loaded, it may be the assigned identifier or another server-visible ID. Use the returned value in the next request rather than guessing.
Step 5 — Run a repeatable chat-completions smoke test
Send the same simple test prompt through the API. Replace MODEL_ID_FROM_V1_MODELS with the ID returned in Step 4.
curl http://127.0.0.1:1234/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "MODEL_ID_FROM_V1_MODELS",
"messages": [
{"role": "system", "content": "Follow the user request exactly."},
{"role": "user", "content": "Reply with exactly this text and nothing else: TEMPLATE-CHECK-731"}
],
"temperature": 0,
"max_tokens": 40,
"stream": false
}'Expected result: a JSON response with an assistant message. Check the text inside choices[0].message.content. The answer should match the test label closely; if it does not, inspect the logs before editing any prompt template.
For production code, handle HTTP errors, timeouts, model-unavailable responses, and JSON parsing explicitly. A successful HTTP response only confirms that the request was handled; it does not prove the model followed the prompt correctly.
Step 6 — Inspect the formatted model input and server logs
Keep a second terminal open:
lms log stream --source model --filter input,outputThis command is documented by LM Studio for inspecting formatted input sent to the model and the model output. To inspect server-side requests instead, run:
lms log stream --source serverCompare what you intended to send with what LM Studio reports. Look for repeated role labels, unexpected separators, missing prior turns, or a prompt that differs between the UI and API. Do not assume that every visible special token is an error—some models legitimately use explicit control tokens.
Logs can contain private prompts, source code, personal information, or secrets. Use synthetic test content, avoid sharing raw logs publicly, and redact credentials before filing a bug report.
Step 7 — Run a small regression matrix
After updating, test a few cases that represent your actual use:
| Case | What to check | What a failure may indicate |
|---|---|---|
| Single-turn exact text | Expected marker appears without extra content | Template, sampling, or instruction-following issue |
| Two-turn memory | Second answer uses the earlier label | Client history may be missing, or the model may not follow the prompt |
| Longer user message | No truncation or malformed formatting | Context limit, payload construction, or template edge case |
| Tool call (if used) | Structured tool-call object is returned when supported | Model capability, template format, or parser compatibility |
| UI versus API | Same model and settings produce comparable behavior | Different prompt, settings, model ID, or message history |
Run each test a few times if the model is stochastic. Keep the prompt and settings fixed, and record the app version and model artifact. Do not report a general performance improvement from a handful of smoke tests; this workflow checks correctness and regressions, not benchmark speed or model quality.
Step 8 — Troubleshoot by isolating one layer at a time
- The app still shows the old version: verify the version after restarting; on macOS, the restart/update behavior is specifically mentioned in 0.4.28’s notes.
- The model is missing from
/v1/models: checklms lsandlms ps, load the intended model, and review server logs. - The API returns a model-not-found error: copy the exact ID from
/v1/models; do not assume the Hub name and API identifier are identical. - UI works but API fails: compare the message array, system prompt, temperature, context, and loaded model. Inspect server logs for request errors.
- Both UI and API produce malformed output: confirm the exact model file and runtime, update first, reproduce with a short prompt, and capture the relevant logs. Only then investigate model-specific template settings.
- Tool calls are malformed: verify that the model has a tool-use-capable template and that LM Studio supports its tool-call format. Template parsing fixes do not automatically grant tool-use training to a model.
- Output is slow or the app runs out of memory: reduce context length or use a smaller quantization. Treat this separately from formatting correctness.
If the issue persists on 0.4.28, prepare a minimal reproduction with the app version, operating system, exact model artifact/revision, runtime, request payload, expected result, actual result, and redacted logs. Check the official changelog again for later fixes before concluding that the issue remains unresolved.
Security and privacy checklist
- Keep the local server bound to loopback unless remote access is intentional.
- Do not expose the API directly to the internet. For shared access, use a controlled network path, authentication, firewall restrictions, and a documented threat model.
- Never place API tokens or private prompts in public bug reports or committed test fixtures.
- Use synthetic prompts for diagnostics and redact logs that include proprietary code or customer data.
- Treat model output and tool calls as untrusted. If your app executes commands or invokes tools, validate arguments and require explicit approval for destructive actions.
Trade-offs and limitations
Updating is a sensible first step when the official release notes match your symptom, but it is not a universal repair. Different model variants can use different templates; community-converted weights may carry different metadata; and an application can introduce its own prompt-formatting bugs. A successful smoke test proves only that the tested path worked for that case. It does not establish model accuracy, tool-call reliability, security, or performance across workloads.
This workflow is most useful for local-model developers who need a reproducible way to separate model behavior from the UI, template, and API layers. If you only chat manually and do not observe a problem, there is no need to edit templates or run every diagnostic step.
FAQ
Does LM Studio 0.4.28 fix every chat-template issue?
No. The official changelog specifically lists a Flint model chat-template parsing fix. It does not claim to fix all models or custom templates.
Should I manually replace the model’s template after updating?
Not as the first step. Update, reproduce the issue, and inspect the formatted input. Manual changes can make the setup harder to reproduce and may break a template that already works.
Why does the same model behave differently in the UI and API?
The requests may differ in system prompts, message history, sampling settings, context length, or model identifier. Compare those inputs and inspect the model logs before blaming the template.
Is this a benchmark of LM Studio 0.4.28?
No. It is a diagnostic and regression-testing guide. No live Flint test or benchmark was run while preparing this article.
Where should I go next?
For related workflows, read GyanAangan’s guides to benchmarking local GGUF models correctly, serving GGUF models with llama.cpp, and routing local models through one LiteLLM API.