Root cause

LLM Agentflow determines whether to call .stream() or .invoke() using:

const isStreamable = ... && modelConfig?.streaming !== false && ...

modelConfig comes from llmModelConfig, which is populated in the UI when the user selects a model. Flowise stores "" (empty string) for any boolean input field the user never explicitly toggled — the field's default value is only used for display, not to pre-populate the stored value.

So for any model with streaming: { type: 'boolean', default: false } that the user never touches, modelConfig.streaming === "", and "" !== false evaluates to true — streaming is enabled regardless of the model's declared default.

Why existing models aren't affected

Models that support streaming (e.g. ChatOpenAI) also get streaming: "" in llmModelConfig. But since they actually support streaming, the .stream() call succeeds — the bug is invisible.

The problem surfaces when a new chat model node declares streaming: { default: false } because it does not support streaming. The "" value causes LLM Agentflow to attempt streaming anyway, the model's endpoint rejects or silently fails the stream request, and no response is shown in the UI.

Why the fix must be in LLM.ts, not in the chat model node

The isStreamable decision is made entirely inside LLM Agentflow, based on llmModelConfig — a snapshot taken at UI config time. The chat model node's init() only returns a model object; it has no way to reach back and influence the streaming decision in LLM Agentflow.

Fix

When streamingConfig is "" or undefined (user never set it), fall back to the default declared in the node's own input definition.

• User never set streaming → uses node's declared default
• User explicitly set streaming to false → respects it
• User explicitly set streaming to true → respects it
• Node has no streaming input → defaults to true (backward compatible)