Skip to content

feat(batch): use Flow's native count selector for -n N; add --same-project for multi-prompt batches #14

Closed

Description

@ffroliva

Two related improvements

Part 1 — Fix -n N to use Flow's UI count selector (bug)

Today: gflow image t2i "prompt" -n 4 fans out 4 parallel single-image submissions into 4 separate projects. The asyncio.Lock in 1621748 made this safe, but the design is wrong.

Should be: Call generate_images(count=N) once. The transport sets the x{N} count button in Flow's UI (1x / x2 / x3 / x4), submits once, downloads N images from one project. Max -n 4 (Flow's UI cap). CLI rejects -n > 4 with a clear error.

Result: 1 project, N images, 1 submission round-trip. Strictly faster and matches user intent.

Part 2 — Add --same-project for multi-prompt batches (feature)

Today there's no first-class multi-prompt CLI (each prompt = separate gflow invocation). When that lands (e.g. gflow image batch manifest.tsv), users will want a choice:

  • Default: each prompt → its own new project.
  • --same-project: all prompts share one project, submitted sequentially with random 3-7s jitter. On per-item failure, log and continue.

Combines cleanly with Part 1: gflow image batch m.tsv -n 4 --same-project = one project, each manifest row produces 4 images via the native selector, 3-7s jitter between rows.

Implementation sketch

  • Part 1: refactor generate_images_batch to delegate to generate_images(count=N) when given one prompt; remove the fan-out plus lock for that path (lock may still be needed for cross-profile concurrency — investigate). Add count-selector UI interaction. CLI validation: -n in [1, 4].
  • Part 2: new --same-project flag on the multi-prompt commands (when those land). New transport path _run_batch_same_project(prompts, jitter_range).

Open

  • Flag name --same-project confirmed (bikeshed: --group, --one-project).
  • Jitter range: 3-7s hardcoded for v1, configurable later.

Out of scope

  • Per-prompt -n (different counts per prompt) — future, behind a JSON manifest.
  • Parallel-in-same-project — Flow's UI almost certainly can't handle it.

Activity

  1. ffroliva commented on May 17, 2026

    @ffroliva
    OwnerAuthor

    Production integration note from Compiled Growth worker hardening (2026-05-17): this should explicitly preserve t2i defaulting to one image.

    Observed failure mode downstream: the worker/API path generated Flow candidates with x4, but the pipeline persisted only one selected image per scene. That wastes wall-clock time/quota and makes integrations look correct while silently discarding 75% of generated output.

    Acceptance criteria to add to this issue:

    • gflow image t2i "prompt" generates exactly 1 image by default.
    • -n 2, -n 3, and -n 4 are explicit opt-in and map to Flow's native count selector.
    • -n validates as 1..4; 0, negatives, and >4 fail before opening Flow.
    • Docs/help text should describe the default as 1 and extra candidates as opt-in.
    • Regression coverage should assert the request/transport receives count=1 when -n is omitted.

    This matches the downstream contract: one selected image per scene unless the caller has explicitly requested and intends to consume multiple candidates.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingenhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions