DEV Community: Super Lewis

Nano Banana 2.1 vs Nano Banana Pro: Same Prompts, Real Latency Data, and When Pro Is Worth It

Super Lewis — Thu, 08 Oct 2026 02:59:03 +0000

Short answer: for most product images, banners and text-heavy graphics, Nano Banana 2.1 does the job at roughly half to a third of Nano Banana Pro's price and about twice the speed. Pick Pro when the scene needs more world knowledge, richer detail or more character references (5 versus 4).

Nano Banana 2.1 is Google's Flash-tier image generation and editing model (Gemini API id gemini-nano-banana-2.1, released on 6 October 2026, built on Gemini 3.6 Flash). Nano Banana Pro is the Pro tier (gemini-3-pro-image). Google's own docs call 2.1 "the more efficient counterpart to Gemini 3 Pro Image".

Disclosure up front: the production numbers below come from apimodels.app, the API platform I work on, and the test images were generated through it.

How I compared them

I fixed the criteria before looking at any output:

Price per image at 1K, 2K and 4K, from Google's pricing page (updated 7 October 2026, standard tier).
Documented capabilities: reference-image limits, thinking controls, grounding, aspect ratios.
Same-prompt output at 2K, 16:9: one text-heavy infographic, one edit from a reference image.
Real-world latency and success rate from one week of production traffic (1–8 October 2026).

At a glance

	Nano Banana 2.1	Nano Banana Pro
Gemini API id	`gemini-nano-banana-2.1`	`gemini-3-pro-image`
Google price, 1K / 2K / 4K	$0.0336 / $0.0504 / $0.113	$0.134 / $0.134 / $0.24
Object references	up to 10	up to 6
Character references	up to 4	up to 5
Style references	up to 3	not documented
Thinking	minimal / medium / high (default medium)	always on
Google Search grounding	Web and Image Search	Web Search
Extra wide ratios	1:4, 4:1, 1:8, 8:1	no
Our median time, 2K	about 25 s	about 40 s
Best for	volume, banners, infographics, many object refs	complex scenes, brand-exact work, more character refs

At 2K, Pro costs 2.7 times as much as 2.1 on Google's list; at 1K the gap is 4 times.

Test 1: a text-heavy infographic

Prompt (same for both, 2K, 16:9):

A clean flat-design infographic poster, 16:9, titled "How an image API request works". Four numbered steps left to right, each with an icon and a short label: "1. Send prompt", "2. Queue task", "3. Render image", "4. Download result". A small footer line reads "Average time: 25 seconds". White background, navy and coral accents, crisp legible typography.

Both models spelled every string correctly: the title, the four labels and the footer. Pro drew richer icons inside numbered circles; 2.1 went flatter and turned the footer into a navy bar. 2.1 finished in 25 seconds, Pro in 57. For text-heavy graphics at this size, I could not tell you which one is "better" without a style preference.

Test 2: editing with a reference image

The reference was a 1280×720 title card from our own site (that is why the brand name appears on the screen). Prompt:

Use the reference image as the screen content. Show it playing on a large modern TV mounted on a living-room wall at night, warm lamp light, a plant on the left, a soft reflection on the floor. Keep the on-screen poster recognisable.

Scored against the prompt:

Wall-mounted TV: 2.1 yes; Pro placed it on a cabinet.
Plant on the left, warm lamp: both.
Reflection on the floor: Pro yes; 2.1 put it on a foreground table (with the letters correctly mirrored).
On-screen text kept exact: both.

Each model missed one instruction. 2.1 took 28 seconds, Pro 49.

A week of production timings

Two prompts prove nothing about reliability, so here is what real traffic looked like on apimodels.app from 1 to 8 October 2026:

Model and job	Requests	Median	90th percentile
Pro, 4K with references	617	61 s	252 s
Pro, 2K with references	203	40 s	76 s
Pro, 2K text only	83	38 s	143 s
2.1, 4K with references	16	45 s	50 s
2.1, 2K (all)	6	about 25 s	35 s
2.1, 1K text only	2	13 s	15 s

Success rates over the same week: Pro 98.9% (971 requests; all 11 failures were content-moderation refusals), 2.1 97.6% (41 requests since it went live on 7 October; one upstream failure). The 2.1 sample is small, so treat its percentiles as a first look. The striking number is Pro's 4K tail: one request in ten took over four minutes.

Reproduce it

Node 18+ (uses the built-in fetch). The same script runs either model; swap the id.

// compare.mjs — APIMODELS_API_KEY in your environment
const BASE = 'https://api.apimodels.app/v1'
const H = { Authorization: `Bearer ${process.env.APIMODELS_API_KEY}`, 'Content-Type': 'application/json' }
const prompt = 'A clean flat-design infographic poster, 16:9, titled "How an image API request works" ...'

async function run(model) {
  const t0 = Date.now()
  const created = await fetch(`${BASE}/images/generations`, {
    method: 'POST', headers: H,
    body: JSON.stringify({ model, prompt, aspect_ratio: '16:9', resolution: '2K' }),
  }).then(r => r.json())
  const id = created.data.taskId
  for (;;) {
    await new Promise(r => setTimeout(r, 4000))
    const task = await fetch(`${BASE}/images/generations?task_id=${id}`, { headers: H }).then(r => r.json())
    if (!['pending', 'processing'].includes(task.data.state)) {
      return { model, state: task.data.state, seconds: Math.round((Date.now() - t0) / 1000), urls: task.data.resultUrls }
    }
  }
}

console.log(await Promise.all([run('nano-banana-2-1'), run('gemini-3-pro-image')]))

To edit instead of generating, add image_urls: ['https://…/your-reference.jpg'] to the body (2.1 accepts up to 10 references here).

Which one should you pick

High-volume banners, thumbnails, product shots → 2.1. About half the time per image and a third to a half of the price.
Infographics and labelled diagrams at 2K or 4K → 2.1 first. It matched Pro on spelling in my test, and Google's model card reports infographic factuality of 0.521 for 2.1 versus 0.179 for Nano Banana 2.
Very wide banners (4:1, 8:1) → 2.1. Pro does not offer those ratios.
Scenes that lean on world knowledge, exact brand assets or five recurring characters → Pro. That is where Google positions it, and its extra detail showed in the icons.
Small text at 1K or long paragraphs → neither. Google lists blurry small text at 1K as a known 2.1 limitation; render text at 2K or add it in post.

Where the numbers came from, and when not to use apimodels.app

apimodels.app is a multi-model API gateway: one API key and OpenAI- and Anthropic-compatible endpoints for about 150 image, video, audio and language models. Over the week above, Pro and 2.1 ran there at 98.9% and 97.6% success, failed calls are not charged, and the per-image prices are $0.024 / $0.04 / $0.064 for 2.1 and $0.08 / $0.08 / $0.13 for Pro, below Google's standard list.

Do not route through it if you need 2.1's thinking-level control, Google Search grounding or all 14 reference images: our endpoint does not expose those yet, and Google's API does. The same applies if you only use Gemini and can wait for Google's batch tier, which is half the standard price. Model pages: Nano Banana 2.1 and Nano Banana Pro.

Limits of this comparison

Two prompts, one run each, at 2K only. Image models vary run to run, so a single miss (Pro's cabinet, 2.1's table reflection) is an anecdote, not a rate. The latency data is real traffic but skewed toward 4K jobs with references for Pro.

Which job would you trust to 2.1 and which would you still send to Pro? I'm curious where others draw the line.

This post was written with AI assistance from the test data above and reviewed before publishing. The comparison images are AI-generated by the two models being compared.

How to Render a Motion Graphics Video with Claude Opus 5.5: Prompt, Frame Renderer, ffmpeg and Real Cost

Super Lewis — Wed, 07 Oct 2026 05:39:15 +0000

Claude Opus 5.5 cannot output a single pixel, yet people keep posting motion-graphics videos "made by Opus 5.5". The trick is that the model writes a program that draws every frame, and you render that program into an MP4. This post is the full, reproducible pipeline we used for a 12-second 1280x720 promo: the exact prompt, the API call, a 25-line frame renderer, the ffmpeg command, and what it actually cost.

Disclosure up front: we ran this through apimodels.app, the API gateway I work on. apimodels.app is a multi-model API gateway: one API key and an OpenAI-compatible endpoint for about 150 image, video, audio and language models, including claude-opus-5-5. Every step below works the same against any OpenAI-compatible endpoint that serves Opus 5.5; only the base URL changes.

The idea in one sentence

Ask Opus 5.5 for an HTML page with a deterministic renderFrame(t) function, not for "a video", then let a headless browser call that function once per frame.

Opus 5.5 outputs text. A page that animates itself with requestAnimationFrame looks fine in a browser, but you cannot export it frame-accurately, because what you see depends on timing. A page whose every frame is a pure function of t can be rendered frame 0, frame 1 … frame 359 in any order, and each call returns the same picture. That is exactly what a video encoder needs.

What you need

An API key for an endpoint that serves claude-opus-5-5 (OpenAI chat-completions format).
Node.js 20+ and puppeteer-core (npm i puppeteer-core works; we use the Chrome already installed on the machine).
ffmpeg 6+.
About seven minutes of patience for the model call. More on that below.

Step 1: write the prompt as a frame contract

The rules in the first half of this prompt are what make the output renderable. The story comes second, the style last. This is the prompt we sent, unedited:

You are writing a program that renders a video. Output one complete, self-contained HTML file and nothing else.

Rules for the program (these make it renderable frame by frame):
1. A single <canvas> of exactly 1280x720, no CSS scaling, black page background.
2. Expose a global function window.renderFrame(t) that draws the frame at time t (seconds, 0 <= t < 12) from scratch. Everything on screen must be a pure function of t: no Date.now, no performance.now, no Math.random (use a seeded PRNG if you need noise), no accumulated state between calls, no requestAnimationFrame loop.
3. Also expose window.DURATION = 12 and window.FPS = 30. When the page is opened normally, play it once in a loop with requestAnimationFrame by calling renderFrame, so a human can preview it.
4. No external assets, fonts, images or libraries. Use system-ui for text.
5. The rhythm is 120 BPM: a beat every 0.5 s. Put every major cut, text entrance and impact on a beat time (a multiple of 0.5). List the beat plan as a comment at the top of the script.

The story (tell this, then decide the visuals):
A 12-second promo for "APIMODELS", an API gateway. Problem, then turn, then payoff:
- 0-3 s: a developer's screen is cluttered with many different API keys and SDK logos flying in from every side, overlapping, getting chaotic (draw them as simple rounded labels such as "image", "video", "LLM", "audio", "key_1", "key_2", "sdk", not real company logos).
- 3-4.5 s: everything snaps together on a beat and collapses into one glowing key.
- 4.5-9 s: from that one key, lines fan out to a grid of model cards that light up one per beat (label them "145 models", "image", "video", "LLM", "audio", "one endpoint").
- 9-12 s: clean end card: the word APIMODELS, the line "One key. Every model.", and "apimodels.app" small underneath; hold still for the last second.

Style: dark background, one accent colour (electric violet #7c5cff) plus white, motion with easing (easeOutCubic / easeInOutQuad written by you), subtle depth (scale and blur fall-off), no clutter in the final 3 seconds.

Before the code, do not explain. Return only the HTML.

Three details mattered more than the wording:

Ban every source of non-determinism by name. Date.now, performance.now, Math.random and accumulated state are the usual culprits. The model followed all four.
Fix the rhythm in numbers. "120 BPM, cuts on multiples of 0.5 s, write the beat plan as a comment" produced a 24-beat plan, and every cut landed on one.
Say what must not appear. We asked for plain rounded labels instead of real company logos, which keeps the result usable.

Step 2: call Opus 5.5 with streaming and no small max_tokens

curl https://api.apimodels.app/v1/chat/completions \
  -H "Authorization: Bearer $APIMODELS_API_KEY" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile p prompt.md \
        '{model:"claude-opus-5-5", stream:true, messages:[{role:"user", content:$p}]}')" \
  --no-buffer > stream.txt

Two things will bite you here if you skip them:

Opus 5.5 thinks before it writes, and thinking counts as output. On this prompt the first character of the answer arrived after 110 seconds, and the full reply took 6 minutes 37 seconds. Stream the request so the connection stays alive. A client with a 60-second timeout will give up long before the first token.
Do not send a small max_tokens. The reply used 31,786 output tokens for about 16,000 characters of HTML, most of it thinking. A max_tokens: 4096 cap cuts the file off mid-script. If you omit the field, apimodels.app uses the model's own ceiling instead of inventing a small default.

Join the delta.content pieces from stream.txt and save the result as promo.html. Open it in a browser first: it should play its own preview loop.

Step 3: render every frame with headless Chrome

// render.mjs: pnpm add puppeteer-core (or npm i puppeteer-core)
import puppeteer from 'puppeteer-core'
import { mkdirSync, writeFileSync } from 'node:fs'

