generate_image_story

pro.aicut/aicut · Verify this server

CREATES an AI image story: a narrated script turned into a sequence of AI-generated images, read aloud with captions over it. aicut's most-used format for facts, history, horror, storytime and explainer shorts. YOU WRITE THE SCRIPT, AND ONLY THE SCRIPT. The `text` you send is the narration that gets spoken, verbatim, in that order - there is no writer behind this endpoint. Draft it yourself from what the user asked for, show it to them as plain text before spending anything, and change it until they like it. Iterating on the script costs nothing. What you must NOT write is the pictures: aicut segments your script and writes every image prompt itself. A WORKED EXAMPLE of `text`: `"In 1943 a Soviet pilot was shot down behind enemy lines. He walked eighteen days through the snow on two broken legs. When he reached his own trenches, they did not believe he was alive. Then he asked for his plane back."` That is the whole format: a narration script in plain prose, the way it should be READ ALOUD. No scene numbers, no image directions, no stage notes, no speaker labels - aicut cuts it into scenes and writes the picture for each one. Write it the way a good voiceover sounds: short sentences, a hook in the first line, one idea at a time. PRICE IS DRIVEN BY THE IMAGE COUNT, not by the words. `estimate_only: true` returns `scene_count` and `voice_provider` next to the money - say the count and the price. The three levers, in the order to reach for them: `seconds_per_image` (3 is the default; 5 buys fewer images for the same script and is the cheap direction, 2 is the busy/expensive one), `image_model` (`zit-realism` is the cheap default; `nano-banana-pro` is roughly fifteen times the per-image price - offer it only when the user wants the best-looking result and say what it costs), and `voice_provider` (ElevenLabs reads best and costs about four times openai/polly per character of narration). Re-quote after changing any of the three; never carry an older number across a change. STYLES ARE OPTIONAL AND THEY ARE NOT FREE. `list_image_story_styles` returns aicut's authored looks; passing one as `style_id` forces the expensive edit-capable image model, so re-quote with `estimate_only` after adding one. Without a style you get aicut's default photorealistic look, which is what most videos use. AFTER: the response carries the job id, `scene_count`, the price split (`generation_tokens` for the images and narration, `render_tokens` for the video file) and `renders_automatically: true`. If it ALSO carries `start_confirmed: false`, the job exists but aicut never saw its start confirmed - do not create it again, watch that job id and tell the user it may need a retry if it has not moved in fifteen minutes. THERE IS NO FIRE STEP AND NO RENDER STEP: this one call makes the finished video. Wait for it with `wait_for_generation`; when it is terminal, `get_video` carries the file url. It takes longer than a single image - every scene is generated. LANGUAGE: write `text` in the language you name. aicut detects the script's language and TRANSLATES it when it differs from `language`, and a translated script has a different length - so the quote is exact for the script you sent and only for that. Do not send English and ask for German expecting the quoted price; write the German. REFUSALS (the common ones, not all of them - always read the `code` you actually get): 400 = the script or a setting is not accepted, and the message says which (a script over the language's character limit, which aicut will NOT silently cut for you; a script that needs more images than one video can carry, where the fix is a longer `seconds_per_image`; an unknown style id, model, voice or language). 402 = not enough tokens for the whole video; the body carries `required` and `balance`. 503 `image_story_unavailable` = the video was not started and nothing was charged; retry the same call once. THE WATERMARK is decided by the account's plan, not by this call: free accounts get the aicut mark on the video. Say so if the user asks; there is no argument that changes it. DELIVERY: hand the user ONE thing - the finished video. Do not re-list the script back at them after it is made. SPEND ETIQUETTE (the money grammar): in the webapp the priced button is the user's own finger; in chat YOUR tool call is not - so state the price IN THE SAME MESSAGE as the ask, and the user's explicit go is the button press. Never charge on inference: quoting is not asking, and after a price you wait for the yes. THIS APPLIES TO EVERY TOOL CARRYING THIS NOTE, including this one. A GO IS SCOPED TO ONE PURCHASE, AND IT MUST BE UNAMBIGUOUS. The user's instruction has to NAME the thing you are about to buy, or refer to it so plainly that it cannot mean anything else. A BARE AFFIRMATION - 'go', 'yes', 'ok', 'do it', 'just do it', 'sure' - counts ONLY when ALL THREE of these hold: the message immediately before it was YOUR priced ask for THAT EXACT action, nothing else was raised in between, and NOTHING THE USER ASKED FOR EARLIER IS STILL OUTSTANDING. That last one is the trap the others miss: if the user's OWN previous turn asked for something else - a refusal, a different scene, an edit, a redraw, a question - their 'just do it' may be answering THAT, and it is AMBIGUOUS even when your priced ask happens to be the last thing said in the thread. An ambiguous affirmation is not a go: ask WHICH one they mean and state that price again. WHEN IN DOUBT ABOUT WHAT A 'GO' REFERS TO, ASK. A wrong guess spends the user's money on something they never asked for, and nothing on this surface can undo it or give it back - asking costs one sentence. An episode's STAGES - cast portraits, episode create, fire, render - are each their own priced ask. A STANDING GO IS NOT UNLIMITED: 'just make it' or 'go ahead with the whole episode' authorizes the stages you PRICED IN THAT SAME MESSAGE, in the order you named them, and nothing beyond them - so do not re-ask per stage while it holds, and do not stretch it over a stage whose price the user never saw. IT EXPIRES THE MOMENT THE USER RAISES ANYTHING ELSE - a change, a question, a refusal, a redraw, a new idea - and after that the next stage needs its own priced ask. ONE STAGE IS NEVER COVERED BY A STANDING GO AT ALL: the FIRE (`fire_story_video`) is irreversible and the biggest single charge in the episode, so it always takes a go that NAMES firing, whatever was said earlier - see that tool's own note. A REDRAW IS NOT A STAGE: `regenerate_story_frame` and `regenerate_cast_portrait` are extra spends the user asks for one at a time, so state that price every time, even under a standing go. A standing go never carries to a different episode, and never to `generate_video`, `generate_image` or `generate_audio` - each of those is its own ask. ACCOUNT FOR YOUR OWN CALLS: if the user says something happened that you did not intend - a charge they did not expect, a step they did not ask for - RE-READ YOUR OWN TOOL CALLS IN THIS CONVERSATION before you answer, and tell them plainly which tools you called and when. NEVER SPECULATE ABOUT A CAUSE YOU CANNOT OBSERVE: not a button on an aicut card, not the user's own click, not their client. The aicut cards CANNOT SPEND - the only tools they ever call are the reads (`get_video` / `get_image` / `get_audio`), and their buttons either save a file or send a VISIBLE user turn into the chat - none of them calls a spending tool - so saying a card might have generated or charged something is false, not a hedge. (If a spend followed one of those visible turns, it was still YOUR call, and the honest answer names it.) If your call history disagrees with what you told the user, say what you actually called and let them correct you; do not invent an explanation that makes the two agree. IDEMPOTENCY: `idempotency_key` is optional and makes a retry safe. Set it on the FIRST call, not only on a retry - the job is addressed by the key, so a key added afterwards cannot find a job that was created without one. Reusing a key REPLAYS the job that key already created and returns it unchanged - even if you send a different prompt or different settings, and even after that job has finished. A key is therefore spent permanently. Do NOT reuse one to make another generation: two deliberate generations are two jobs and need two different keys (or none). ONE EXCEPTION, on `render_story_video`: replaying a key whose render FAILED answers 409 `render_failed` rather than replaying the failure, because a spent key stays spent - retry that one with a NEW key or with none. A KEY IS NOT SCOPED TO A TOOL: it addresses a job on the whole account, so reusing the key you gave `generate_video` on `generate_story_video` replays that first video instead of starting an episode. One key, one thing you made. (`render_story_video` is the one door that namespaces its own, which is why an episode's key can be reused on its render without colliding - but there is no reason to reuse it there either.) Never derive the key from the request body. You do NOT need to pass one to be safe against a duplicated delivery: aicut already derives a per-call key server-side, so a retry the transport makes on its own replays rather than charging twice. Pass your own only when YOU want to retry a call whose answer you never saw. OUTPUT: this returns JSON for you to read. When you report back to the user, give them the media URL plus a one-line summary. Do not paste the raw JSON, job ids, or internal field names into the conversation.