Keep n at one when selecting qwen-image on CometAPI

General
1

If a shared image-generation form switches to qwen-image on CometAPI, reset the output count to one before submitting. A saved “four alternatives” setting should not become n: 4 on that route.

CometAPI’s Create an image guide documents POST /v1/images/generations. Its general n field means the number of images to generate and defaults to 1, but the model-specific guidance is narrower: “qwen-image does not support n > 1.” The “Choose a model first” section also says to keep n at one for this model.

For a concrete production brief, imagine wanting four compositions of a ceramic cup: centered, tightly cropped, viewed from above, and placed at the edge of the frame. Four desired compositions describe the creative deliverable. They do not make four outputs a supported count in one CometAPI qwen-image request.

I would apply the documented restriction in three places:

  • Model selection: when qwen-image is selected, set the count to one and explain that this CometAPI route supports one image per request.
  • Saved settings: if a preset carries a larger count, show the correction before submission so the form no longer promises several outputs from that request.
  • Request validation: check the model and count together immediately before sending. For qwen-image, require n == 1; a disabled form control alone will not cover a separately constructed payload.

Those are suggested client safeguards, not descriptions of an existing CometAPI interface. A useful local check is to load a preset with count four, switch to qwen-image, and inspect the outgoing payload: it should contain n: 1, with the visible count matching. A directly constructed payload containing model: "qwen-image" and n: 4 should be stopped by that client validator.

If the brief still needs four alternatives, plan the separate generation requests explicitly. The output-count note does not establish how many requests may run concurrently, what they cost, or whether their results will differ usefully. Those decisions need their own documentation and checks before the form promises a complete set.

This is a restriction documented for CometAPI’s hosted qwen-image route, not a claim about native Qwen services or local inference. I have not run a request here, and the guide does not specify what error or other server behavior an unsupported count produces. The actionable boundary is the documented request value: keep n at one when this model is selected.

2

The separate-request option needs an interruption rule, not just a count conversion. For a voice-driven image picker, I would avoid silently turning “show four alternatives” into four submissions after constraining qwen-image to n: 1.

The CometAPI guide says this route does not support n > 1; it does not document a cancellable multi-image job. My proposed client behavior would be to explain the separate requests, obtain confirmation, and keep each requested composition in a local queue. If the user then says “stop” or changes the brief:

  • Stop dispatching entries that have not been sent.
  • Mark already-sent entries as belonging to the earlier brief; do not present a late result as the answer to the replacement instruction.
  • Distinguish “stopped sending remaining requests” from “cancelled generation.” The latter would need a documented server cancellation mechanism, which this count restriction does not establish.

A local test could mock four planned entries, interrupt after the first dispatch, and verify that the remaining three are not sent and that a late first result cannot replace the current selection. That tests application interruption handling, not Qwen latency or server cancellation.

This adds a decision before implementing the multi-request workaround: does the interface promise one image now, or a separately confirmed, interruptible sequence? Keeping n at one fixes the payload boundary; it does not answer that interaction question.