mkdirSync('frames', { recursive: true })
const browser = await puppeteer.launch({
  executablePath: '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome',
})
const page = await browser.newPage()
await page.setViewport({ width: 1280, height: 720 })
await page.goto('file://' + process.cwd() + '/promo.html')
await page.evaluate(() => { window.requestAnimationFrame = () => 0 }) // stop the preview loop
const { DURATION, FPS } = await page.evaluate(() => ({ DURATION, FPS }))
for (let i = 0; i < DURATION * FPS; i++) {
  const png = await page.evaluate((t) => {
    window.renderFrame(t)
    return document.querySelector('canvas').toDataURL('image/png')
  }, i / FPS)
  writeFileSync(`frames/f${String(i).padStart(4, '0')}.png`, Buffer.from(png.split(',')[1], 'base64'))
}
await browser.close()

On Linux, point executablePath at your Chromium binary. 360 frames took 14 seconds on a laptop, and the page threw no errors.

Step 4: encode with ffmpeg

ffmpeg -framerate 30 -i frames/f%04d.png -c:v libx264 -pix_fmt yuv420p -crf 20 -movflags +faststart promo.mp4
# optional soundtrack, keep the BPM you gave the model:
# ffmpeg -i promo.mp4 -i beat.mp3 -c:v copy -shortest promo-with-audio.mp4

yuv420p and faststart are what make the file play everywhere, including in browsers and on phones. The result was a 1.8 MB, 12-second, 30 fps MP4.

Step 5: check frames at the story beats

Before judging the video, pull frames at the moments the brief describes and put them side by side: 2.3 s (the clutter), 3.5 s (one key), 7.2 s (cards lighting up) and 11.3 s (end card).

All four matched on the first attempt. To change something, ask by timecode and beat ("at 7.5 s the sixth card should light up with a pulse") and ask for the whole file back, so the frame contract stays intact.

What it cost

Item	Value
Model	`claude-opus-5-5`
First token / total time	110 s / 6 min 37 s
Output tokens	31,786 (mostly thinking)
Cost at Anthropic list price ($4 / $20 per 1M tokens)	about $0.64
Cost at apimodels.app list price ($2.40 / $12 per 1M tokens)	about $0.38
Rendering and encoding	local, free

Output tokens dominate. A clip that needs 30,000 to 80,000 tokens of thinking and code costs roughly $0.36 to $0.96 per attempt at the lower rate, so budget for two or three attempts per finished clip.

When this approach is the wrong tool

Code-rendered video is good at kinetic typography, UI walkthroughs, animated charts, logo reveals, explainers and social templates you can re-render with new text in seconds. It is the wrong tool for anything that has to look filmed: photoreal people, natural camera motion, skin, fabric, physics. For those shots use a text-to-video model and let Opus 5.5 write the shot list and prompts instead.

It also has no audio (add it with ffmpeg), and the model never runs its own page. Treat the HTML as untested code: render it and look at the frames before you trust it.

Where to go from here

The model page for Claude Opus 5.5 on apimodels.app has the API parameters and this run's files.
We collected 60+ Opus 5.5 video prompts with the original posts and methods, sorted into motion design, product promos, explainers, music videos and 3D.

What would you render first with a renderFrame(t) contract: a chart, a logo reveal, or a UI walkthrough? I'm curious which kind of clip breaks the approach.

This post was written from our own run's code and numbers; AI helped with structure and editing.

Photoshop's Pen Tool Is Done: How AI Splits a Flat Image into Layers

Super Lewis — Tue, 06 Oct 2026 13:27:39 +0000

Originally published on the LayerGrab blog. Disclosure: I build LayerGrab, an AI tool that splits images into layers; this post was drafted with AI assistance and edited by me.

Separating a flat image into layers used to be the one job you could not hand off: Pen tool, Layer via Copy, Content-Aware Fill, repeat for every element. Image layer decomposition is the AI task that does it in one pass: a model takes a flat RGB image and returns a stack of RGBA layers, one per element, with the regions behind each element filled in so the layers recompose into the original.

Here is how it works, what we measured on a real poster today, and where it breaks.

What the model has to do

Three things at once, which is why this was hard until recently:

Decide what the elements are. Not pixels by colour, but "headline", "badge", "cup".
Cut each one out as RGBA with a usable alpha edge.
Invent what was behind each element, because the camera or designer never stored it. Without this, moving a layer leaves a hole.

Segmentation models solve step 2 and inpainting models solve step 3. A decomposition model does all three, which is what makes the output a real layered file instead of cutouts on a broken background.

Running the open model: what we measured

Qwen-Image-Layered (Apache 2.0, weights released December 2025) is the open model for this. We ran it through fal's hosted API on an 880 × 1184 coffee shop poster on 2026-10-06. Example request, from fal's public docs:

# Example (fal queue API). FAL_KEY is your own key.
curl -X POST https://queue.fal.run/fal-ai/qwen-image-layered \
  -H "Authorization: Key $FAL_KEY" \
  -H "Content-Type: application/json" \
  -d '{"image_url": "https://example.com/poster.png", "num_layers": 4, "output_format": "png"}'

What came back with num_layers: 4:

4 PNGs, each 544 × 736, the full canvas size: the model works at around 640 px on the long side, and its README recommends that resolution.
Layer 1 was the fully opaque background; layers 2–4 were transparent everywhere except their element.
Text, the discount badge and three small leaves shared one layer; the cup got its own; one large leaf got its own.
Stacked back together, the layers matched the downscaled original with a 1.5% mean pixel difference.
18.6 s of inference, 65 s end to end including the queue.

With num_layers: 2, the cup and headline stayed in the background layer, and the second layer held only the small decorations.

Pitfalls that decide whether the layers are usable

You choose the layer count, and it groups by depth, not by object. Too few layers and the main subject stays in the background. Start at 4–6.
Resolution drops. Expect ~640 px output. Upscale afterwards if you need print size.
VRAM. Users in the model's GitHub issues report failures on 16 GB cards and trouble on 24 GB; ComfyUI's guide measured a 45 GB peak at 1024 px.
Text is pixels. You get the headline on its own layer, not as editable type. Hide it and retype.
Hosted APIs bill per output image. fal charges per image returned, so 4 layers cost 4×.

When you don't want to run it yourself

LayerGrab is an AI tool that splits one image into up to 16 separate transparent layers, one per element, names each layer from what it shows, fills the background behind them, and exports PNG, ZIP or a layered PSD. On the same poster it returned 10 named layers in 100 seconds at the original resolution. It also runs Qwen-Image-Layered itself, with a free 2-layer try, if you want to compare: layergrab.com/qwen-image-layered-free.

Don't use it if your images must stay on your own machine: run the open model locally instead.

Is Photoshop dead?

As a finishing tool, no: we even ship a Photoshop plugin. As the place you go to cut a flat image apart by hand, yes. That job is now a model call.

Have you tried any of these models on real client work? I'm curious where the output broke for you.

Claude Opus 5.5 vs GPT-6.1 Sol: which one to call, and how to measure it on your own prompts

Super Lewis — Thu, 01 Oct 2026 14:51:37 +0000

Claude Opus 5.5 and GPT-6.1 Sol are the two models most teams are choosing between this week. Opus 5.5 is Anthropic's everyday flagship, released on 22 September 2026. GPT-6.1 Sol is OpenAI's upgraded mid-tier model, released at DevDay on 29 September 2026. The short answer: pick GPT-6.1 Sol for high-volume and cost-sensitive work, and Claude Opus 5.5 for long agentic coding and tasks where a wrong answer costs more than the tokens. The longer answer depends on reasoning effort, and you can check it on your own prompts in about ten minutes.

Disclosure up front: I work on apimodels.app, a multi-model API gateway that serves both models. Prices for it below are its public prices on 1 October 2026. This post was drafted with AI assistance and checked against the vendors' pages.

How I compared them

List price per 1M tokens, from the vendors' pages on 1 October 2026.
Specs that change your code: context window, max output, reasoning controls.
Benchmarks both models were run on in the same table. The labs mostly publish different suites, so I only use rows where both appear, and I name who ran them.
Cost per call for a realistic agent turn, computed from the prices above.

At a glance

	Claude Opus 5.5	GPT-6.1 Sol
Released	22 Sep 2026 (Anthropic)	29 Sep 2026 (OpenAI DevDay)
List price, input / output	$4 / $20	$2 / $10
Cached input (list)	$0.20 read, $5 write	$0.10 read, $2.50 write
Context / max output	1M / 128K	1.05M / 128K
Knowledge cutoff	June 2026	30 April 2026
Reasoning control	effort low to max, default medium, always thinks	reasoning_effort low to max, default medium, no `none`
Long context surcharge	—	above 272K input: input and cache 2×, output 1.5×
Best for	long agent sessions, review, careful writing	volume, extraction, cost-capped agents
Not for	high-volume bulk classification	code that relies on `reasoning_effort: none`

The benchmarks they share

OpenAI's GPT-6.1 Sol launch included Opus 5.5 in several rows. These are OpenAI's runs and OpenAI's choice of benchmarks, so read them as a vendor's claim:

Benchmark (OpenAI launch)	Effort	GPT-6.1 Sol	Claude Opus 5.5
AutomationBench	medium	31.7%	29.5%
AutomationBench	max	36.1% ($0.30/task)	42.5% ($1.44/task)
GDP.pdf	medium	30.0% ($0.34/task)	25.6% ($0.80/task)
Terminal-Bench Science 0.1	max	57.0% ($5.47/task)	63.3% ($23.21/task)

The pattern is consistent: at medium effort GPT-6.1 Sol edges ahead, at max effort Opus 5.5 pulls ahead, and Sol costs less per task in every row. Independent aggregates point the same way on capability. Reported max-effort figures put Opus 5.5 at 58 and GPT-6.1 Sol at 52 on the Artificial Analysis Intelligence Index, with cost per index task of $5.98 and $0.72.

Anthropic's own launch numbers for Opus 5.5 (66.4% on Terminal-Bench 4.0, 57.8% on CursorBench 4.0) have no GPT-6.1 Sol row, so they don't settle the head-to-head.

What one agent turn costs

Take a coding-agent turn that re-sends 50,000 input tokens, 40,000 of them cached, and returns 2,000 output tokens:

	Claude Opus 5.5	GPT-6.1 Sol
At list price	$0.088	$0.044
On apimodels.app	$0.053	$0.022

Two things move these numbers in practice. Opus 5.5 always thinks, so its reasoning tokens land in the output bill even on short answers. GPT-6.1 Sol at low effort spends far fewer reasoning tokens, which is where most of its cost-per-task advantage comes from.

Measure it on your own prompts

Benchmarks are someone else's tasks. The fastest way to decide is to send the same twenty prompts to both models and compare answers and cost. Both are OpenAI-compatible on apimodels.app, so one client covers both, and every response carries the billed amount in an x-apimodels-cost header.

Tested with Python 3.11 and openai 1.x:

import os, time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["APIMODELS_API_KEY"],
    base_url="https://api.apimodels.app/v1",
)

MODELS = ["claude-opus-5-5", "gpt-6.1-sol"]

def ask(model: str, prompt: str) -> dict:
    t0 = time.time()
    raw = client.chat.completions.with_raw_response.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        max_tokens=8000,
    )
    r = raw.parse()
    return {
        "model": model,
        "seconds": round(time.time() - t0, 1),
        "in": r.usage.prompt_tokens,
        "out": r.usage.completion_tokens,
        "billed_usd": raw.headers.get("x-apimodels-cost"),  # what you were actually charged
        "answer": r.choices[0].message.content,
    }

prompts = [line for line in open("prompts.txt") if line.strip()]
for p in prompts:
    for m in MODELS:
        res = ask(m, p)
        print(f'{res["model"]:16} {res["seconds"]:>6}s  in={res["in"]:>6} out={res["out"]:>6}  ${res["billed_usd"]}')

Score the answers yourself, or with a third model as judge, then divide the total billed cost by the number of answers you would ship. That number is the one that matters.

Gotchas when switching

reasoning_effort: "none" is not on GPT-6.1 Sol's list. OpenAI's model page lists low, medium, high, xhigh and max. Code written for GPT-6 Sol that sends none should send low.
Small max_tokens can return an empty answer. Reasoning counts against the budget on both models. If finish_reason is length and the content is empty, raise max_tokens or lower the effort.
Long prompts change Sol's price. Above 272K input tokens the whole request is billed at 2× input and 1.5× output.
Opus 5.5 can't be made to cost less by turning thinking off. If a task is simple enough that thinking is waste, it is probably a Sol task.

Which one should you pick

Classification, extraction, routing, bulk summarisation → GPT-6.1 Sol at low effort.
Agents with a hard cost cap per task → GPT-6.1 Sol at medium effort.
Long agentic coding sessions, code review, careful long-form writing → Claude Opus 5.5.
The hardest reasoning tasks → run both at max effort on twenty real examples before you commit.
You need a direct contract with OpenAI or Anthropic, such as zero data retention or a regulated-industry agreement → call the vendor directly, not a gateway.

