One thing worth checking on that Modelfile: the TEMPLATE only uses .Prompt, with no .Messages and no .Response. Going by template.go in the Ollama repo, a template with neither gets {{ .Response }} appended at parse time and then runs once per user/assistant pair in legacy mode. So from turn two on, the earlier answer lands right after the bare <|start|>assistant with no channel header and no <|end|>, and the hard-coded system block repeats in front of every pair (a SYSTEM line in the Modelfile is ignored too, since .System is never referenced). Single-shot ollama run would look fine, multi-turn chat is where I'd expect it to drift. Ranging over .Messages and writing each past assistant turn as a final-channel message closed with <|end|> should avoid it. I read this from the source, I haven't run it against a gpt-oss GGUF.
One thing worth checking on that Modelfile: the TEMPLATE only uses .Prompt, with no .Messages and no .Response. Going by template.go in the Ollama repo, a template with neither gets {{ .Response }} appended at parse time and then runs once per user/assistant pair in legacy mode. So from turn two on, the earlier answer lands right after the bare <|start|>assistant with no channel header and no <|end|>, and the hard-coded system block repeats in front of every pair (a SYSTEM line in the Modelfile is ignored too, since .System is never referenced). Single-shot ollama run would look fine, multi-turn chat is where I'd expect it to drift. Ranging over .Messages and writing each past assistant turn as a final-channel message closed with <|end|> should avoid it. I read this from the source, I haven't run it against a gpt-oss GGUF.