8-frame coherence 2×2 matrix

One person (character A), eight chronological beats across one day in 8 different locations: dawn bedroom → coffee → train → cafe → park → reading window → cooking → balcony dusk.

Two people (A + B as an ensemble) across eight chronological beats in eight different locations of one shared day. Tests whether both identities lock independently across diverse rooms.

One person, ALL EIGHT beats in the SAME single location (a small home kitchen) at different moments / camera angles. Tests location coherence — room layout, cabinet placement, window position, lighting register, palette — across the set.

Two people, ALL EIGHT beats in the same small home kitchen. The most demanding combination: two distinct identities AND a single location must both stay consistent across all 8 panels.

Four tests targeting things that matter for Pikumo's actual production pipeline. Each test uses the K-recipe (gpt-5.4-mini + photo + sheet refs + low-q + 1024² + reasoning:high) and asks: "does this hold when we hit a real Pikumo-shaped surface?"

Test M — pet inclusion (text-only pet ref)

Pikumo's PET REFERENCE role in the canonical JSON spec normally takes a photo of the user's pet. Question: does the thinking-mode pipeline hold pet identity from text alone (a pet bible naming species + coat color + markings)? 6 beats with female_asian + "Whiskers, a fluffy long-haired ginger tabby with white socks, white chest, green eyes, long fluffy tail."

Result: yes. Whiskers reads as the same cat in every panel — same orange tabby coat, same white markings, same fluffy tail. Beat 4 (pet alone in frame) correctly renders ONLY the cat with the woman's shoes visible in the background — the model didn't invent a human. Pikumo can ship pet support without adding a pet-photo upload step.

6 panels · 219.6 s wall · 689 reasoning tokens · ~$0.06 total.

Test O — cross-style transfer (oil + sketch)

Question: does the recipe generalize across Pikumo's STYLE_GUIDE catalog, or does it overfit to dreamscape? Same 8-beat day-in-life prompt, only the style block changes. Two new styles:

Oil — gallery oil-painting register (visible brushwork, impasto, linen canvas)

8 panels · 334.4 s wall · 726 reasoning tokens · ~$0.075 total.

Sketch — pencil sketchbook register (loose linework, cross-hatching, paper grain)

8 panels · 298.5 s wall · 529 reasoning tokens · ~$0.07 total.

Result: clean transfer in both. Oil shows the requested impasto + warm earthy palette + atmospheric depth; sketch shows the requested loose pencil + cross-hatching + visible paper grain + minimal washes. Identity locks in both. No per-style optimization required.

Test P — dialogue / pull-quote handling

Pikumo's extract pipeline pulls quotes per beat (e.g., "Mom said 'I didn't know there were that many people who still loved me'"). Production prompts have strong NO TYPOGRAPHY rules. Does the thinking-mode pipeline honor that boundary when beats include dialogue language? 4 beats, each with a verbatim "she said X" cue + explicit "depict via expression, never as text" instruction.

Result: 4/4 panels have zero rendered text. No speech bubbles, no captions, no letters of any language. Emotional tone (surprise + gratitude / reluctance / helpless laughter / quiet wonder) conveyed entirely through facial expression, mouth shape, hand position, body language. Beat 1 has the woman mid-sentence with a hand to her chest and the brother attentive across the table — exactly the production-pattern. Direct migration from Pikumo's per-panel pipeline preserves this behavior.

4 panels · 157.1 s wall · 656 reasoning tokens · ~$0.05 total.

Test Q — panel-count scaling (N=2, N=4)

Pikumo's default story shape is 2-4 panels. We've measured 8-panel runs extensively; this test measures the actual 2-panel and 4-panel cost + latency curves Pikumo's pipeline would see.

N=2 sample

N=4 sample

The headline number for Pikumo: a 2-panel story renders in 74 s for $0.025 and a 4-panel renders in 160 s for $0.045 — both ending in complete rendering. With streaming, first paint is at ~33 s regardless of N. The 2-panel shape fits comfortably inside Pikumo's ~90 s wizard budget end-to-end. The 4-panel shape needs streaming to feel acceptable, but with streaming the first illustration lands while the user is still reading their wizard caption.