About apimodels.app

apimodels.app is a multi-model API gateway: one key and one OpenAI-compatible endpoint for 140+ image, video, audio and language models. When an upstream channel fails, requests switch to another channel automatically, failed calls are not charged, and long-running jobs can report back through async callbacks. On price, on 1 October 2026 it lists Claude Opus 5.5 at $2.40 / $12 per 1M tokens, 40% below Anthropic's list, and GPT-6.1 Sol at $1 / $5, half of OpenAI's list, billed per token. It is not the right choice if you only ever call one model and already have the vendor's SDK and contract in place.

Which prompts in your own workload flip between the two models? I'd like to hear where your results disagree with the launch tables.

We Replaced a 2,300-Character Image Prompt With One Sentence

Super Lewis — Sun, 27 Sep 2026 02:02:56 +0000

Our prompt for making AI images look real used to be 2,300 characters long. It listed every AI tell to remove, every camera detail to add, and rules for colour, shadows and lens optics. It produced faces covered in freckles and skin so drained it looked like a corpse. The version in production today is one sentence.

The lesson generalises to any image-editing prompt: a modern image model already knows what a phone photo looks like, so naming a familiar camera does the work of a page of instructions, and every extra clause is something the model can over-apply.

sparkpix.ai's AI Image Humanizer is a web tool that re-renders an AI-generated image so it reads like a real phone-camera photo, keeping pose and framing. Disclosure: I build sparkpix.ai. This post was drafted with AI assistance for structure and wording; the prompt text, comments and code are from the sparkpix codebase (Next.js App Router on Vercel, calling GPT Image 2 through apimodels.app, September 2026).

Long prompts fail by arguing with themselves

Every clause in the long prompt was added to fix a problem the previous clause created. "Add natural skin texture" produced freckles; "don't add freckles" produced flat skin; "keep healthy colour" fought "remove the saturated AI grade". The model obeyed every clause a little too hard, and the clauses pulled against each other.

What replaced it, tested directly against GPT Image 2 and preferred by eye on 2026-07-30:

export const DE_AI_PROMPT =
  'Remove the AI-generated look from this image so it looks natural — for a ' +
  'photographic image, like it was taken with an iPhone 12 camera. Keep the ' +
  'original art style: an illustration or anime image must stay an ' +
  'illustration, not become a photograph.'

"Like it was taken with an iPhone 12 camera" carries the sensor noise, the colour science, the skin rendering and the slightly imperfect light, all at once, because the model has seen millions of those photos. There is no clause left to over-apply.

One word can change the subject instead of the camera

We tried "selfie" in that sentence, and it re-posed people. "Selfie" does not only describe a camera; it describes a photo genre: arm raised, head tilted, shot close and from above. The model read it as an instruction about the person and changed the pose the user had already chosen.

The rule we took from it: name the device, never the genre. "iPhone 12 camera" is about the lens. "Selfie", "portrait shot", "street photo" are about the picture, and the model will happily give you a new picture.

Scope a style instruction, don't negate it

The unscoped sentence, "make it look like an iPhone photo", is also an instruction to convert the medium, and anime uploads started coming back as photographs. The model was doing exactly what it was told.

The tempting fix is to append "do not change the art style". That recreates the original failure: two clauses arguing. Instead, the camera reference is scoped to photographic input ("for a photographic image, like it was taken with…"), and the second sentence adds a constraint rather than a contradiction.

Honest status: the scoped version has not been through the same side-by-side test as the one-sentence version. It is in production because it fixed the anime-to-photo reports, not because it was benchmarked.

Keep the prompt in exactly one place

The first time we shortened the prompt, nothing changed for real users. The wording lived in three places: two tool defaults on the server, and a pre-filled textarea on each landing page. The landing-page copy is what actually reached the model, because the editor sends its textarea as prompt and the server only falls back to its default when prompt is empty. We had edited the fallback.

Now there is one exported constant, imported by both the tool config and the pages, and the old long prompt is not kept as a "fallback", because an unused second copy is how the drift started. It is in git history if anyone needs it.

Failures must refund exactly once

A humanizer call can fail after credits are taken: the model's safety filter refuses the image, or the upstream API errors. The refund has to happen once, even though a failure can be observed by several code paths (the background job, a client poll, a cleanup cron). The pattern is to let the database decide who gets to refund:

const failAndRefund = async (errorMessage: string) => {
  const result = await query(
    `UPDATE generations SET status = 'failed', error_message = $1
     WHERE id = $2 AND status = 'processing'`,
    [errorMessage.substring(0, 500), generationId],
  )
  if (result.rowCount && result.rowCount > 0) {
    await addCredits(userId, creditsCharged)
  }
}

Only the caller whose UPDATE actually flips the row from processing to failed sees rowCount > 0, so only that caller refunds. A SELECT followed by an UPDATE looks equivalent and is not: two pollers can both read processing before either writes. We learned that the expensive way, with a polling endpoint that refunded the same failure on every poll.

Where this approach falls short

A one-sentence prompt gives the user no dial. If you need to control grain strength or skin detail per image, a slider-based tool is the better fit. A generative re-render can also shift very fine details, and GPT Image 2's safety filter refused about 1 in 20 of these requests in early September 2026, which is why the refund path matters.

FAQ

Why an iPhone 12 and not the latest model? Nothing magic; it is a very common, well-represented camera. Users do edit it: we see iPhone 13 to 17 in their prompts.

Does naming a camera work with other models? We only tested GPT Image 2. The idea, naming a familiar device instead of describing its output, should transfer, but test it.

Why not just add grain in post? Grain fixes the surface only. Plastic lighting, colour grades and over-smooth skin are structural, and a texture overlay cannot touch them.

The tool is at sparkpix.ai/ai-image-humanizer, 5 credits per image with the first image free. For how it compares with nine other tools, see Best AI Image Humanizers in 2026.

How to Read C2PA and IPTC AI Labels From Image Bytes in Node.js

Super Lewis — Sat, 26 Sep 2026 14:42:19 +0000

Most AI images carry a note from the tool that made them, and you can read it with about 60 lines of TypeScript. The hard part is not parsing it; it is knowing what its absence means, which is nothing at all.

sparkpix.ai's AI Image Detector is a web tool that estimates whether an image was AI-generated by reading provenance labels in the file first and then scoring the pixels. This post walks through how the first layer works in Node.js, how the two layers combine into a verdict, and the one upload bug that silently deletes the evidence.

Disclosure: I build sparkpix.ai and apimodels.app, and both appear below. This post was drafted with AI assistance for structure and wording; the code is from the sparkpix codebase (Next.js App Router, Node 24, September 2026).

Two kinds of label live inside AI images

AI tools write provenance into the file in two standard ways, and a detector should look for both.

C2PA Content Credentials. A signed manifest, defined by the Coalition for Content Provenance and Authenticity, that records which tool produced the file and what was done to it. OpenAI, Adobe Firefly and Microsoft embed one. It sits in a JUMBF box: JPEG APP11 segments, a caBX chunk in PNG, a C2PA chunk in WebP.
IPTC Digital Source Type. An XMP field whose value trainedAlgorithmicMedia means "created by a generative model" and compositeWithTrainedAlgorithmicMedia means "edited with one". Google writes it into Gemini and Imagen images, and C2PA action assertions reuse the same vocabulary.

When either is present, the question is settled: the maker declared it.

A byte scan is enough to detect presence

You do not need a full C2PA validator to answer "does this file claim to be AI?". We deliberately scan bytes and report presence plus the claimed generator, not signature validity:

export function readMetadataSignals(buf: Buffer): MetadataSignals {
  const latin = buf.toString('latin1')
  const c2pa =
    (latin.includes('jumb') && latin.includes('c2pa')) ||
    latin.includes('caBX') ||
    /C2PA[\s\S]{0,8}jumb/.test(latin)
  const composite = latin.includes('compositeWithTrainedAlgorithmicMedia')
  const generated = !composite && latin.includes('trainedAlgorithmicMedia')
  let generator = c2pa ? claimGenerator(buf) : null
  if (!generator && /Made with Google AI/i.test(latin)) generator = 'Google AI'
  return { c2pa, generator, aiSource: composite ? 'composite' : generated ? 'generated' : null }
}

Note the order of the two IPTC checks: compositeWithTrainedAlgorithmicMedia contains trainedAlgorithmicMedia as a substring, so the composite test has to run first or every AI-edited photo reads as fully generated.

The generator name comes from the C2PA claim, which is CBOR. Newer (v2) claims store it as claim_generator_info: [{ name: "ChatGPT" }]; older (v1) claims use a single claim_generator string such as Adobe_Photoshop/25.0 adobe_c2pa/0.7.6. Reading a CBOR text string by hand is a few lines, because the first byte tells you the length:

function readCborText(buf: Buffer, at: number): string | null {
  const b = buf[at]
  let len = -1
  let start = at + 1
  if (b >= 0x60 && b <= 0x77) len = b - 0x60      // length in the type byte
  else if (b === 0x78) { len = buf[at + 1]; start = at + 2 }            // 1-byte length
  else if (b === 0x79) { len = buf.readUInt16BE(at + 1); start = at + 3 } // 2-byte length
  if (len <= 0 || len > 200 || start + len > buf.length) return null
  return buf.toString('utf8', start, start + len)
}

What this does not do: it does not verify the signature, so a forged manifest would pass. For "is this probably AI?" that is an acceptable trade; for legal provenance, use the official c2pa-rs or c2pa-node libraries.

Your upload pipeline may be deleting the evidence

The most common reason a detector finds no label is that your own code stripped it. Our site compresses every upload in the browser and re-encodes it to WebP before sending it to storage, which is right for an image editor and fatal for a detector: re-encoding drops the metadata segments where both labels live. The detector's upload path skips that optimizer for any file up to 10 MB and stores it byte-for-byte; larger files still get compressed, and the user is told the metadata check may miss.

Social platforms and chat apps do the same thing to everyone, and a screenshot creates a brand-new file. That is why a missing label proves nothing, and why a second layer is needed.

The second layer scores the pixels

When there is no label, a classifier looks at texture, noise and structure. We call an external model for this, apimodels.app's ai-image-detector (POST /v1/images/detections, synchronous, about $0.015 per image), which also reads C2PA itself and returns a 0-1 score:

Upload is stored unmodified, then two checks run.
Byte scan for C2PA and IPTC labels. If IPTC says generated, the verdict is AI Generated (99%+); if it says composite, Digitally Edited.
Otherwise the pixel classifier's score picks the band: 85-100 AI Generated, 60-84 Likely AI, 40-59 Uncertain, 16-39 Likely Real, 0-15 Real Photo.

A metadata declaration always wins over the pixel score, because it is the maker's own statement. Without either signal, the endpoint refuses to guess: if the classifier is down and the file has no label, the user gets an error and their credits back, not a made-up "Uncertain".

How accurate is it?

On our own set of 28 images, 14 AI images from GPT Image 2 and Gemini plus the 14 real photos they were modelled on, the combined detector got 27 right: no real photo was flagged and one AI image passed as real. Calls took 1.6 to 3.1 seconds. The classifier returned near-binary scores (0.99 or 0.001), and it named the generator on none of the 28, so attribution is best-effort.

That test is small and covers two generators. Don't read it as a benchmark.

When not to build this

If you need provenance that stands up in court or in a newsroom's publishing workflow, a byte scan is the wrong tool: use a real C2PA validator that checks signatures and the trust list. And if your images come from social media, skip the metadata layer's expectations entirely; almost everything will arrive stripped.

FAQ

Can I detect AI images without calling any API? Partly. The metadata layer is free and local, and it is decisive when a label exists. It answers nothing for stripped files, which is most images shared online.

Does SynthID show up in this scan? No. Google's SynthID is an invisible watermark in the pixels, not a metadata field, and there is no public API to read it.

Why is 40-59% labelled "Uncertain" instead of a lean? Because a classifier score near the middle carries almost no information, and presenting it as "slightly AI" invites people to act on noise.

Try the detector at sparkpix.ai/ai-image-detector. For the non-code version, including reverse image search and visual checks, see How to Tell If an Image Is AI-Generated.

We Replaced a 2,300-Character Image Prompt With One Sentence

Super Lewis — Sat, 26 Sep 2026 14:41:17 +0000

Long prompts fail by arguing with themselves

What replaced it, tested directly against GPT Image 2 and preferred by eye on 2026-07-30:

export const DE_AI_PROMPT =
  'Remove the AI-generated look from this image so it looks natural — for a ' +
  'photographic image, like it was taken with an iPhone 12 camera. Keep the ' +
  'original art style: an illustration or anime image must stay an ' +
  'illustration, not become a photograph.'

One word can change the subject instead of the camera

Scope a style instruction, don't negate it

