How we write a story in one AI call (and why five passes lost)

The five-pass writer

The old writer ran plan, draft, edit, polish and picture planning as separate calls, five to seven per story. On paper that was thorough. In practice the stories read flat, and nobody could point to the pass that was supposed to make them good.

More passes also meant more places to fail, more waiting, and more cost on every single video.

One call that does the whole job

On 6 October 2026 we replaced the chain with one call that writes everything a story needs at once: the lines, the title, the setting and the cast of characters. Picture planning stayed as its own call, because it needs the finished lines, and translation stays separate.

Inside that one call, three settings did most of the work:

• One worked example of the same kind of story for each tone, so a scary story is shown a good scary story, not a generic example.
• A higher temperature, 1.0 with an AI service and 0.8 for local models, so stories stop converging on the same ideas.
• No deduplication pass on stories.

How we judged it

We did not build an evaluation system or pay for a judging service. We ran the old and new writers on the same ideas with the same model, DeepSeek Flash, put the stories side by side on one page, and had Claude, an AI model, read and score each one. Then we read them ourselves.

The old writer averaged about 5.0 out of 10 and the new one about 7.3. Cost barely mattered either way: about $5 of DeepSeek covered two months of all our writing tests.

Why web stories were still weak

A week later, stories made in the web app were still being called bad: no clear beginning or ending, and worse the longer they got. The cause was not the model. The web app was writing scripts on the server with its own short prompt of six bullet points, and none of the story craft from the Studio writer ever ran for web videos. Every story fix we had made had gone into a writer web users never touched.

We also found three smaller problems:

• Long web videos asked for 30 or 50 lines in one call with no plan at all.
• The Studio story prompt was about 11,500 characters, and over half of it was camera, sound and tone direction rather than story.
• When a story call failed, it quietly fell back to a generic viral prompt and then to a free online model, so failures turned into bad stories instead of errors.

Letting the model think first

DeepSeek had been running with its thinking mode switched off, to keep it fast. We tried one long story with thinking on. It was clearly more coherent, and it cost about $0.001 more, for 774 tokens of reasoning.

So the fix was one shared writer for Studio and the web, generated from the same source so the two cannot drift apart again. Short stories get one call with thinking on. Long videos make a plan with thinking, then write from the plan without it. That is two calls for a long video and still one for a Short.

Thinking can be slow, so a quick answer without thinking starts at the same time and is used only if the thinking call fails or runs out of time. In our last rerun, all three test stories finished thinking, in 39 to 61 seconds.

The blind test

The new writer is slower to write, but writing is a small part of making a video, and the extra half minute is spent where it shows.

Eight story ideas written by both versions, labelled only A and B, 15 October 2026.

The rules we added after reading the losers

Reading the stories that still fell flat gave us a short list of checks, all in the same single call:

• Keep every line under 20 words, so it reads well as a caption and as speech.
• A funny story gets one clear joke, not five weak ones.
• The ending has to name the object, rule or person planted earlier, so the payoff connects to the setup.
• No twin characters, and no "it was behind the narrator all along" ending, which the model loved.
• When the model writes more lines than there are pictures, lines are joined down to fit, and the last line always stays on its own.

What we would tell anyone building a story writer

Start with one strong call and a good example of the exact kind of story you want. Give the model room to think on anything longer than a minute. Make failures loud instead of falling back to a worse writer. And judge changes by reading real outputs side by side, blind if you can, rather than trusting that more steps mean more quality. In our case, they meant less.

Models and links

• DeepSeek API documentation