Issue when creating images via OpenAI

[badcom]

⏺ Same error: "The operation was aborted." Exit code 1, no actual OpenAI error message — the request never even reached a response. Let me find out why the designer is aborting its own request.

⏺ Bash(_D="/Users/badcom/.claude/skills/gstack/design/dist/design"
echo "--- abort/timeout strings in binary ---"…)
⎿  --- abort/timeout strings in binary ---
fd_timeout_ms = timeout / BigInt(1e6);
let tNS = BigInt(t), waitNs = (absolute ? timeout : tNS + timeout) - tNS;
… +32 lines (ctrl+o to expand)
⎿  Allowed by auto mode classifier

⏺ Bash(_D="/Users/badcom/.claude/skills/gstack/design/dist/design"
echo "--- look at the actual generate() call surrounded with context ---"…)
⎿  --- look at the actual generate() call surrounded with context ---
const timeout = setTimeout(() => controller.abort(), 120000);
try {
… +34 lines (ctrl+o to expand)
⎿  Allowed by auto mode classifier

⏺ Found the cause: the designer binary has a hardcoded 120-second timeout that calls controller.abort(). Your generation took longer than 120s, so the binary killed its own request — that's where "The operation was aborted." comes from.

Now I need to know if it's slow because of OpenAI (load / your account tier) or because the key/endpoint don't work at all. Quick API-key sanity check:

⏺ Bash(_KEY=$(jq -r .api_key ~/.gstack/openai.json 2>/dev/null)
echo "--- 1. Cheap chat call (does the key auth at all?) ---"…)
⎿  --- 1. Cheap chat call (does the key auth at all?) ---
"usage": {
"prompt_tokens": 11,
… +40 lines (ctrl+o to expand)
⎿  Allowed by auto mode classifier

⏺ Key works (HTTP 200, 3.2s) and image generation IS available (chatgpt-image-latest in your model list). The blocker is purely that the image render is taking longer than the binary's hardcoded 120s timeout.

Let me time a direct image call so we know whether OpenAI is the slow one, or if there's a workaround:

⏺ Bash(_KEY=$(jq -r .api_key ~/.gstack/openai.json 2>/dev/null)
echo "--- Direct image-generation call, no timeout cap ---"…)
⎿  --- Direct image-generation call, no timeout cap ---
Starting at 07:22:05...
Done at 07:22:32 (~27s wall clock)
… +119 lines (ctrl+o to expand)
⎿  Allowed by auto mode classifier

⏺ Direct image call worked in 27 seconds — so your key is fine and OpenAI is fast for image generation. The binary is broken for a different reason: it uses the newer /v1/responses endpoint (a multi-step "agent calls image tool" path) instead of the
simpler /v1/images/generations. That path is what's hanging past 120s.

Let me confirm by hitting the binary's actual endpoint the way it does:

⏺ Bash(_KEY=$(jq -r .api_key ~/.gstack/openai.json 2>/dev/null)
echo "--- /v1/responses with image_generation tool (binary's endpoint) ---"…)
⎿  --- /v1/responses with image_generation tool (binary's endpoint) ---
"store": true,
"temperature": 1.0,
… +70 lines (ctrl+o to expand)
⎿  Allowed by auto mode classifier

⏺ Diagnostic complete — found something weird:

Your account is healthy:

• Direct /v1/images/generations call → 27s ✓
• /v1/responses with image_generation tool (the exact endpoint the binary calls) → 26s ✓
• Both well under the binary's 120s timeout

But the gstack design binary still hangs past 120s. It's not your account, not the network, not the endpoint — something in the binary's own pipeline (prompt assembly, retries, post-processing, or vision-quality-check loop) is the bottleneck. The binary
has no --timeout flag and the timeout is baked in.

Most likely the binary makes multiple sequential calls per generate (assemble brief → generate image → vision quality check → maybe retry) and the cumulative latency blows the 120s budget. There's no clean fix from the outside.

Three real options:

1. /design-html — Claude-powered. No image-gen involved at all. Generates real working HTML/CSS from the design contract in your plan file, opens in a browser, you can interact with it. For your design system (token-mapped) this is arguably the better
   deliverable than raster mockups.
2. Bypass the binary — I can write a small script that uses your working OpenAI key + the direct /v1/images/generations endpoint (27s each, proven) to generate PNGs for each surface in the matching trio, save them to
   ~/.gstack/projects/more-than-writers-gstack/designs/, and build a comparison HTML to view in browser. No binary involved. ~30 lines of bash.
3. Report the binary bug — file an issue with gstack. Not actionable for you today.

[RagavRida]

Looked into this. The diagnostic in the issue body is right that the OpenAI endpoint itself is fast (curl ~26s), but the binary hangs past 120s. Root cause: the timeout is hardcoded 120_000 at five image-generation callsites with no CLI override:

• design/src/generate.ts:40
• design/src/iterate.ts:85 and :133
• design/src/variants.ts:61
• design/src/evolve.ts:55

(The existing --timeout flag is plumbed only to compare --serve / serve for the design-board HTTP listener — design/src/cli.ts:145, 251. It does not reach the image-gen path.)

Why curl finishes in 26s but the binary doesn't: the diagnostic curl test most likely used a smaller image (the cheap chat call shape) than the binary's defaults (1536x1024 + quality: high). At those defaults with gpt-4o + image_generation tool, response time pushes into the 90-180s range on slower account tiers, which is right at the 120s ceiling and tips over for many users.

Taking this. Plan: add --api-timeout <ms> CLI flag (distinct name to avoid colliding with the existing serve --timeout), thread it through GenerateOptions, VariantsOptions, IterateOptions, EvolveOptions, and bump the default from 120_000 to 300_000 so the existing fleet stops timing out at defaults. Five callsites, one CLI surface, no behavior change for users who aren't currently timing out. PR shortly.