ollama - 💡(How to fix) Fix imagegen: --negative / NegativePrompt is collected by the CLI but never reaches the runner (Z-Image CFG path is unreachable)

Summary

The Z-Image diffusion model in x/imagegen/models/zimage fully implements classifier-free guidance with a negative prompt (GenerateWithCFG), and the ollama run CLI accepts a --negative flag, but the value is silently dropped between them — there is no field on the runner's request schema to carry it, and the server handler always calls the legacy GenerateImage(...) (which hard-codes NegativePrompt="") instead of GenerateWithCFG(...).

Result: --negative is a no-op for every image-gen model today. With seed locked, output PNG bytes are byte-identical with and without the flag.

Reproduction (Ollama 0.23.0 on macOS, Apple Silicon, MLX runner)

```bash ollama run x/z-image-turbo:latest "an apple" \ --width 384 --height 384 --steps 4 --seed 42 \ --negative "red, crimson, scarlet, dark color" > /tmp/a.raw

ollama run x/z-image-turbo:latest "an apple" \ --width 384 --height 384 --steps 4 --seed 42 > /tmp/b.raw ```

After extracting the PNG from each kitty-graphics stream, both files hash to the same SHA-256 (`57216effa52901db…`, 145,915 bytes). `--negative` changes nothing.

Root cause (current `main`, commit `c2f2d90`)

1. Model layer supports it. `x/imagegen/models/zimage/zimage.go` lines 19, 150, 218, 230 declare `NegativePrompt`/`CFGScale`, expose `GenerateWithCFG(prompt, negativePrompt, …)`, and actually encode `negEmb` and run CFG when `cfg.NegativePrompt != ""`.

2. Wire schema does NOT carry it. `x/imagegen/types.go` lines 9–22 define the runner request as: ```go type Request struct { Prompt string `json:"prompt"` Options *RequestOptions `json:"options,omitempty"` Width int32 `json:"width,omitempty"` Height int32 `json:"height,omitempty"` Steps int `json:"steps,omitempty"` Seed int64 `json:"seed,omitempty"` Images [][]byte `json:"images,omitempty"` } ``` No `Negative` / `NegativePrompt` field anywhere.

3. Server handler ignores it even if present. `x/imagegen/imagegen.go:95` calls: ```go img, err := s.imageModel.GenerateImage(ctx, req.Prompt, req.Width, req.Height, req.Steps, req.Seed, progress) ``` `GenerateImage` is the legacy entry point — it constructs a `GenerateConfig` with `NegativePrompt` left as the zero value. `GenerateWithCFG` is never reached from the HTTP layer.

4. CLI collects the flag but has nowhere to send it. `x/imagegen/cli.go:56,62,98-99` registers `--negative`, marks it hidden, and writes the value into `opts.NegativePrompt` — but since `Request` has no field for it, the value never crosses the process boundary to the runner. (The flag is also `MarkHidden`, suggesting upstream knows it isn't wired.)

5. Other image-gen model packages don't support it at all. `grep -rn -i "negative\|uncond" x/imagegen/models/flux2 x/imagegen/models/qwen3` returns zero results.

Suggested fix

Three small wiring changes — model and CLI sides are already done:

1. `x/imagegen/types.go`: add ```go Negative string `json:"negative,omitempty"` ``` (and optionally `CFGScale float32 `json:"cfg_scale,omitempty"``).

2. `x/imagegen/cli.go`: include `Negative: opts.NegativePrompt` in the `Request` body the CLI POSTs to the runner.

3. `x/imagegen/imagegen.go`: when `req.Negative != ""`, call `GenerateWithCFG(...)` (or extend the `runner.ImageModel` interface so each model can decide). For Flux2/Qwen3, return a clear "model does not support negative prompt" error rather than silently dropping it.

Happy to send a PR if useful. The user-visible behaviour today is particularly confusing because the documented flag exists, the help text describes it, and there's no error when you use it — it just quietly does nothing.

Environment

• ollama 0.23.0 (also reproduces on 0.23.2; 0.23.2 separately segfaults in MLX VAE decode, see future report)
• macOS 14, Apple Silicon
• Models tested: `x/z-image-turbo:latest`, `x/flux2-klein:latest`, `x/flux2-klein:9b`