Keep the prompt in exactly one place

Failures must refund exactly once

const failAndRefund = async (errorMessage: string) => {
  const result = await query(
    `UPDATE generations SET status = 'failed', error_message = $1
     WHERE id = $2 AND status = 'processing'`,
    [errorMessage.substring(0, 500), generationId],
  )
  if (result.rowCount && result.rowCount > 0) {
    await addCredits(userId, creditsCharged)
  }
}

Where this approach falls short

FAQ

Why an iPhone 12 and not the latest model? Nothing magic; it is a very common, well-represented camera. Users do edit it: we see iPhone 13 to 17 in their prompts.

Does naming a camera work with other models? We only tested GPT Image 2. The idea, naming a familiar device instead of describing its output, should transfer, but test it.

Why not just add grain in post? Grain fixes the surface only. Plastic lighting, colour grades and over-smooth skin are structural, and a texture overlay cannot touch them.

The tool is at sparkpix.ai/ai-image-humanizer, 5 credits per image with the first image free. For how it compares with nine other tools, see Best AI Image Humanizers in 2026.

14,000 production calls later: image and video APIs fail in two opposite ways

Super Lewis — Mon, 21 Sep 2026 14:19:54 +0000

Media generation endpoints fail in two ways that look identical in your logs and need opposite handling. One is a content filter refusing the prompt, which no amount of retrying will fix. The other is a saturated GPU pool, which almost always clears within seconds. If you lump them into one catch block, you will both burn money retrying rejected prompts and give up on requests that would have succeeded.

I pulled the numbers to see how the split actually falls, across 14,069 image and video generations over 30 days. The ratio is not close, and it inverts completely between the two media types. Disclosure up front: the data is from apimodels.app, which is the API platform I work on, so treat it as one operator's dataset rather than an industry benchmark. Everything below is written so you can run the same measurement against whatever provider you use.

The split

The two tiers and the video model below are the same three models the code at the end calls. For image generation, content rejections were 90% of all failures. For video generation on the same platform in the same window, they were 4%.

                        content  capacity  timeout  upstream  bad input
image model, fast tier      823        17       29        20         24
image model, detail tier    232        69       44        16         14
video model                   2        31        3          9         6

Turned into rates against total calls, the picture is sharper:

model                calls   success   infra failures   p50      p90
image, fast tier    10,149     91.0%            0.65%   40.1s    71.2s
image, detail tier   3,630     89.7%            3.55%   52.0s   135.9s
video                  290     82.4%           14.83%   36.5s   104.1s

The fast image tier looks unreliable at 91% success and is not. Strip out the prompts a filter refused and actual infrastructure failure is 66 calls in 10,149. Meanwhile the video model, which looks worse at 82.4%, has essentially no content problem at all: it failed 43 times because capacity was not there.

That inversion has a boring physical cause. Image inference finishes in tens of seconds and the filters sit on a text prompt, which users write freely and sometimes carelessly. Video inference holds a GPU for a minute or more, so pools saturate under load and "come back later" is a normal operating state rather than an incident. Any provider running the same hardware economics will show some version of this shape.

One honest caveat on my own numbers: these models are served through more than one upstream provider, so the capacity column partly reflects routing between them rather than a single vendor's raw availability. Your numbers against a single-vendor API will look different in magnitude. The two-class split is the part that transfers.

Measure it on your own provider

You need failures bucketed into "the user can fix this" and "time can fix this", and most APIs will not hand you that distinction. They return a 4xx or 5xx and a message string.

The mapping that has held up for us is three buckets, not two, because the third one is the one that wakes people up at night:

function classify(status, message) {
  const m = (message || "").toLowerCase();

  // The user can fix this. Never retry. Show them the provider's own wording.
  if (/safety|content policy|moderation|nsfw|prohibited|violat/.test(m)) return "CONTENT";
  if (status === 400 || /invalid|unsupported|too large|must be/.test(m)) return "BAD_INPUT";

  // Time can fix this. Retry with backoff.
  if (status === 429 || /busy|capacity|overload|rate limit|try again/.test(m)) return "CAPACITY";
  if (status >= 500 || /timeout|timed out|econnreset|gateway/.test(m)) return "TRANSIENT";

  // Nobody knows yet. This is the bucket you alert on.
  return "UNKNOWN";
}

Alert on the size of UNKNOWN, not on your overall error rate. A rising UNKNOWN means the provider changed their error wording and your retry logic has quietly stopped working. A rising CONTENT means your users changed, or someone shipped a prompt template that trips a filter, and no amount of infrastructure work will help.

I am not going to pretend this regex table is elegant. It is hand-maintained, it drifts, and every provider that collapses both classes into a generic 500 Internal Error makes it worse. It is still better than one retry policy for everything.

The retry loop the split implies

Retry capacity and transient failures with exponential backoff, and fail content rejections immediately with the message attached.

const RETRYABLE = new Set(["CAPACITY", "TRANSIENT"]);

async function generate(body, tries = 3) {
  for (let i = 0; i < tries; i++) {
    const res = await submitAndPoll(body);
    if (res.ok) return res;

    const bucket = classify(res.status, res.message);
    if (!RETRYABLE.has(bucket)) throw new UserFacingError(bucket, res.message);
    await sleep(2 ** i * 2000); // 2s, 4s, 8s
  }
  throw new Error("still failing after retries");
}

Three attempts at 2/4/8 seconds covers the capacity failures we see, because a saturated pool usually has a slot within ten seconds. Do not push this to ten attempts; if a pool is still full after fifteen seconds it is having a real incident and you want to fail visibly rather than pile on.

Surface content rejections immediately, with the provider's own wording. It is the one failure class a human can act on, and hiding it behind a spinner that retries three times means the user waits thirty seconds to find out their prompt was the problem.

The pipeline these numbers came from

The workload was a two-call pipeline: generate a still frame, then hand that frame to a video model as its first frame. Almost every hosted media API uses the same asynchronous shape, so the structure ports even though the field names will not.

Runtime for everything below: Node 24.19 with the built-in fetch, no SDK. Measurements taken 2026-09-20 over the preceding 30 days.

const BASE = process.env.MEDIA_API_BASE;   // swap for your provider
const HEAD = {
  Authorization: `Bearer ${process.env.API_KEY}`,
  "Content-Type": "application/json",
};

// 1. still frame
const img = await post(`${BASE}/images/generations`, {
  model: "gpt-image-2.5-flare",
  prompt: "a minimalist oak desk with a laptop showing a blue analytics dashboard, soft morning window light",
  aspect_ratio: "16:9",
  resolution: "1K",
  quality: "low",
});
const frame = await poll(`${BASE}/images/generations`, img.data.taskId);

// 2. animate it
const vid = await post(`${BASE}/video/generations`, {
  model: "grok-imagine-video-1.5",
  images: [frame],          // array, even for a single reference
  prompt: "slow push-in on the laptop screen, dust motes in the light",
  duration: 5,
  resolution: "720p",
});

You POST, get a task id, and poll until the state is terminal. A synchronous-looking wrapper around a 40-second median will time out somewhere in your stack, usually at a proxy you forgot about.

That still frame cost $0.008 and took 37 seconds.

The delivered size was 1672x941, not the 1920x1080 a 16:9 request implies. Image models snap dimensions to whatever grid their tiler uses; if a downstream step needs exact pixels, resize after generation rather than trusting the request.

The economics push one way: iterate on the still image, not on the clip. A second of 720p video cost more than six times the entire still frame, so refining motion when the real problem is the composition in frame one is the expensive mistake.

Three things that cost me time

The poll parameter was task_id while the create response returned taskId. A poll loop that returns an empty object for eight minutes rather than erroring is a genuinely miserable debugging session, and snake case versus camel case across create and read is common enough to check first.

Result files expire. Seven days on this platform, and every hosted media API has some version of it. Download to your own storage in the job that created the file, not in a nightly batch that will eventually run against dead URLs.

Billing lands on success. That is good for the bill and confusing for reconciliation, because a task that burned real GPU time upstream and then failed shows as free to you. Do not reconcile spend against request counts.

When not to do this at all

Do not generate when you need the same output twice. Seeds help and do not survive model version changes, so if your product promises a user that what they saved last month still looks the same, generate once and store the file. Treat the model as a source of assets, not a renderer you can call again.

Skip generation entirely for exact text inside an image. Every model in this class still garbles multi-word text at small sizes, and composing type in SVG over a generated background is more reliable than rolling dice on a headline.

And if your failure volume is low enough that you would never notice a 3% difference, skip the classifier too. It earns its keep somewhere north of a few thousand calls a month; below that, a single retry and a clear error message is the correct amount of engineering.

What I would like to know

If you run generation in production, how are you separating these two classes? I am specifically curious about providers that return a bare 500 for both, because the regex table above is the part of our stack I would most like to delete.

$30 to $8,880/mo in Six Months: How a PM Who Can't Code Runs an API Gateway Doing 300K Calls a Month

Super Lewis — Sat, 29 Aug 2026 04:10:49 +0000

I'm a product manager. I can't write code — not "I'm rusty," not "I know some Python." I cannot write the code that runs my business.

Six months ago my product made $30.32. This month it made $8,880. I have never paid for a click.

The numbers first

Revenue, straight out of the production database, admin accounts excluded:

Month	Revenue	Paying customers
2026-03	$30.32	3
2026-04	$230	3
2026-05	$460	9
2026-06	$2,410	33
2026-07	$6,730	63
2026-08	$8,880	127

293x in six months. Trailing 30 days is $9,180 — so no, I haven't crossed $10k/month yet. September probably. I'd rather publish the real number than a rounder one.

On the system side:

August: 299,668 API calls at a 95.5% success rate
Excluding content-moderation rejections — a customer's prompt refused upstream, not my system failing — it's 98.9%
From July to August, volume grew 2.6x (116k → 300k calls) while the success rate went from 93.9% to 98.9%

Volume nearly tripled and stability went up. That last line says more than the success rate on its own.

But a success rate can lie to you — in a minute I'll show you exactly how it lied to me. The number I actually trust: only 20 customers have ever topped up in more than one month, and they account for 70.8% of all revenue I've made. Heavy users renewing month after month is the one stability proof that can't be faked. Nobody keeps paying for an API that isn't good.

The product is apimodels.app: one API key for 182 AI models — image, video, audio, and LLMs — behind a single OpenAI-compatible interface. Every line of it was written by an AI coding agent working under my direction.

How does someone who can't write code run this?

It's the question I get most. The answer has four layers, and the first one matters more than the rest combined.

1. This business has exactly two product cores

Nobody picks a model aggregator because the UI is nice, the feature list is long, or the model catalog is big. They pick you for two reasons: the same model is cheaper here, and you don't fall over.

That's the whole list. Everything else is decoration.

Get the core right and the product follows. That sounds like a truism. The operational meaning is sharper: every hour you have should go into those two things, and you need to know, at all times, whether you're cheating on one of them.

Because they will lie to each other. Here's the time I nearly got away with cheating on "cheaper."

2. Official model channels only — a rule I paid for in customers

Early on I wired up a very cheap upstream for a popular video model. Cheap enough that the margin looked absurd.

Then I noticed something no dashboard flagged: several users tried it once and never came back.

No errors. No failed calls. Every request returned 200.

So I ran the same prompt through the official channel and put the two clips side by side. It was watered down. Almost certainly a lower resolution upscaled and delivered as the higher one — or the cheap tier being passed off as the premium tier.

That upstream wasn't failing. It was substituting. Every request "succeeded," my error rate was immaculate, and my retention was dying.

That's when the rule got written, and it hasn't been broken since: official model channels only. Never a reseller priced far below the market.

If something is cheap in a way that seems impossible, it is guaranteed to be both unstable and quality-compromised. There's no third explanation — somebody has to pay for the GPU, and if it isn't you, it's coming out of what you receive.

So "cheap" as a product core needs restating. It isn't cheapest possible. It's the lowest price at a quality level you have actually verified. Undercut that line and you haven't won a customer — you've rented one for a single call.

And notice which instrument caught it: not the error rate. Retention. Silent quality degradation is invisible to every monitor you have. The only thing that reveals it is whether people come back.

3. Everything built in-house — no open-source gateway

There are several good open-source API gateways. You can be running on one in a day. I used none of them.

The reason is simple: price and stability both live in the same layer of code — the forwarding logic between the customer's request and the upstream model. That layer is exactly what an off-the-shelf gateway occupies.

When a failure lives inside a dependency, your move is to file an issue and wait. When it lives in your own code, you fix it that afternoon. At 300,000 calls a month, the gap between those two response times is the product.

Much slower to start. And the only way to actually control the two things customers are paying for.

As for how the success rate got from 93.9% to 98.9%: every mechanism in this system exists because of a specific production failure. Not one of them was designed up front. "Polishing," in plain language, means something breaks, you understand it, you turn it into a rule that stops it recurring, and then you do that three hundred times. There's no shortcut version — and it happens to be work a non-coder can do.

