Bionic 1.0.4 (Build 9) fails to start conversations with LM Studio (HTTP 400 / failed to parse grammar)

[T4SISU]

Which version of LM Studio?

LM Studio 0.4.20 (Build 1)

---

Which operating system?

Windows 11

---

What is the bug?

After updating Bionic from 1.0.3 to 1.0.4 (Build 9), I can no longer start conversations through LM Studio.

The same model works correctly when used directly in LM Studio, so the issue only occurs when using Bionic.

The request reaches LM Studio successfully, but LM Studio returns HTTP 400 and reports a grammar parsing error.

Environment:

• Bionic: 1.0.4 (Build 9)
• LM Studio: 0.4.20 (Build 1)
• Model: Qwen3 8B GGUF
• GPU: NVIDIA RTX 5070

The issue is 100% reproducible in my environment.

---

Steps to reproduce

1. Start LM Studio.
2. Load the Qwen3 8B GGUF model.
3. Start Bionic 1.0.4 (Build 9).
4. Connect Bionic to LM Studio.
5. Create a new conversation.
6. Send any message.

---

Expected behavior

The conversation should start normally.

---

Actual behavior

Bionic reports:

Engine protocol ngPredictTokens request returned 400

Failed to initialize samplers:
failed to parse grammar

LM Studio reports:

Failed to initialize samplers:
failed to parse grammar

srv process error

failed to launch slot with task

---

Observations

From my investigation:

• The issue started only after updating from Bionic 1.0.3 to 1.0.4 (Build 9).

• The issue only occurs through Bionic.

• LM Studio works correctly by itself.

• HTTP 400 indicates that LM Studio receives the request successfully.

• Immediately before the error, LM Studio logs contain many tool-* schema entries such as:

• tool-search-file

• tool-run-python

• tool-render-svg

• tool-read-skill

Immediately after those entries, LM Studio reports:

failed to parse grammar

---

Possible cause (hypothesis)

This is only a hypothesis based on the logs.

It appears that the failure occurs while LM Studio is processing Tool Calling / grammar-related data.

I cannot determine whether the root cause is in Bionic, LM Studio, or an incompatibility between them.

I hope these investigation results are useful.

---

Screenshots

I have attached screenshots showing:

• the complete error message
• the LM Studio log
• the tool-* entries immediately before the grammar parsing failure

Unfortunately, I no longer have the original log files because I only preserved screenshots during my investigation.

---

Closing note

Thank you very much for all the work you've put into LM Studio and Bionic.

English is not my native language, and I have very little experience using GitHub.

This report was organized with the help of ChatGPT, but the investigation, testing, comparisons, and log collection were performed by me.

I really enjoy using your software as part of my personal AI project, Project NAGI.

Because I appreciate your work, I wanted to investigate this issue as carefully as I could instead of simply reporting that "it doesn't work."

I understand that bugs can be difficult to track down, but I sincerely hope this report helps identify the problem.

Thank you again for creating such an excellent piece of software.

[grtninja]

The observation that direct LM Studio works while Bionic 1.0.4 fails, together with the tool-* schema entries immediately before failed to parse grammar, is consistent with a Bionic/native-path request-shape difference. It does not by itself prove whether Bionic, LM Studio, or the bundled parser is the owner.

A safe experiment is to capture one redacted Bionic request and compare it with a same-model POST http://127.0.0.1:1234/v1/chat/completions request. Keep the model and credentials unchanged; compare only messages, tool schemas, reasoning, response format, and stream mode. Validate the schema/grammar before opening an SSE response. If the native grammar cannot compile, return a typed 400 and avoid an unchanged retry. For plain text requests with no strict schema, a single same-host OpenAI-compatible request may provide a compatibility path; for tool requests, preserve the allowlist and use the standard tool-call/result continuation without duplicate execution. This is a diagnostic/mitigation proposal, not a claim that the bug is fixed upstream.

[grtninja]

I built a transport-free compatibility candidate and ran 57 focused tests covering the exact grammar-400 signature, same-model route mapping, schema/argument validation, pre-SSE failure behavior, auth redaction, tool allowlisting, and call-id idempotency. This is a candidate contract, not a claim that Bionic is fixed:

1. Preflight the generated grammar before opening SSE; emit a typed selected_model_grammar_invalid JSON error on compile failure and never retry the unchanged body.
2. For plain text/no-strict-schema/no-MCP requests only, perform one same-host fallback to http://127.0.0.1:1234/v1/chat/completions with the identical selected model and equivalent messages, non-streaming first.
3. Preserve function schemas and allowed tool names; run the caller-owned tool loop once per call ID with argument validation and replay deduplication.
4. Do not translate native MCP, stateful, strict structured-output, or opaque grammar requests; return a typed not-eligible error instead.

A redacted Bionic request plus generated grammar/schema would let this become an exact parser fix rather than a heuristic. The fact that the same model works on the compatible endpoint is strong differential evidence that the short leg is the Bionic/native translator, not model weights.

[grtninja]

Separate response-finalization note (not claimed as the grammar root cause): I built a three-case local clean-room around the Bionic 1.0.4 Build 9 control flow using dummy auth/error data only. The buggy sequence next(error); next() commits a 401, continues into the fallback router, and attempts a second 200 send, reproducing ERR_HTTP_HEADERS_SENT. Returning immediately after next(error) prevents fallback traversal; a defense-in-depth headersSent || writableEnded guard also suppresses a duplicate send. This is a candidate source-level repair, not a claim of live acceptance or an upstream fix. Please verify against the corresponding source/version and add a regression test; the grammar ngPredictTokens 400 remains a separate parser/frontdoor defect.