OpenAI-compatible provider emits system messages after the conversation, causing strict chat templates to reject requests

[rirze]

Summary

The OpenAI-compatible provider can emit multiple system messages, including system messages placed after user, assistant, or tool messages.

Some OpenAI-compatible servers and model chat templates require the system message to be the first message and permit at most one system message. For example, a local vLLM server running Qwen3.8 rejects Autolith requests with:

The provider returned HTTP 400.
System message must be at the beginning.

This prevents otherwise working custom OpenAI-compatible providers from being used with Autolith.

Environment

• Autolith: current master / 0.33.8
• Platform: Linux x86_64
• Provider type: custom OpenAI-compatible provider
• Server: local vLLM OpenAI-compatible API
• Model: qwen3.8-27b
• Endpoint: http://localhost:18020/v1/chat/completions

The problem occurs with both the Nix invocation and a normally installed Autolith binary.

Provider configuration

(in-package #:autolith)

(register-openai-compatible-provider
 :name "local-vllm"
 :description "Local Qwen3.8-27B served by vLLM"
 :endpoint "http://localhost:18020/v1/chat/completions"
 :models-endpoint "http://localhost:18020/v1/models"
 :models
 '((:name "qwen3.8-27b"
    :description "Qwen3.8-27B"
    :context-window 262144
    :reasoning-efforts ("xhigh" "medium" "low")))
 :reasoning-parameter "reasoning_effort")

Steps to reproduce

1. Start a local vLLM server using a model whose chat template requires the system message to be first, such as Qwen3.8.

2. Register the server as a custom OpenAI-compatible provider.

3. Authenticate the provider.

4. Start Autolith:

   AUTOLITH_MODEL=qwen3.8-27b autolith

5. Send any ordinary user message.

Actual behavior

The request is rejected by vLLM:

✗ error
  The provider returned HTTP 400.
  System message must be at the beginning.

The user message itself does not appear to be duplicated. The issue is the ordering and number of system messages.

provider-request-object in src/provider/openai-compatible.lisp currently constructs the message list in approximately this order:

system: main Autolith system prompt
system: optional goal context
user/assistant/tool: projected conversation
system: optional context-delivery content
system: optional compaction instructions

Therefore, ordinary requests can contain a system message after the conversation, and requests with goal context can contain more than one system message before the conversation.

Compaction requests can similarly place the compaction instruction system message after the projected conversation.

Strict chat templates reject these request shapes.

Expected behavior

The OpenAI-compatible provider should support servers that require exactly one leading system message.

All Autolith-controlled system content could be combined in its original logical order:

[
  {
    "role": "system",
    "content": "<main system prompt>\n\n<goal context>\n\n<context delivery or compaction instructions>"
  },
  {
    "role": "user",
    "content": "..."
  }
]

There should be no additional system messages after index 0.

If changing the behavior globally would affect providers that support interleaved system messages, a provider registration option such as the following could control normalization:

:system-message-policy :single-leading

For a generic OpenAI-compatible provider, making :single-leading the default would likely provide the broadest compatibility.

Confirmed workaround

I added an :around method for provider-request-object in init.lisp that:

1. Calls the existing method to construct the complete request.
2. Extracts every message whose role is system.
3. Joins their textual contents in their original order.
4. Inserts one combined system message at index 0.
5. Preserves the relative order of all non-system messages.

After applying that normalization, the same Autolith configuration and vLLM server work correctly.

This confirms that the failure is caused by system-message construction rather than a duplicated user message, authentication, streaming, or the model identifier.

Suggested implementation

Add a request-normalization function for Chat Completions messages, conceptually:

(openai-compatible--normalize-system-messages messages)

It should:

• preserve the order of non-system messages;
• gather all system-message content in encounter order;
• emit at most one system message;
• place that message at index 0;
• handle string content and typed text-content arrays;
• avoid producing an empty system message if there is no system content.

Normalization should happen after all request-local context, goal context, conversation items, and compaction instructions have been assembled, but before the message list is converted to the final JSON vector.

Suggested regression tests

A normal request with context delivery should assert that:

(string= (json-get (aref messages 0) "role") "system")

and:

(zerop
 (count "system"
        messages
        :start 1
        :test #'string=
        :key (lambda (message)
               (json-get message "role"))))

Tests should also verify that:

• the main system prompt remains present;
• goal context remains present;
• context-delivery content remains present;
• compaction instructions remain present during compaction;
• user, assistant, function-call, and tool-result messages retain their relative order;
• a user message is included exactly once.

[chakany]

Known bug. It's being worked on.

[rirze]

Do you want a PR? Also is there another bug reporting lane other than Github Issues? I'm not seeing much activity here.

[chakany]

Do you want a PR? Also is there another bug reporting lane other than Github Issues? I'm not seeing much activity here.

I have a local branch RN that I am using to diagnose harness issues. For now I could push a fix for this though.

On your second question, we have a zulip chatroom that can be used to report bugs: https://zulip.lambda-symbolics.com

[luciusmagn]

I think we should push a small fix for this so we don't accumulate too much stuff on your branch, hahaha @chakany