All four Pikumo probes — one-line synthesis

• M — pets need no separate upload; text bible holds identity. Ship Pikumo pet support directly on this pipeline.
• O — recipe generalizes across STYLE_GUIDE; no per-style tuning. Ship one pipeline for all styles.
• P — dialogue language in beats does not cause text-in-image violations. Pull-quote extraction stays usable.
• Q — typical 2-panel Pikumo story costs $0.025 in 74 s; 4-panel costs $0.045 in 160 s. With streaming, first paint at ~33 s regardless. The economics work.

The original Azure /v1/images/edits cohort study concluded: ship "photo + character sheet" (approach 3) for multi-panel sets — it won on set-wide consistency over photo-only (approach 2) and sheet-only (approach 1). Does that finding still hold in the new gpt-5.4-mini + thinking-mode pipeline?

Three runs against the locked-kitchen prompt from Test E. Identical model, tools, beats, location bible. The ONLY variable is what's attached as identity refs.

Photo (used in J & K)

Character sheet (used in K & L)

Token + cost ledger

Test J — photo only (today's production)

Test K — photo + character sheet (recommended)

Test L — character sheet only

Verdict

• All three configurations produce competitive identity hold across the 8 panels. Visually, K (both refs) has the most "settled" face proportions; J (photo only) is a close second; L (sheet only) shows mild drift toward generic-anime defaults but remains recognizably the same person.
• K is both the cheapest AND the strongest match. Adding the character sheet to the attached refs REDUCES reasoning-token consumption from 1,070 (photo only) to 561 — the sheet acts as a "hair + silhouette stabilizer" that the model would otherwise have to derive from scratch on each panel.
• The original "approach 3" recommendation holds — but for different reasons. In the Azure /edits single-shot world, photo+sheet won on cross-panel identity consistency. In the thinking-mode world, the reasoning step makes all three competitive on consistency; photo+sheet now wins on cost (cheaper reasoning) AND on face fidelity (more reference signal). Same conclusion, new mechanism.
• Pikumo's character-bible pipeline becomes more valuable, not less. The generated multi-view sheet (one-time cost per user) saves reasoning tokens on every subsequent story — payback period is essentially zero.

Updated production recipe

// Pikumo's thinking-mode pipeline, end of investigation:

POST https://api.openai.com/v1/responses
{
  "model": "gpt-5.4-mini",                              // 22× cheaper than gpt-5.4 at scale
  "input": [{ "role": "user", "content": [
    { "type": "input_text",  "text": "<style + identity + LOCATION BIBLE + beats>" },
    { "type": "input_image", "image_url": "<photo>" },            // K-recipe: both refs
    { "type": "input_image", "image_url": "<character_sheet>" }
  ]}],
  "tools": [{ "type": "image_generation",
              "quality": "low",                          // 35× cheaper than high
              "size":    "1024x1024" }],
  "tool_choice":         "auto",
  "parallel_tool_calls": true,
  "max_tool_calls":      N,                              // panel count
  "reasoning":           { "effort": "high" },
  "stream":              true                            // first paint at ~33-49s
}

Follow-up to Test E: does the LOCATION BIBLE technique scale to MULTIPLE locked locations in the same call? 8 beats alternating between a KITCHEN bible (beats 1, 2, 4, 6) and an ATTIC STUDY bible (beats 3, 5, 7, 8). Each beat is tagged. Identical model, tools, quality, size, max_tool_calls, reasoning effort as Test E.

Result: 8/8 panels correctly routed. Kitchen panels share the same kitchen (terracotta + sage cabinets + delft + 6-pane window + leaning fence post). Attic panels share the same attic (honey pine floor + ivory sloped walls + dark oak beam + diamond-pane dormer + navy window seat + kilim pillows + green-glass banker's lamp + Persian rug). Zero cross-contamination. Beat 8 even rendered the requested "dusk" lighting in the same attic — same room, evening sky.

All the prior tests waited for the full response before showing anything. The OpenAI /v1/responses endpoint supports stream: true with Server-Sent Events. Each image_generation_call result lands on the stream as soon as it's generated, not at the end of the response. That moves time-to-first-paint from ~5 min to ~50 s for an 8-panel story.

8-panel streaming timeline (gpt-5.4-mini · low quality · 1024²)

T+0.0 s     request sent
T+4.1 s     image 1 starts
T+48.6 s    image 1 FINAL  ← first paint at ~49s
T+85.5 s    image 2 FINAL  (+37 s)
T+118.2 s   image 3 FINAL  (+33 s)
T+156.4 s   image 4 FINAL  (+38 s)
T+190.7 s   image 5 FINAL  (+34 s)
T+223.2 s   image 6 FINAL  (+33 s)
T+263.2 s   image 7 FINAL  (+40 s)
T+324.0 s   image 8 FINAL  (+61 s)
T+327.1 s   response.completed

Cadence is ~39s per panel. Images stream sequentially even with parallel_tool_calls: true — the model reasons, fires one image, waits, then reasons and fires the next. Wall-clock total is unchanged from non-streamed (still ~5 min for 8 panels) — but the user-experience shape is completely different.

Wait-time UX shift

The 8 streamed panels (low quality, same prompt as Test A)

Integration recipe for Pikumo

The Worker already speaks SSE for the existing /generate endpoint (per CLAUDE.md). The integration is two surfaces:

// Worker side — pass through OpenAI SSE to client SSE
const upstream = await fetch("https://api.openai.com/v1/responses", {
  method: "POST",
  headers: { Authorization: `Bearer ${env.OPENAI_API_KEY}`,
             "Content-Type": "application/json" },
  body: JSON.stringify({
    model: "gpt-5.4-mini",
    tools: [{ type: "image_generation",
              quality: "low", size: "1024x1024" }],
    parallel_tool_calls: true,
    max_tool_calls: N,           // panel count
    reasoning: { effort: "high" },
    stream: true,                // ← the lever
    input: [/* user message with attached identity photo + prompt */],
  }),
});

// Parse SSE; forward each image_generation_call.output_item.done
// as a `panel` SSE event to the frontend with the panel index + b64.

// Frontend (main/app.js) — pop each panel into the album as it arrives
const es = new EventSource(`${API_BASE}/generate?sid=${storyId}`);
es.addEventListener("panel", (e) => {
  const { index, b64 } = JSON.parse(e.data);
  els.panels[index].src = `data:image/png;base64,${b64}`;
});

Notes

• partial_images: 2 didn't help much. A 4-panel test with partials enabled showed the "partial" preview landed only 1-3 s before the final — essentially the same image. Skip the parameter; saves ~$0.012 per 4-panel call.
• Cadence has occasional outliers — beat 8 took 61 s instead of ~33-40 s. Plan UI to render any time within a ~30-65 s window after the prior panel.
• The "first paint" budget on Pikumo's wizard is ~90 s. With streaming, the first illustration lands inside that budget; without, the user stares at "Loading…" for the full 5 minutes.

Follow-up to Test C's location drift. Same model, same image-tool config, same 8 beats — only the prompt changes. Adds: a 400-word LOCATION BIBLE (terracotta floor, sage-green walls + lower cabinets, cream uppers, brass knobs, blue-and-white delft backsplash, butcher-block counter, six-pane window with countryside + leaning fence post, white farmhouse sink, cream gas stove, copper pot rack with 3 pots, oak table with yellow vase of white daisies + stack of red/navy/cream books + sage-green mug), a PRESERVE LIST naming 15 invariants, and "the SAME X" re-anchors in every beat.

Result: location locks. The kitchen is visibly the same room in all 8 panels — same floor, same cabinets, same delft backsplash, same window-and-countryside view, same yellow-vase-with-daisies on the table. Cost: ~$0.08 (same as Test C); only the prompt did the work.