4. What I own isn't the code. It's defining what counts as evidence.

The most misunderstood part: this is not "the AI writes it and I click deploy."

If that's your loop, you'll ship something that appears to work and quietly does the wrong thing, and you'll hear about it from a customer.

The agent generates. I define what counts as evidence that it works. Four rules, each one written down because breaking it cost me money:

Never deploy automatically. Test locally, show me the result, I say OK, then commit. No exceptions, no "this one's trivial."

"Test it" means test it. Not test-and-then-fix-what-you-found. When I ask for a diagnosis I want the diagnosis — a fix applied before I understand the problem is a fix I can't evaluate.

A deploy succeeded only if the code running on the server equals the version I pushed. Not if the command printed no errors. I lost a full day to a deploy that reported success at every step while the server ran week-old code.

Verify against production data, never against a summary of production data. "I checked and there were no errors" and "here is the query and here are the zero rows" are completely different claims.

None of these require reading code. They require refusing to accept confidence as evidence — which turns out to be a product skill, not an engineering one.

The bottleneck in AI-assisted development was never code generation. It's verification. And verification is exactly the part a non-coding PM can own completely.

Then three things I got wrong

My free tier couldn't afford a single call

New users got $0.10 in signup credit. The video models my content pushed hardest cost between $0.89 and $2.66 per successful call.

A new user signs up, lands on the page my SEO worked hardest to rank, tries the thing that page is about, and gets rejected for insufficient balance. Their first experience of my product is a billing error.

The obvious fix is raising the credit. I almost did. Then I sorted every model by actual per-call spend instead of by how much I liked it, and two things stopped me cold:

veo-3.1-fast-fhd: $0.0684 per clip — 1080p, native audio. $0.10 covers it with change.
gpt-image-2-lite: $0.0078 per image. The same $0.10 buys twelve pictures.

So the free tier was never too small. It was perfectly adequate for a path no new user was ever shown. I'd built a funnel that took strangers by the hand and walked them into the most expensive thing I sell.

A free tier isn't a generosity number. It's the answer to one question: can a brand-new user complete one full happy path with it? If not, you have two levers, and raising the credit is the expensive one.

Never build a product page for a model you can't actually call

To go after a new model's search terms, the instinct is to put the page up first.

But that reads as a claim that you offer it. The API will 400 every time, and the specs and prices can only be invented. Worse — you've fed a false fact to the LLMs, and it gets cemented. By the time you really launch, the version in their heads is still the one you made up.

The right move is an honest placeholder: state plainly it isn't open yet, show how you verified that, promise it the day it launches, and put a working neighboring model in the code sample. Honest pages rank fine, and they leave no debt.

In an era where AI remembers what you said, this only gets more important.

Healthy SEO metrics and a working product are independent

Two of my flagship model pages failed on every single call because of a config error — for ten days, and nobody noticed.

Because the page status was active, it was indexed normally, and Search Console kept right on reporting impressions and clicks. Those metrics measure "the page exists and got crawled." None of them measures "the person who clicked could use it." If GSC is your only dashboard, everything looks great.

This and the watered-down upstream are the same disease: your dashboards will show everything is fine while the product rots. The only cure is finding one metric that can't lie. For me that's retention.

One thing I still haven't gotten right

I've never bought a click. That I can prove.

The only acquisition work I've done is content: 1,204 indexable pages across 7 languages, a page for every model. I believe the traffic comes from search and LLM citations, because it's the only thing I've ever done.

But I have to say this out loud: I can't prove it.

There is no analytics on my site. No Google Analytics, no Plausible, no PostHog. My user table has a registration IP and a timestamp and no source field of any kind.

My largest customer paid $3,000 in August. I do not know how they found me. Not which page, not which query, not which language. I know their invoice total and nothing else.

Install analytics on day one, and add a first-touch source column to your user table on day one. Not because you'll read the dashboard — you won't, for months. Because on the day you finally have revenue worth explaining, the data either exists or it doesn't. It cannot be backfilled. Ever.

It's the biggest mistake I've made, and it's the one that looks least urgent while you're making it.

About apimodels.app

One API key for 182 AI models — image, video, audio, and LLMs — through an OpenAI-compatible interface, with no separate signups or quota applications per vendor.

Image generation from $0.0078 per image
1080p video with native audio from $0.0684 per clip
299,668 calls served in August 2026 at a 95.5% success rate
Official model channels only — no resellers priced far below market
Interface and docs in English, Chinese, Japanese, Korean, Spanish, Portuguese, and Russian

Every figure here is queried straight from production. Happy to answer anything in the comments.

The Seedance 2.5 Prompting Guide, in English

Super Lewis — Wed, 05 Aug 2026 15:16:24 +0000

Cross-posted from apimodels.app — the canonical version lives there and is kept up to date.

If you have only ever prompted image models, video models feel like a different instrument. You are no longer describing a frame; you are directing time, camera and sound at once, and the failure modes are unfamiliar — subjects that duplicate halfway through, props that change hands, edits that quietly re-roll the whole shot.

ByteDance released Seedance 2.5 on 31 July 2026 and, unusually, shipped a real prompting manual with it, written by the people who trained the model. It is specific in the way vendor docs rarely are: how many reference assets it accepts, how to address each one, how to stage a 30-second clip so it does not collapse, how to change one object in existing footage without disturbing anything else, and a blunt list of nine things it will not do.

This is that manual walked through in English with every template kept. The limits, syntax and stated boundaries are ByteDance's; the worked examples are mine, written to be copy-pasted rather than translated.

Contents

1. Foundations
2. The techniques that matter
3. Advanced usage
4. Checklist before you submit
5. What it will not do
Running these prompts today

1. Foundations

1.1 The base formula

A prompt is assembled from six parts. Only the first two are required; drop any of the rest that you do not need.

FORMULA

subject + action or event
  + scene and environment    (optional)
  + visual style             (optional)
  + camera work or cutting   (optional)
  + sound                    (optional)

What each part is responsible for:

Subject + action or event — who or what is doing what. This is the floor of the whole prompt. Summarise the main process first; add concrete detail only for the key action; never describe the same action twice.

Scene and environment — place, time, weather, spatial relationships, state of the background.

Visual style — light, colour, material, image texture, overall mood.

Camera work or cutting — shot size, camera position, movement, focus target, how shots join.

Sound — dialogue, timbre, ambience, effects, music.

TEMPLATE

<SUBJECT> <main action or event> in <scene and environment>.
The image is <visual style>.
The camera uses <shot size, position, movement or cutting>.
Sound includes <dialogue, ambience, effects or music>.

EXAMPLE

A luthier finishes a violin in a narrow workshop, lifting the body off
the bench and setting it upright in the drying rack.

Late afternoon light rakes through fine sawdust; fresh varnish shows a
deep amber, the bench is orderly, tools laid out in a worn leather roll.

The camera opens on a medium shot of the hands releasing the clamp, then
pushes slowly in on the grain of the top plate, then cuts to the rack
seen straight on.

Keep the scrape of the plane, the click of the clamp, and quiet room tone.

Generation parameters do not belong in the prompt. Resolution, duration and aspect ratio are set on the generation page or through the API.

1.2 With reference assets: prepare them, then assign roles

You can combine up to 50 reference assets in one job. Each type has a hard input range and a narrower recommended range; the recommended range exists to raise stability and is not a statement about capability.

LIMITS

Images    input range   up to 30, each no larger than 4K
          recommended   1-8 subjects

Video     input range   up to 10 clips, 30s total across all clips
          recommended   1-5 subjects, 5-10s per clip

Audio     input range   up to 10 clips, 30s total across all clips
          recommended   keep only dialogue, timbre, ambience or music
                        that the task actually needs

Editing   input range   source video plus reference images together
          recommended   source under 20s, 1-5 reference images

You may go beyond the recommended range: image subjects can extend to 9-12, audio/video subjects to 6-10, editing reference images to 6-8. The guide is blunt about the trade-off — the more assets, the more easily stability drops.

When a subject needs more than five image references and still needs multiple viewpoints, split the viewpoints across separate images. Several independent view images are usually more stable than several views packed into one grid.

Assign a role to every asset. After uploading, state what each asset supplies. When a person, background or composition inside an asset is likely to bleed into the result, also state what not to take from it.

The mapping between assets and subjects must be written into the prompt. Do not rely on text labels burned into the image, and do not leave the model to work out which asset corresponds to which person, prop or scene.

TEMPLATE — asset roles

@image1 supplies <subject>'s <appearance, clothing, structure or material>.
@video1 supplies <action, camera movement or rhythm>.
@audio1 supplies <character or sound type>'s <timbre, dialogue,
        ambience or music>.

<SUBJECT> completes <main action or event> in <scene>.
The image is <visual style>; the camera uses <camera expression>.

EXAMPLE

@image1 supplies <BAKER>'s features, hair and flour-dusted grey apron.
        Do not take the background.
@image2 supplies <BAKERY>'s counter layout, tiled wall and window
        position. Do not take the people in the frame.
@video1 supplies the rhythm of shaping the dough, lifting it and sliding
        the tray in. Do not take the person's identity, clothing or room.

<BAKER> shapes a sourdough loaf in <BAKERY> and slides it into the deck
oven.

The camera records the shaping in a medium shot, then pushes slowly in on
the crust; keep the scrape of the peel, the oven door, and room tone.

When several images are different viewpoints of the same person or product, say so explicitly, and state how many of the object should exist in the result.

EXAMPLE — multiple viewpoints

@image1 defines the front of the same folding lamp.
@image2 defines its left-side structure.
@image3 defines its right-side structure.
@image4 defines its back structure.

The four images together define one single folding lamp; there is only
ever one folding lamp in the finished video.

When a reference video already carries the action, camera work and ordering accurately, the prompt only needs to say what it inherits — do not restate the choreography move by move. Restating it invites a conflict with the asset itself.

A white-box video mainly supplies motion and a spatial skeleton. You still have to write out the subject, scene, action and style you want generated.

1.3 Special characters for sound and text

Natural language works on its own. When you need to separate music, effects, dialogue and on-screen text, four bracket types disambiguate them.

SYNTAX

Music       ( )     (calm piano plays underneath)
Sound fx    < >     <a bell rings in the distance>
Dialogue    { }     {Hello, welcome back}
Subtitle    【 】    【Chapter One: Departure】

To control subtitles or audio, simply write which sound categories to keep and which not to use. Picture content should still be written as positive description — only asset roles, edit scope, and things likely to bleed in need explicit prohibition.

EXAMPLE

No background music; keep only dialogue, ambience and action effects.
No subtitles.
No audio at all.

Reinforcing the dialogue language. When a line is not in Chinese, name the language before it:

The girl says softly in Japanese: {もう大丈夫です}

When the line text is English but the model speaks it in Chinese, or when you need to control a regional variety, be more specific. The recommended formula:

FORMULA

dialogue language + regional variant or accent + delivery
  + speaker + {line}

EXAMPLE

