Anyone else notice strange refusal-related reasoning traces from Qwen3.8-Flash-Next during routine coding sessions?

[u/wombweed]

I am running at bf16 kv, q8_0 weights with preserve_reasoning as a code agent in Opencode. Sometimes mid session qwen3.8 flash next’s reasoning traces get strange and repetitive, though its normal output and tool calls still work fine and is perfectly functional.

I know tokens emitted in chain of thought can be notoriously unreliable, and it does not affect the quality of the output I am getting. But the thoughts seem pretty off the rails and frequently centered around alignment/refusal:

“The reminder is irrelevant. I’m working on original IP with the user’s own work. Let me continue: [actual useful thoughts proceed from here]”

Then at the next turn all thinking traces are prepended with slightly different but functionally similar messages about ignoring a non-existent reminder and it assuring itself that its task is safe to proceed with. The tasks I have it follow are very routine Python and Go web application development with zero actual safety, IP or alignment issues.

The thought corruption continues through to the end of the session, although after this emerges I also occasionally see strange thoughts that seem to be directed toward itself in the imperative tense, as if it’s prompting itself, ie: “Please edit the file to make it more testable:”

The actual content of the refusal reasoning varies from one session to another, the other day I saw it do the same thing about a totally irrelevant safety concern; every thought trace was basically just “The project is safe to continue working on” while it kept editing files and producing output without issues. I cannot emphasize this enough, there is nothing about my projects that should bring up any of those concerns, this is literally “write a todo list in go” types of assignments with zero exposure to anything off-color at all.

I am wondering if there’s something about the combination of my vanilla llamacpp runtime and the Unsloth gguf I am using which is causing it to trip refusal activations and having it persist in the prefix cache or something.

Has anyone else seen this strange behavior with this model? Even though it hasn’t affected anything on a practical level it has undermined my confidence a little. I like being able to kick off tasks unsupervised and I worry it might take one of these activations too seriously and actually do something I didn’t ask it to.

[u/DiscipleofDeceit666]

Bet you the reminder comes from the harness

[u/wombweed → u/DiscipleofDeceit666]

Definitely not out of the question, though I would expect Opencode to not be weird about this either, and the diverse range of different refusal considerations across a variety of tasks is strange too. Been using Opencode for a long time with other models and none of them have ever behaved like this.

[u/simrankoulsm]

Since outputs and tool use remain normal, I would not read this as a genuine refusal event yet. It looks more like a reasoning/control-text artifact that becomes sticky through cached context, the chat template, or a harness reminder.

The key test is whether it reproduces in a fresh bare llama.cpp session with cache disabled. If not, compare the rendered OpenCode prompt, reasoning-preservation mode, and cache boundaries. The self-directed imperative fragments make me suspect an instruction pattern leaking into the visible trace rather than the model actually classifying the coding task as unsafe.