SystemMessage added after UserMessage causes API errors for models requiring system message first (affected since v3.8.42)

[wangvm]

I encountered an issue when using LLMTornado with certain LLM models that require the SystemMessage to be placed as the first message in the conversation. The current implementation of SetupConversation adds the system message after appending user input, which violates this requirement and causes API errors.

Specifically, when using the model Jackrong/Qwen3.5-9B-Claude-4.6-Opus-Reasoning-Distilled-v2-GGUF (a fine-tuned Qwen3.5 model), the API returns an error because the system message appears after the user message in the messages array.

Root Cause

In the SetupConversation method, the execution order is:

1. Load existing conversation history (AddMessagesToConversation)
2. Append user input (AppendUserInput)
3. Add system message (AddSystemMessage)

This results in a messages array where system messages may not be at index 0. For models that strictly enforce the system → user → assistant ordering convention, this causes the API request to be rejected.

Affected Code

private static Conversation SetupConversation(TornadoAgent agent, List<ChatMessagePart>? input = null, List<ChatMessage>? messages = null, string? responseId = null, CancellationToken cancellationToken = default)
{
    Conversation chat = agent.Client.Chat.CreateConversation(agent.Options);

    chat.RequestParameters.CancellationToken = cancellationToken;

    chat = AddMessagesToConversation(chat, messages);

    if (input?.Count > 0)
    {
        chat.AppendUserInput(input);
    }

    if (!string.IsNullOrEmpty(responseId))
    {
        chat.RequestParameters.ResponseRequestParameters!.PreviousResponseId = responseId;
    }

    // System message added at the end
    chat.AddSystemMessage(agent.Instructions);

    return chat;
}

Expected Behavior

The system message should be the first message in the conversation. For new conversations, the order should be: SystemMessage → UserMessage. For existing conversations, the system message should remain at the beginning of the message array.

Current Behavior

System message is appended after the user input, resulting in an invalid message order for models that enforce the system-first convention.

Steps to Reproduce

1. Use LLMTornado version v3.8.42 or later.
2. Configure a TornadoAgent with a model that requires system message first (e.g., Qwen-based models).
3. Call the agent with any user input.
4. Observe API error indicating invalid message order.

Environment

• LLMTornado Version: v3.8.42 and later (issue introduced after this version)
• .NET Version: .NET 10
• Affected Model: Jackrong/Qwen3.5-9B-Claude-4.6-Opus-Reasoning-Distilled-v2-GGUF

Workaround (for users)

For users currently blocked by this issue, a temporary workaround is to ensure that the conversation messages array already contains the system message before calling SetupConversation, by passing it through the messages parameter, and setting agent.Instructions to null or empty to avoid duplicate system messages.

[lofcz]

thanks for the report, would you like to contribute a PR to fix this?

[Johnny2x2]

@wangvm

just submitted a new bool to AgentRunnerOptions

/// <summary>
  /// Set the system message at the start of the conversation instead of the end. 
  /// </summary>
  public bool SystemMessageAtStart { get; set; } = false;

can be used like:

        string playerMessage = "";
        Console.WriteLine("Welcome To Dungeon Masters");
        List<ChatMessage> AllContent = new List<ChatMessage>([new ChatMessage(ChatMessageRoles.User, "Start a new Dungeons and Dragons campaign with me.")]);

        string dungeonMasterInstructions = @"
You are a Dungeons and Dragons Dungeon Master. You will guide the solo player through an epic adventure. You will role the dice for all interactions. Start by giving the player a character and explaining the scene and backstory. Task the Player with an action requirement at the end of each prompt.";



        TornadoApi api = new TornadoApi(new Uri("http://localhost:11434")); // default Ollama port, API key can be passed in the second argument if needed
        ChatModel model = new ChatModel("qwen3:14b");  // <-- replace with your model

        TornadoAgent agentDungeonMaster = new TornadoAgent(api, model, tools: [RollDice], instructions: dungeonMasterInstructions, streaming: true);


        Console.WriteLine("\n\n[DUNGEON MASTER]:");
        Conversation dungeonMasterConv = await agentDungeonMaster.Run(appendMessages: [new ChatMessage(ChatMessageRoles.User, "Start")], runnerOptions: new TornadoRunnerOptions() { SystemMessageAtStart = false},streaming: agentDungeonMaster.Streaming, onAgentRunnerEvent: (evt) => {
            if (evt.EventType == AgentRunnerEventTypes.Streaming && evt is AgentRunnerStreamingEvent streamingEvent)
            {
                if (streamingEvent.ModelStreamingEvent is ModelStreamingOutputTextDeltaEvent deltaTextEvent)
                {
                    Console.Write(deltaTextEvent.DeltaText); // Write the text delta directly
                }
            }
            return ValueTask.CompletedTask;
        });

[Johnny2x2]

@wangvm just Pushed release for install.

[wangvm]

@Johnny2x2 Thank you very much, it worked!
From my tests so far, this issue only occurs with the Qwen series of models. Regardless of whether deployed on llama.cpp or vllm.
It fix by v3.8.56