Muse Glimmer Response Parser
Muse Glimmer talks in channels — this node separates the thinking from the answer
- response
- thinking
- raw
- valid
Muse Glimmer is a model whose responses aren't one flat block of text - they're addressed to different recipients in separate channels, with a reasoning/thinking channel alongside the user-facing answer. If you've run one through a llama.cpp node and stared at a wall of interleaved text, you know the problem this node solves: Muse Glimmer Response Parser takes that raw response string and splits it into the final response, the thinking text, and everything else.
The mechanism is a parser, not a model. It understands Muse Glimmer's message structure and separates it by recipient: the final response to the user comes out on response, the reasoning channel on thinking, and anything addressed to other recipients - or unclassified text - lands on raw. The valid output is the honest one: it's true only when a complete Muse Glimmer final-response marker was parsed, and false for truncated reasoning or text that isn't Muse Glimmer at all. That flag is your guard against feeding a garbled or cut-off response into a downstream node and assuming it worked.
The one input is muse_response, a plain string - connect it to the response (or raw) output of whatever llama.cpp node produced the Muse Glimmer output. The node is explicitly non-streaming and won't interpret tool calls: the tooltip and description are clear that streaming and tool-call interpretation are not supported. So the wiring pattern is: generate a non-streaming Muse Glimmer completion, feed the whole raw string here, and read the clean split.
Why this exists: if you're wiring a reasoning-capable model into a prompt pipeline, thinking text is a liability, not a feature. The KB's LLM-in-ComfyUI doc makes the same point about reasoning models leaking scratch-work into prompts - a parser that cleanly separates the channel is the mechanical fix, so your response output never carries the model's deliberation into your conditioning. valid gives you a gate: only proceed when the answer was actually complete.
Install is the pack standard:
cd ComfyUI/custom_nodes
git clone https://github.com/craftingmod/ComfyUI-Ollama-ImageList
Restart ComfyUI, and if you're running this through the llama.cpp path, remember the pack's JamePeng llama-cpp-python wheel requirement.
A narrow node with a narrow, well-defined job - and that's fine. If you're not using Muse Glimmer, you'll never touch it. If you are, it's the difference between "the model said a bunch of stuff" and "here is the answer, here is the thinking, and here is proof the answer is complete." For a response parser, that's the full spec, done properly.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| muse_response | STRING | Raw response string produced by Muse Glimmer. |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| response | STRING | — |
| thinking | STRING | — |
| raw | STRING | Unclassified text and complete messages addressed to recipients other than self or user. |
| valid | BOOLEAN | True when a complete Muse Glimmer final-response marker was parsed. False for truncated reasoning or non-Muse text. |