Fix n8n Chat UI output_text Error on Message Two

TL;DR: n8n's Chat UI can fail on message two when a self-hosted Responses API rejects replayed assistant history, so test a Chat Completions-compatible route or a stateless session to isolate the mismatch.

The error 'type' must be 'output_text' is a conversation-history compatibility problem, not a bad prompt. The first reply succeeds because there is no prior assistant reply to replay. The second request includes one, and some self-hosted OpenAI-compatible servers reject n8n's string-shaped assistant content instead of accepting it as an output_text item.

Why does n8n Chat UI fail only on the second message?

n8n issue #25852 documents the exact pattern: a Workflow Agent connected to Chat UI answered once against llama.cpp, then the next message produced a red error overlay and Unknown error: Execution failed. The report used self-hosted n8n 2.7.5 in Docker, but the important detail is the turn count rather than the container setup.

On turn one, n8n can send the user's text and receive an answer. On turn two, it has to send the earlier assistant answer back as part of the conversation. A strict implementation of the Responses API expects an assistant message to contain typed output content. If it receives a plain string where it expects an array with an output_text item, it returns HTTP 400 before the model gets a chance to answer.

The request captured in n8n issue #26639 makes the mismatch visible. Its rejected request had an assistant content string. The reporter's accepted example represented that same assistant turn as a content array containing an item whose type was output_text. That is why changing the prompt, model temperature, or API key does not change the error.

How do you confirm this is the Responses API history mismatch?

1. Send one short message in the same Chat UI session and confirm that it completes.
2. Send a second short message without changing credentials, model, or workflow input.
3. Check the model-server log for an HTTP 400 containing output_text or inspect the failed n8n execution data.
4. Temporarily remove the memory or history component and retry with a fresh session.

If the error disappears when no assistant history is replayed, the diagnosis is strong. This is closely related to another multi-turn AI Agent 400 failure: both failures happen when a follow-up request loses or reshapes data the model endpoint expects to receive back.

What can you use instead of the failing Chat UI route?

There is no confirmed upstream n8n fix in the open Chat UI report, so treat the choices below as containment options rather than a promise that an update will solve it.

• Use a model endpoint and node configuration that stays on the Chat Completions API when your self-hosted server supports it. That avoids the strict Responses-history representation at the center of this report.
• Use a self-hosted backend or compatibility layer that accepts string assistant history for the n8n version you run. Test a two-message conversation, not only a single prompt.
• Disable the memory/history path for a narrow, stateless workflow when preserving context is not required. This is a diagnostic and a practical fallback, but it removes multi-turn context.
• Keep Chat UI on a provider that natively supports the required API shape, while using the self-hosted model for non-conversational steps.

Do not confuse this with streaming configuration. n8n's OpenAI Chat Model path has separate trigger, agent, and model streaming switches; toggling those can affect delivery of tokens but does not repair an invalid assistant-history object.

How do you collect a useful bug report for n8n?

Include the n8n version, model-server name and version, whether the node is configured for Chat Completions or Responses, and the smallest two-turn workflow that reproduces the failure. Redact keys, then attach the rejected request shape or server log. The open issue is assigned to n8n's Chat team, so a report that proves the first turn works and the second fails is more useful than a general "Chat UI is broken" note.

Also link the Automation Error Index when you are tracking related n8n failures. It helps separate this API-history error from 401s, streaming stalls, and model-specific tool-call failures.

FAQ

Is the "type must be output_text" error caused by llama.cpp?

llama.cpp is one reported backend, but the underlying problem is the shape of assistant history sent to a strict Responses-compatible endpoint. Another backend can show the same failure if it validates the same field differently from n8n.

Why does the first n8n Chat UI message work?

The first request has no earlier assistant reply to include. The incompatible record is created only after that reply is stored and replayed on the next turn.

Will upgrading n8n fix the error?

Check the issue and release notes before relying on an upgrade. The Chat UI issue was still open when this guide was written, so verify a two-turn conversation after every change.

Can I keep my self-hosted model without Chat UI memory?

Yes, if the workflow can be stateless. Removing history avoids replaying the malformed assistant record, but the model will not retain conversational context between messages.