Dialogue language: American English. The girl says it naturally and
colloquially: {I thought you weren't coming.}

Dialogue language: native Los Angeles American English. A young man says
it in natural LA speech: {No way, you actually made it.}

2. The techniques that matter

2.1 Multi-asset work: tell the model which asset each scene uses

Images, video and audio can be combined. Once there are many assets, the job of the prompt is not to cram them all into one sentence — it is to make the correspondence between people, props, scenes, actions and sound unambiguous. Organise it in this order:

ORDER

per-asset roles → subject mapping → grouping by type
  → subject specification → per-scene invocation

Step 01 — name each subject individually. Different people, products and props each get their own binding.

<PERSON A> corresponds to @image1; take appearance, hair and clothing only.
<PERSON B> corresponds to @image2; take appearance, hair and clothing only.
<PROP A>   corresponds to @image3; take structure, material and colour only.
<SCENE A>  references @image4; take spatial layout, architecture and light
           only, not the people in the frame.

Do not write "@image1 through @image4 define four characters". That never says which image is which character.

Step 02 — group the assets by type.

[PEOPLE]
<CONSERVATOR> corresponds to @image1; appearance, hair, clothing only.
<REGISTRAR>   corresponds to @image2; appearance, hair, clothing only.
<INSTALLER>   corresponds to @image3; appearance, hair, clothing only.
<DOCENT>      corresponds to @image4; appearance, hair, clothing only.
The four do not exchange appearance, clothing, actions, positions or lines.

[PROPS]
<SAMPLE BOX>   corresponds to @image5; belongs to <CONSERVATOR> only.
<RECORD BOARD> corresponds to @image6; belongs to <REGISTRAR> only.

[SCENES]
<LAB>     references @image7; space, materials and light only.
<GALLERY> references @image8; space, materials and light only.

[ACTION AND SOUND]
@video1 supplies <CONSERVATOR> opening the sample box; do not take the
        person or the room from it.
@audio1 supplies <DOCENT>'s timbre and the specified line.

Step 03 — write a specification for an important subject. When one person is used across scenes with several assets, collect their definition in one block.

[SUBJECT SPEC: CONSERVATOR]
Appearance and clothing: @image1.
Fixed prop:              <SAMPLE BOX> from @image5.
Appears in:              <LAB> and <GALLERY>.
Action references:       the box-opening in @video1, the sample-placing
                         in @video2.
Do not:                  wear another character's clothing; hold the
                         <RECORD BOARD> or any presentation equipment.

Step 04 — invoke assets per scene. State what the scene uses, what happens, and the state at the end.

SCENE ONE | inspection in the lab
Uses:   <CONSERVATOR>, <SAMPLE BOX>, <LAB>, and the box-opening from @video1.
Event:  <CONSERVATOR> opens the sample box at the bench and inspects the
        sample inside.
Ends:   <CONSERVATOR> stands at the inner side of the bench; the sample box
        stays beside their own right hand, i.e. on the left of frame.

SCENE TWO | registration in the gallery
Uses:   <REGISTRAR>, <RECORD BOARD>, <GALLERY>.
Event:  <REGISTRAR> checks the numbers on the record board beside a case.
Ends:   the record board is still held in both hands by <REGISTRAR>; no
        other character enters the case area.

The goal of multi-asset work is for the model to pick the right asset in the current scene. It is not a requirement that every asset appears on screen at once.

2.2 Thirty-second video: organise events by stage and end state

When there are many events, break the story into consecutive stages. Give each stage exactly one main state change, and write the state that is directly visible on screen when that stage ends.

TEMPLATE — long video

[GOAL]
Generate a <video type>. The core subject is <subject>; the main event is
<story summary>.

[STAGE ONE]
Opens with:   <initial state of people, props and scene>.
Main event:   <one main action or event>.
Ends with:    <person position, prop ownership or picture state>.

[STAGE TWO]
Carried over: <state that must be preserved>.
Main event:   <one main action or event>.
Ends with:    <observable state>.

[STAGE THREE]
Main event:   <closing event>.
Ends with:    <final picture state>.

[KEEP CONSISTENT]
Keep <identity, headcount, clothing, prop ownership, spatial orientation
and sound relationships> stable.

EXAMPLE — florist order-packing walkthrough

[GOAL]
A walkthrough of a florist packing an order. <FLORIST> and <ASSISTANT>
together trim, wrap and hand off a bouquet.

[STAGE ONE]
Opens with:   <FLORIST> behind the bench; loose stems, shears and wrapping
              paper on the surface.
Main event:   <FLORIST> arranges the stems and trims them to length.
Ends with:    the bouquet is held in <FLORIST>'s left hand; the shears are
              back on the right side of the bench.

[STAGE TWO]
Carried over: both keep the same identity and clothing; the bouquet is
              still held by <FLORIST>.
Main event:   <ASSISTANT> unrolls the paper; <FLORIST> lays the bouquet in
              and ties a green ribbon.
Ends with:    the wrapped bouquet lies flat in the centre of the bench, the
              ribbon knot facing the camera.

[STAGE THREE]
Main event:   <ASSISTANT> lifts the bouquet onto the pickup shelf.
Ends with:    the bouquet is alone in the centre of the pickup shelf; both
              stand behind the bench looking at the finished order.

[KEEP CONSISTENT]
Keep <FLORIST> and <ASSISTANT>'s identities, clothing, the orientation of
the bench, the position of the shears and ownership of the bouquet stable.

Timestamps and pacing. For ordinary narrative, prefer stages. Reach for time expressions — in whole seconds — only when a handover, an entrance or exit, a transition or a specific beat needs control. Time ranges allocate story pacing; a time point pins one key event; relative time describes waiting between events.

EXAMPLE

0-5s:   an empty wooden display stand; a hand sets down a white ceramic
        plate; at the end the hand has left and only the white plate is
        on the stand.
5-10s:  the white plate is removed and a clear glass is set down; at the
        end only the clear glass is on the stand.
10-15s: the clear glass is removed and a green ceramic bottle is set down;
        at the end only the green bottle is on the stand.

Time range        0-3s … 3-7s … 7-12s …
Explicit point    At 5s the camera whips left and completes the transition.
Relative time     Three seconds after the button is pressed, the room
                  lights fade out.

Segments must be continuous and must not overlap. A segment is a time budget for an event, not a precise cut point — an action may land slightly before or after a boundary. Too little content in a segment widens the model's room to invent; too much causes over-cutting or dropped story beats. Do not use timestamps to demand a frequency such as three actions in one second.

2.3 Editing, first/last frame and extension: parameters that lock themselves

Video editing, first-frame or first-and-last-frame generation, and video extension automatically lock some generation parameters based on the input.

AUTO LOCK

Video editing
  aspect ratio   automatically keeps the input video's ratio; not settable
  duration       automatically stays essentially the same as the input;
                 not settable. Frame handling can produce a difference of
                 up to about 0.3 seconds.

First / first+last frame
  aspect ratio   automatically uses the first-frame image's ratio. First
                 and last frame should use the same ratio, otherwise the
                 last frame can be stretched.
  duration       settable

Video extension
  aspect ratio   automatically keeps the input video's ratio; not settable
  duration       settable

Locked parameters cannot be overridden on the generation page or through the API. Everything else follows the options currently available.

2.4 Video editing: declare the master, the scope, and what stays

When editing existing footage, first define the source as the sole master, then state the edit target, the scope it applies to, the target asset, and what must be preserved.

TEMPLATE — general edit

[EDIT GOAL]
Edit @video1; across <the whole clip or a specific time range>, perform
<add / remove / replace / adjust> on <picture object, region or sound
category>.

[SOURCE ROLE]
@video1 is the sole editing master, responsible for <people, scene,
action, composition, camera, occlusion relationships, sound and event
order>.

[TARGET ASSET ROLE]
@image1 or @audio1 supplies <the specified attributes of the target object
or sound>.

[EDIT SCOPE]
Process only <object, region, time range or sound category>.

[PRESERVE]
Keep <the picture, action, sound and timing relationships that must not
change> as in @video1.

EXAMPLE

[EDIT GOAL]
Edit @video1; between 4s and 7s only, change the cold blue light on the
right-hand wall to warm amber.

[SOURCE ROLE]
@video1 is the sole editing master, responsible for the people, the room
layout, the action, composition, camera movement, sound and event order.

[EDIT SCOPE]
Adjust only the colour of the light on the right-hand wall and the area it
illuminates; skin tone may change naturally with the ambient light.

[PRESERVE]
Identity, clothing, expression, position, movement, room structure, camera
movement, dialogue and room tone stay as in @video1.

Case A — replacing a subject.

TEMPLATE

[EDIT GOAL]
Edit @video1; change <original object> to <target object> only.

[SOURCE ROLE]
@video1 is the sole editing master, responsible for the original scene,
camera position, camera movement, motion paths, occlusion relationships
and event order.

[TARGET ASSET ROLE]
@image1 supplies <target object>'s <appearance, structure or material>;
do not take <unrelated background, people or composition>.

[EDIT OBJECT AND SCOPE]
Modify only <the explicit object and region>. The count of the target
object across the whole clip is <number>. Do not modify <what must stay>.

[TIMELINE INHERITANCE]
<Target object> inherits every appearance, movement, occlusion and exit of
<original object>: the same timings, durations, paths and changes of speed.
Apart from the object or region explicitly modified above, all other
people, props, scene content, camera movement, cuts and event order in
@video1 stay as they are.

EXAMPLE

[EDIT GOAL]
Edit @video1; replace the yellow folding lamp with the white folding lamp
from @image1 only.

[SOURCE ROLE]
@video1 is the sole editing master, responsible for the desk, the books,
the hand movements, camera position, camera movement, occlusion
relationships and event order.

[TARGET ASSET ROLE]
@image1 is used only for the white folding lamp's appearance, structure
and material; do not take the background, composition or other objects in
the image.

[EDIT OBJECT AND SCOPE]
There is exactly one white folding lamp throughout. Replace only the
original yellow folding lamp; do not modify the books, desk, hands or
background.

[TIMELINE INHERITANCE]
The white folding lamp inherits every appearance, swing of the arm,
occlusion by the hand and exit from frame of the original yellow lamp:
the same timings, paths and changes of speed. Apart from the object
explicitly modified above, all other people, props, scene content, camera
movement, cuts and event order in @video1 stay as they are.

Case B — replacing a background.

TEMPLATE

[EDIT GOAL]
Edit @video1; replace <the original background region> with <the target
environment> from @image1 only.

[SOURCE ROLE]
@video1 is the sole editing master, responsible for the people, foreground
objects, action, composition, camera movement and event order.

[TARGET ASSET ROLE]
@image1 is used only for <target environment>'s spatial layout, materials,
depth of field, ambient colour and light direction; do not take the people
or foreground objects in the image.

[EDIT OBJECT AND SCOPE]
Modify only <the background region outside the subject's outline>. Do not
modify <the subject's identity, features, hair, clothing, expression,
position, size or movement>.

[TIMELINE INHERITANCE]
The subject's movement and occlusion relationships stay as in @video1.
Apart from the object or region explicitly modified above, all other
people, props, scene content, camera movement, cuts and event order in
@video1 stay as they are.

EXAMPLE

@video1 is the sole editing master, responsible for the person, the action,
composition, camera and event order.
@image1 supplies only the spatial layout, depth, ambient colour and light
direction of a daytime glass greenhouse; do not take the people in it.

Replace only the pale grey background outside the person's outline in
@video1 with the daytime glass greenhouse from @image1.

The person's identity, features, hair, clothing, expression, position,
size and raised-hand movement stay as in @video1. Apart from the region
explicitly modified above, all other people, props, scene content, camera
movement, cuts and event order in @video1 stay as they are.

Editing sound. Dialogue, language, timbre, background music and effects can each be handled separately. State the speaker or sound category, the intended change, and whether the other sounds are preserved.

EXAMPLE

Edit @video1; remove the original background music only, keeping the
dialogue, lip sync, ambience and action effects. Picture content, camera
and cutting rhythm stay as in @video1.

Edit @video1; change <DOCENT>'s dialogue language to natural American
English, keeping the line content and the timing of speech unchanged.
Other characters' voices, background music, ambience and picture stay as
in @video1.

2.5 Extension: align the boundary frame first, then describe what comes before or after

Extension generates new material outside the boundary of an existing clip. The output ratio automatically follows the input; the added duration is set by you.

BOUNDARY

          extend backward  ←  [ original video ]  →  extend forward
                              first frame  last frame

The boundary frame must be continuous. Extending forward, the first frame of the new segment has to continue from the source's last frame. Extending backward, the last frame of the new segment has to join the source's first frame. Beyond the boundary frame itself, people, props, background, motion trend and sound must also stay continuous.

Extending forward. Describe the continuous state of the source's last frame first, then what happens after it.

TEMPLATE — forward, basic

@video1 is the source video to extend forward.

Extend @video1 forward. The first frame of the extension continues
directly from the last frame of @video1: keep <subject pose and facing>,
<prop positions>, <background and spatial relationships>, <camera position
and composition>, <light>, <sound state> and <motion trend> continuous.

Then, <describe the new action, event, camera move or sound>.

Throughout the extension keep <identity and clothing>, <key props>,
<background layout>, <the camera axis> and <the original sound
environment> continuous. The same subject remains one continuous object —
no duplication, no splitting; the subject's form and the number of parts
stay stable.

EXAMPLE

@video1 is the source video to extend forward.

Extend @video1 forward. The first frame of the extension continues
directly from the last frame of @video1: keep the same locked-off medium
shot, the position and heading of the orange paper plane, the classroom
window background, the afternoon light and the drift toward the right of
frame continuous.

Then let the orange paper plane glide further right and leave frame, while
the white curtain at the window sways slightly. Camera and classroom
background stay as at the source's last frame.

TEMPLATE — forward, with other reference assets

@image1 defines <PERSON A>'s facial features.
@image2 defines <PERSON A>'s clothing.
@image3 defines <key prop>'s structure and material.
@video1 is the source video to extend forward.

Extend @video1 forward. The first frame of the extension continues
directly from the last frame of @video1: keep <the boundary picture and
sound state> continuous.

Then, <the new action or event PERSON A performs with the key prop>.

Throughout the extension keep <identity and clothing>, <key props>,
<background layout>, <the camera axis> and <the original sound
environment> continuous. The same subject remains one continuous object —
no duplication, no splitting; the subject's form and the number of parts
stay stable.

EXAMPLE

@image1 defines <GARDENER>'s facial features.
@image2 defines <GARDENER>'s pale green work apron.
@image3 defines <WICKER BASKET>'s structure and material.
@video1 is the source video to extend forward.

Extend @video1 forward. The first frame of the extension continues
directly from the last frame of @video1: keep the greenhouse bench,
<GARDENER>'s standing position and the position of <WICKER BASKET>
continuous.

Then <GARDENER> lifts <WICKER BASKET> with both hands and sets it on the
middle shelf of the wooden rack behind them.

Throughout, keep <GARDENER>'s face, apron, the greenhouse layout and the
camera direction continuous.

Other assets may supply people, props or sound, but they do not replace the source's last frame as the control on the opening picture.

Extending backward. Describe what happens before the source starts first, then write the source's first frame as an explicit end state. Writing only "then it joins the original video" tends to make the model introduce later characters or effects early, or keep changing the picture after it has already reached the target state.

TEMPLATE — backward, basic

@video1 is the source video to extend backward.

Extend @video1 backward. Before the source begins, <describe the preceding
action, event, camera move or sound>.

The last frame of the extension joins the first frame of @video1 naturally:
<subject pose and facing>, <prop positions>, <background and spatial
relationships>; keep <camera position and composition>, <light>, <sound
state> and <motion trend> consistent with @video1's first frame.

Throughout the extension keep <identity and clothing>, <key props>,
<background layout>, <the camera axis> and <the original sound
environment> continuous. The same subject remains one continuous object —
no duplication, no splitting; the subject's form and the number of parts
stay stable.

EXAMPLE

@video1 is the source video to extend backward.

Extend @video1 backward. Before the source begins, show the same glass
greenhouse empty: morning mist lying low and slowly dispersing, the shade
blind at the top gradually rising, no people in frame.

The last frame of the extension joins the first frame of @video1 naturally:
keep the central aisle, the planting benches on both sides, the glass
frame, the soft morning light and the locked-off wide composition
consistent with @video1's first frame; at the end the blind is fully
raised, no one is in the aisle, and the leaves are still moving faintly.

TEMPLATE — backward, with other reference assets

@image1 defines <PERSON A>'s facial features.
@image2 defines <PERSON A>'s clothing.
@image3 defines <key prop>'s structure and material.
@video1 is the source video to extend backward.

Extend @video1 backward. Before the source begins, <PERSON A completes the
preceding action or event>.

The last frame of the extension joins the first frame of @video1 naturally:
<PERSON A's pose and facing>, <the position and state of the key prop>,
<where the other characters stand>; keep <background and spatial
relationships>, <camera position and composition>, <light>, <sound state>
and <motion trend> consistent with @video1's first frame.

Throughout the extension keep <identity and clothing>, <key props>,
<background layout>, <the camera axis> and <the original sound
environment> continuous. The same subject remains one continuous object —
no duplication, no splitting; the subject's form and the number of parts
stay stable.
<Assets that appear only after the source begins> must not appear early in
the backward extension.

EXAMPLE

@image1 defines <CURATOR>'s facial features.
@image2 defines <CURATOR>'s dark blue work coat.
@image3 defines <WOODEN DISPLAY CASE>'s structure and material.
@image4 defines the grey work clothes of the two <INSTALLERS>.
@image5 defines the space and light of <PREP ROOM>.
@video1 is the source video to extend backward.

Extend @video1 backward. Before the source begins, <CURATOR> walks to the
bench, picks up the closed <WOODEN DISPLAY CASE> and opens the lid.

The last frame of the extension joins the first frame of @video1 naturally:
<CURATOR> stands in the centre of frame holding the opened <WOODEN DISPLAY
CASE> in both hands; the two <INSTALLERS> stand behind them, one to each
side. Keep the vertical front-on medium shot, the bench position, the prep
room background and the morning light from the left consistent with
@video1's first frame.

The boundary should look naturally joined; it should not be read as pixel-identical. The loudness of the extension may vary slightly from the source. Extending a video generated by the same model generation usually joins more smoothly in both picture and sound. When reviewing, check the picture, the sound and the whole extended segment on both sides of the boundary.

3. Advanced usage

3.1 Keyframes, storyboards and white-box references

First and last frame together with reference assets. In multimodal reference mode you can declare @image1 as the first frame and @image2 as the last frame in the opening line of the prompt — there is no need to switch to a separate first/last-frame mode. The system locks the output ratio to the first frame's ratio; duration is set on the generation page or through the API. First and last frame should use the same ratio, or the last frame may be stretched. Remaining reference images can still define people, props, scenes and materials separately.

TEMPLATE

@image1 is the first frame, defining the composition, subject position,
pose, prop state, scene and camera direction at the start.
@image2 is the last frame, defining the composition, subject position,
pose, prop state, scene and camera direction at the end.
@image3 supplies <SUBJECT A>'s <appearance, clothing, structure or
material>; it does not change the first-frame composition defined by
@image1, nor the last-frame composition defined by @image2.
@image4 supplies <SUBJECT B, prop or scene>'s <specified attributes>; it
does not change the first-frame composition defined by @image1, nor the
last-frame composition defined by @image2.

<Describe one continuous action or event.>
The picture begins naturally from the first frame defined by @image1 and,
through continuous action, arrives at the last frame defined by @image2.
Between the two, keep <identity, prop structure and ownership, scene
layout and camera direction> continuous.

EXAMPLE

@image1 is the first frame, defining the composition of the perfume
workshop at the start: the person's position, pose, the state of the props
on the bench and the camera direction.
@image2 is the last frame, defining the same at the end.
@image3 supplies <PERFUMER>'s face, hair and dark green apron; it does not
change the compositions defined by @image1 and @image2.
@image4 supplies <GLASS BOTTLE>'s shape, material and label position; it
does not change the compositions defined by @image1 and @image2.

Starting from the first-frame pose, <PERFUMER> picks up a pipette and
<GLASS BOTTLE>, drips amber concentrate into it, swirls it gently, seats
the stopper, and places the finished bottle in the centre of the bench,
arriving naturally at the last frame defined by @image2.

Between the two, keep <PERFUMER>'s identity and clothing, the number and
structure of the bottles, the layout of the wooden bench, the warm side
light and the camera direction continuous.

Each anchor image needs its own sentence — do not merge them into "images 1 and 2 as the first and last frames". First and last frame should use the same ratio. Other reference images supply specified attributes only; they do not override the composition of the anchors.

Multiple keyframes in order. When several independent images define different stages of a process, open with the ordering statement, then describe the key state each image represents.

TEMPLATE

Use @image1 through @imageN as keyframes, in that order.

@image1 is the first frame, defining <the composition, subject position,
pose, prop state and camera direction at the start>.
@image2 defines the second keyframe: <the visible state at the end of
stage one>.
@image3 defines the third keyframe: <the visible state at the end of
stage two>.
@imageN is the last frame, defining <the composition, subject position,
pose, prop state and camera direction at the end>.

The picture passes in turn through the states defined by @image1, @image2,
@image3 … @imageN, moving between stages with continuous action.
Throughout, keep <subject identity, prop structure and ownership, scene
layout, light and the camera axis> continuous.

EXAMPLE

Use @image1 through @image4 as keyframes, in that order.

@image1 is the first frame: an orange paper plane at rest on the left of a
classroom desk, nose pointing to the right of frame, locked-off medium shot.
@image2 defines the second keyframe: the same orange paper plane lifted off
the desk by a hand, nose direction unchanged.
@image3 defines the third keyframe: the same plane passing the window, the
curtain swaying slightly to the right.
@image4 is the last frame: the same plane landing on the middle shelf of
the bookcase on the right, nose still pointing right.

The picture passes in turn through the states defined by @image1 to
@image4, keeping flight direction and speed continuous between stages.
Throughout, keep the plane's orange stock, size and fold lines, the
classroom layout, the afternoon side light and the camera axis continuous.

Independent keyframes usually align more easily than several panels packed into one grid image. Understand what they control: stage order and key states — not frame-by-frame reproduction.

Storyboard grids. A grid gives the overall story, the shot order and rough composition. It is not suited to demanding that each cell be reproduced in detail. Keep it under about 15 cells, use clean line art or a tidy schematic, and minimise text labels. State the reading order in the prompt, then write each shot's subject action, shot size or camera move, plus the final look and sound.

TEMPLATE

@image1 supplies the shot order and rough composition of an <N-cell
storyboard>, read <left to right, top to bottom>; do not take <the line-art
style, text labels or placeholder figures> from it.
@image2 defines <SUBJECT A>'s <appearance and clothing>.
@image3 defines <key prop or scene>'s <structure, material or light>.

Shot 1: <shot size, subject action, scene state>.
Shot 2: <shot size, subject action, camera move or cut>.
…
Shot N: <closing action and final picture state>.

The final image uses <visual style>; sound includes <dialogue, ambience,
action effects or music>.

EXAMPLE

@image1 supplies the shot order and rough composition of a four-cell
pottery storyboard, read left to right, top to bottom; do not take the
line-art style or the text labels.
@image2 defines <CERAMICIST>'s face, short hair and dark grey apron.
@image3 defines <BLUE GLAZED CUP>'s proportions, glaze colour and curved
handle.

Shot 1: a wide shot of the quiet pottery studio, <CERAMICIST> seated at
        the wheel.
Shot 2: a medium side shot of <CERAMICIST>'s hands steadying the spinning
        wet clay as the wall rises.
Shot 3: a close-up of fingers refining the join between rim and handle,
        slip running slowly off the fingertips.
Shot 4: a medium close-up of the fired <BLUE GLAZED CUP> being set on the
        wooden rack as <CERAMICIST> withdraws both hands.

The final image is realistic documentary; keep the hum of the wheel, the
friction of wet clay and studio room tone.

White-box references. These split into coarse and fine, and picking the wrong one wastes the asset.

COMPARE

Coarse white-box
  Suits      previsualising action, paths, blocking, camera moves or cuts
             with simple geometry
  Asset      clear relationships between solids, a complete action
             sequence; can be layered with people, prop and scene images
  Prompt     map every white-box solid one by one, and state which
             temporal and spatial information is inherited

Fine white-box
  Suits      a finished model that needs different people, materials,
             colour, scene or style
  Asset      complete structure and a clean plate — no trajectory lines,
             axes or camera frustums
  Prompt     keep structure, action and camera; state which attributes
             are to be re-rendered

A coarse white-box is good for locking motion paths, direction of travel, where people stand, entrances and exits, camera paths, cut points, light changes and sound rhythm. Every solid should map to a final subject or prop; appearance comes from other reference images.

MAPPING — what the white-box supplies → what you must state

Blocking   motion paths, direction of travel, where people stand,
           entrance and exit order
Camera     position, camera path, direction and changes of speed
Light      light direction, changes in brightness, and when they happen
Cuts       cut points, and the subject and composition either side
Sound      whether dialogue, music, ambience or action effects are
           inherited

Prefer simple solids with clear relationships. Appendages such as arms or wings are only suitable as white-box information when the action sequence is complete; otherwise they tend to produce stiff movement or misread structure.

TEMPLATE — coarse white-box

@video1 is a coarse white-box reference. It supplies only <motion paths,
blocking, camera position, camera movement, cuts, light changes, sound
rhythm or spatial relationships>; do not take the white-box appearance,
materials or scene from it.
The <white-box subject A> in @video1 corresponds to <SUBJECT A>.
The <white-box subject B or geometric prop> in @video1 corresponds to
<SUBJECT B or key prop>.
@image1 defines <SUBJECT A>'s <appearance, clothing or structure>.
@image2 defines <SUBJECT B, key prop or scene>'s <specified attributes>.

<SUBJECT> completes <the main action or event> in <scene>.
Keep <the motion paths, blocking, camera movement, cuts, light or sound
rhythm> from @video1.
The final image uses <people, scene, materials and visual style>; sound
includes <dialogue, ambience or action effects>.

EXAMPLE

@video1 is a coarse white-box reference. It supplies only the walking path,
the direction the cart travels, the locked-off camera position, one push-in
and two cuts; do not take the grey solids' appearance or the empty scene.
The tall cylinder in @video1 corresponds to <DOCENT>.
The long box in @video1 corresponds to <MOBILE CART>.
@image1 defines <DOCENT>'s face, blue uniform and name badge.
@image2 defines <MOBILE CART>'s white metal frame and clear cover.
@image3 defines the curved wall, grey floor and linear ceiling lights of a
science gallery.

<DOCENT> pushes <MOBILE CART> along the curved wall, stops in front of the
central plinth and opens the clear cover.
Keep the walking path, blocking, push-in direction and cut points from
@video1.
The image is bright, realistic museum-documentary; keep footsteps, the
sound of the wheels and gallery room tone.

A fine white-box already has complete people, props or scene structure, and suits changing materials, colour, cast, scene and overall style. The plate should be clean — no trajectory lines, axes, controllers or camera frustums.

TEMPLATE — fine white-box

@video1 is a fine white-box reference. Keep <subject structure, action,
spatial layout, camera position, camera movement and cuts>; do not take
the original grey-model materials or the empty background.
@image1 defines <subject>'s <cast, material, colour or surface detail>.
@image2 defines <scene>'s <space, materials, light or visual style>.

Re-render the <subject> in @video1 as <final subject>, and the scene as
<final scene>.
Keep <the structure, action, camera and spatial relationships> from
@video1; the image shows <materials, colour and style>; sound includes
<ambience, effects or music>.

EXAMPLE

@video1 is a fine white-box reference. Keep the complete structure of the
ring assembly, the rotational relationship between the three rings, the
plinth position, the orbiting camera move and the cuts; do not take the
original grey-model materials or the empty background.
@image1 defines the brushed brass material of the outer ring.
@image2 defines the translucent blue glass material of the inner blades.
@image3 defines the white curved wall, dark grey floor and soft ceiling
light of a contemporary art gallery.

Re-render the ring assembly in @video1 as a kinetic sculpture of brass and
blue glass, and the scene as the contemporary art gallery.
Keep the structure, rotation rhythm, orbiting camera move and cuts from
@video1; keep the low hum of the mechanism and quiet interior room tone.

3.2 One-click film

One-click film assembles several images — or images plus a style reference video — into a finished piece with consistent pacing and packaging. The prompt has to state each asset's role, the image order, how much the picture moves, the cutting rhythm, the visual packaging and the sound. Do not just write "turn these into a video".

ORDER

asset roles → image order → amount of motion → cutting style
  → visual packaging → sound

TEMPLATE

[ASSET ROLES]
@image1 supplies <person, product, scene or opening shot>.
@image2 supplies <person, product, scene or process shot>.
@image3 supplies <person, product, scene or closing shot>.
@video1 supplies <cutting rhythm, transitions, caption packaging or music
        style> only; do not take the identities or locations in it.
        (optional)

[ARRANGEMENT]
The images appear in <upload order / a specified order / freely arranged
by theme>.
<State the person, product, place and event relationships to preserve.>

[PICTURE MOTION]
Each image uses <a slight live effect, parallax, push/pull, lateral move
or localised motion>.
Keep <subject appearance, product structure, text or background
relationships> stable.

[FINISHED STYLE]
Use <cutting rhythm, transition style, caption or graphic packaging,
colour style>.

[SOUND]
Include <dialogue, ambience, effects or music>.

EXAMPLE — night-market travel short

[ASSET ROLES]
@image1 supplies the market entrance and the opening environment.
@image2 supplies <TRAVELLER> walking along the street.
@image3 supplies the lantern stall and craft details.
@image4 supplies three friends around a table eating.
@image5 supplies the riverside at night and its reflections.
@image6 supplies the closing shot of the three on the bridge.
@video1 supplies the brisk cutting rhythm, hand-drawn stickers and
        transition style only; do not take the identities or locations.

[ARRANGEMENT]
The images appear in the order @image1 to @image6, forming the sequence
arrive → wander → eat → walk → group photo.
Keep the three friends' appearance and clothing stable; do not blend them
into each other.

[PICTURE MOTION]
Environment images use a slow push-in and slight parallax; images with
people add only natural blinking, head turns, raised cups and clothing
moving in the wind.
Keep the stall structure, table positions and the bridge railing stable.

[FINISHED STYLE]
Use a bright travel-short rhythm; join scenes with natural wipes and
related colours; hand-drawn stickers appear only at the edge of frame.

[SOUND]
Keep market crowd noise, the clink of tableware and river wind, with light
instrumental music that does not dominate.

When image order matters, write the order image by image. When you are happy for the model to arrange them, say so explicitly — "may be arranged freely by theme". With several people or several products, name and bind each one as usual.

3.3 Seamless transitions between two videos

A seamless transition generates continuous material between two clips. State which clip comes before and which after, then the trigger action, camera movement, how the picture changes, the state it arrives at, and how the sound joins.

ORDER

before-clip → after-clip → trigger action → camera movement
  → picture morph → arrival state → sound

FIVE WAYS — what each one needs stated

Dive or whip-back    camera direction, changes of speed, and when the
                     next scene is entered
Subject rotation     the pose, the direction of rotation, and how clothing
                     or background changes continuously
Foreground wipe      when the occluder fills the frame, and the
                     composition revealed after it
Object morph         the corresponding shapes and materials before and
                     after, and the morphing process
Push/pull or focus   camera movement, the focus target, and the
                     continuous spatial relationship between the two

TEMPLATE

@video1 is the before-clip; take its <closing subject, action,
composition, camera direction and sound>.
@video2 is the after-clip; take its <opening subject, composition, camera
direction and sound>.
Keep the <identities, product structure, scenes and main actions> in the
original @video1 and @video2 stable.

At the end of @video1, <subject or foreground object> triggers the
transition through <action>.
The camera <direction and change of speed>, and the <shape, material,
light or space> in frame gradually becomes <the corresponding element> at
the start of @video2.
The transition ends arriving naturally at @video2's opening composition,
keeping <subject position, camera direction and motion trend> continuous.
Sound moves smoothly from <the first clip's sound> to <the second clip's
sound>.

EXAMPLE

@video1 is the before-clip; take the rainy night street, the red umbrella,
the slow push-in and the rain.
@video2 is the after-clip; take the circular skylight of the gallery, the
rising camera and the quiet interior reverb.
Keep the people, the street, the gallery structure and the main actions in
both original clips stable.

At the end of @video1, the red umbrella moves toward the lens and
gradually covers the whole frame, triggering the transition.
The camera continues pushing forward; the circular edge of the umbrella
gradually becomes the metal ring of the gallery skylight, and the red
canopy gradually becomes the white daylight coming through it.
The transition ends arriving naturally at @video2's opening low-angle
composition, the camera turning smoothly from a forward push to a rise.
The rain fades and passes smoothly into footsteps echoing inside the
gallery.

The aim is continuity of picture and sound. You can ask for the main content of both source clips to be preserved, but a generative transition is not a pixel-identical edit splice.

3.4 Emotional direction and observable performance

Words like "tense", "warm" or "oppressive" give the model an overall direction, and leave the performance wide open. To control acting reliably, name what can be directly seen or heard: eyes, brow, mouth corner, breathing, gaze direction, hand movement. You do not need to list every facial detail. For a single emotional turn, two to four of the clearest signals is usually enough; stage it across multiple beats only when the emotion genuinely turns more than once.

TEMPLATE — single turn, the default

Overall the emotion moves from <starting emotion> to <ending emotion>.
After <trigger event>, <subject> first shows <the immediate observable
reaction>.
Then <eyes, brow, mouth corner, breathing, gaze or hand movement>
gradually <changes>.
Finally <subject> expresses <the target emotion> through <a restrained or
explicit outward sign>.

TEMPLATE — multiple stages, keyed to triggers

On hearing or seeing <the first trigger>, <the subject's first observable
reaction>.
After <the second trigger> appears, <the change in the subject's
expression, gaze or breathing>.
Once <the key information> is confirmed, <the emotion the subject is
trying to contain or hide> gradually surfaces through <observable signs>.
Finally, <the subject's closing action, expression or manner of speaking>.

EXAMPLE

Applause for the end of the performance carries from behind the stage. The
young actor's fingers stop on the programme; her gaze turns slowly toward
the curtain while her shoulders stay tight.

Once the curtain call is confirmed, she lets out a small breath, her
shoulders gradually loosen, a restrained smile reaches the corner of her
mouth and her eyes slowly well up — but she never turns to leave.

3.5 Professional camera terms

Basic camera language and popular moves can go straight into the prompt. When a term is uncommon, open to several readings, or when you need precise control of how the picture changes, also state what it acts on, how the picture changes, and the result you want.

BASIC

Shot size    extreme wide, wide, medium, close, extreme close-up
Movement     push, pull, pan, track, follow, orbit, dive, pull-back,
             tilt-up, handheld shake
Position     low angle, overhead, first person

POPULAR — seven moves and what to add

Oner              the subjects, spaces and event order the camera passes
                  through continuously
Dolly zoom        the size the subject holds, and whether the background
                  is drawn in or pushed away
Aerial            the height, direction of travel, and how much
                  environment to reveal
FPV               the first-person flight or run path, speed and turns
Bullet time       which action is frozen or slowed, and the direction of
                  the orbit
Handheld          who is being followed and how much shake — avoid a
                  "handheld feel" with no subject
Speed ramp        where the action accelerates, decelerates or snaps
                  back, and the final resting state

These can be used as-is; but when several subjects are in frame, still state who the move is built around, where it starts and where it ends.

For terms that are genuinely niche, whose meaning varies across the industry, or that the model may not know, keep the term and translate it into observable change.

FORMULA

term + what it acts on + how the picture changes
  + foreground/background relationship + direction or speed

Rack focus: focus moves smoothly from the foreground leaves to the figure
behind. The leaves gradually soften; the figure's face resolves from
blurred to sharp.

For a precise transition, also write the trigger moment, the occluder, the camera direction, how the cut happens, and the composition or motion trend to preserve afterwards.

FIVE EXAMPLES

1 · Shallow-depth portrait
  <PASTRY CHEF>'s eyes and face stay sharp; the glass jars and lights
  behind fall away into soft round bokeh.

2 · Tracking shot
  The camera moves horizontally at the same speed as <SKATER>; the figure
  stays sharp while the street wall smears horizontally from right to left.

3 · Golden hour
  Warm low-angle sun enters from behind <CLIMBER>'s left; the ridge
  ground carries long shadows.

4 · Natural vignette
  The four corners darken gradually while the central <PIANIST> keeps
  normal brightness and skin tone; no black border appears.

5 · Whip-pan transition
  At 5s the camera whips left; when the foreground bookcase fills the
  frame it cuts to the next scene, and after the cut the camera keeps
  moving left at a similar speed.

Aperture, focal length and shutter values can go into the prompt, but the visible result is usually clearer than a number on its own.

4. Checklist before you submit

The guide closes with fourteen questions. Run them before you spend a generation:

 1  Are the subject and the main action or event stated clearly?
 2  Does every reference asset state what to take AND what not to take?
 3  Is each person, product and prop named and bound to its asset?
 4  Are assets selected per scene rather than all forced on screen at once?
 5  Does each stage of a long video have one main change and a written
    end state?
 6  Are headcount, clothing, prop ownership and spatial relationships
    stable?
 7  Does the edit declare a sole master, the scope, the target count and
    what stays?
 8  Are abstract emotions and camera terms cashed out as something
    directly seen or heard?
 9  Do first/last frames and multi-keyframes each state their own role,
    and do first and last frame share one aspect ratio?
10  Does the storyboard state which structure is inherited?
11  For a white-box, have you decided coarse or fine, and written which
    timing, structure, material and style are inherited?
12  Do editing, first/last-frame generation and extension respect the
    auto-locked ratio and duration rules?
13  For an extension, have you checked the boundary frame, the motion
    trend AND sound continuity?
14  Does one-click film state asset roles, image order, amount of motion,
    cutting style and sound? Does a seamless transition state both clips'
    roles, the trigger, the transition process and the arrival state?

5. What it will not do

Nine stated boundaries. These are the requests that end in disappointment:

1  Timestamps allocate event pacing only; they are not frame-level cut
   points.
2  An edit prompt raises the probability that key events align with the
   source, but cannot guarantee frame-exact overlap.
3  Multi-asset work is about selecting and combining the right assets, not
   about showing them all at once.
4  Subtitles, formulas, signage, product specs and frame-precise timing
   that must be exactly right should be handled with pre-composited assets
   plus generation plus post-production.
5  Video editing locks the input's ratio and essential duration; neither is
   settable, and output duration may differ from the input by up to about
   0.3 seconds.
6  First-frame or first/last-frame generation locks the ratio to the first
   frame; duration is settable. Mismatched first/last ratios can stretch
   the last frame.
7  Video extension locks the input's ratio; the added duration is settable.
   The extension's loudness may differ slightly from the source.
8  In one-click film, if image order or character correspondence matters,
   it must be specified in the prompt.
9  A seamless transition aims at visual and audio continuity; it does not
   mean the two source clips stay pixel-identical.

Running these prompts today

Seedance 2.5 is not open through us yet — verified against our own Volcengine Ark account on 4 August 2026, and we do not list a model whose generate button would fail. Seedance 2.0 is live from $0.092/s and shares most of the grammar above: named subjects, per-asset roles, staged events with end states, native synced audio, up to 9 reference images plus reference video and audio. The formula, the naming discipline, the stage-with-end-state structure and the inheritance clause all transfer. When 2.5 opens, the same key and the same endpoint reach it — you change one model string.

Originally published at apimodels.app, where the same guide is also available in Chinese with Chinese-language templates.

Source: ByteDance's official Seedance 2.5 prompting guide — the limits, syntax, auto-locked parameters, checklist and stated boundaries are theirs; the worked examples and the English phrasing are mine. Status figures were measured on 4 August 2026.

If you want to try this grammar today, Seedance 2.0 shares most of it and runs from $0.092/s.