One Brief, 63,000 Words, 42 Illustrations, and a Working Flipbook: A Qwen4 Case Study

One brief. 40 chapters. 42 illustrations. A working browser-based flipbook. What happens when you give a newly released flagship model a project that can't be completed in one shot?

When a new flagship model appears, the usual first tests are familiar: ask it a hard reasoning question, throw a coding benchmark at it, or have it build a small app.

I wanted to try something less tidy.

I gave Qwen 4 Preview a project with several kinds of work tangled together: write a complete children's mystery, create a consistent illustration system for it, and turn the result into an interactive book that actually works in a browser.

The output was:

• A 63,258-word novel across 40 chapters.
• 42 SVG illustrations built around a reusable library of nine characters.
• A single-file, 652-page HTML flipbook.
• A headless browser run that reported zero runtime errors and zero text overflow.

The run took about 1 hour and 42 minutes and involved 242 assistant turns.

I ran the model through Jouzu, a coding-agent harness. The source repository contains the prompts and generated artefacts. You can open the finished flipbook here.

This isn't a benchmark, and I'm not claiming that one run settles anything about the model. It is a practical look at how Qwen 4 Preview handled a long-running task where the requirements had to survive across multiple stages.

Why this particular test?

The project is called Pip Parker and the Bureau of Lost Things.

Pip is a boy who labels everything. When his brother's stuffed dinosaur goes missing, the trail leads to a bureaucratic animal office that files the town's lost things. There's a mystery to solve, a set of clues to pay off, and a midpoint reframe: the apparent thief isn't stealing things; he's saving them.

A children's mystery makes a useful stress test because continuity failures are easy to spot. A character can't suddenly know something they haven't learned. An object can't be in two places at once. A clue introduced early has to matter later. And the ending has to resolve what the opening set in motion.

Then I added two more layers.

The book needed illustrations, but not 42 unrelated images. It needed a consistent visual language: nine reusable characters, an eight-colour palette, and SVG artwork that reused the same character definitions.

Finally, it needed to become a real reading experience. Not a PDF export or a long HTML page, but a flipbook with page turns, navigation, bookmarks and controls.

That combination made the task interesting. The agent had to move between narrative generation, structured visual assets and application development without treating them as three unrelated jobs.

The brief: constraints first

I deliberately made the brief specific. I didn't want the model to decide halfway through that 20 chapters were enough, change the cast, or quietly simplify the illustration requirements.

The novel specification called for:

• 40 chapters, each between 1,400 and 1,700 words.
• A target of roughly 60,000 words.
• A fixed cast and timeline.
• Five explicit plant-and-payoff pairs.
• A continuity ledger tracking day-by-day events and object ownership.
• A fixed final sentence.
• Kid-safe content rules: no death or gore, and a lonely rather than evil antagonist.

The plant-and-payoff requirements were especially useful. A detail introduced in one chapter had to become meaningful several chapters later. The model couldn't just make each chapter locally plausible; it had to preserve information for future use.

The illustration brief was equally constrained:

• A nine-character SVG library.
• A locked eight-colour palette.
• One cover illustration and one illustration for each of the 40 chapters.
• The same SVG definitions reused across the plates.

The point of specifying these constraints wasn't to make the prompt impressive. It was to make success and failure observable.

It took one magic prompt

The prompts are preserved verbatim in PROMPT.md.

1. Write the book and create the art system.

The initial brief produced the novel, the individual chapter files, the character library, the cover and the 40 chapter illustrations.

2. Turn the material into an interactive HTML flipbook.

The next instruction was to bind the book and artwork into a self-contained reading application. This produced the first version of flipbook.html, including 3D page turns, sound and mute controls, themes, a control dock, SVG export, keyboard navigation and mobile support.

This sequence is worth spelling out. The agent wasn't handed a fully specified application and asked to produce it in one pass. It had to work with its own earlier output, respond to new requirements and preserve the existing content while changing how it was presented.

That's closer to how real projects evolve.

The real challenge: keeping the project coherent

There were three different kinds of consistency to maintain.

1. Narrative state across 40 chapters

Long-form generation is not just a question of producing the next 1,500 words.

The next chapter has to respect what has already happened. Who knows what? Where is a particular object? How much time has passed? Which clues have been planted? Which ones still need to pay off?

The brief called for a continuity ledger covering the timeline and object ownership. The story also had fixed plot requirements and delayed payoffs.

I wouldn't infer from the final word count alone that every aspect of the story is perfect. But the project did produce all 40 chapters within the specified 1,400-1,700-word window, at 63,258 words in total.

2. Visual state across 42 illustrations

The illustration system took a different approach to consistency.

Instead of asking for each character to be redrawn from scratch, the project defined the characters once as reusable SVG elements. The 42 illustrations reused those definitions, with scene composition and positioning changing from plate to plate.

This is a small example of a broader engineering principle: if something must remain consistent, encode the invariant in the artefact rather than relying on repeated natural-language reminders.

A reusable character definition is a stronger constraint than "make this character look like the previous one."

3. Product state across a changing application

The flipbook introduced a separate set of constraints.

The application had to preserve the book and illustrations while adding pagination, chapter openers, page-turn animation and reading controls. The follow-up prompts changed the structure without changing the underlying story.

The final version includes:

• 3D page-turn animation.
• A bookmark rail with persistent state.
• Keyboard navigation.
• A live control dock.
• Adjustable flip speed, text size, art zoom and page depth.
• Room and page navigation.
• Sound controls, drift and automatic page turning.
• SVG download and copy controls.
• Responsive mobile presentation.

The deliverable is one HTML file, approximately 975 KB. It can be opened locally in a browser without a server or external dependencies.

The browser had to verify the result

This is the part I care about most.

An agent can write an HTML file and then tell you that it works. That statement is not a test.

For this project, the flipbook was exercised in headless Chrome through the Chrome DevTools Protocol. The checks covered navigation and interactions, including bookmarks, persistence, themes, sound controls and SVG export. The reported result was zero runtime errors and zero text overflow.

The important thing is the feedback loop:

Build -> Run -> Inspect -> Fix -> Run again.

The browser provides evidence from the running application, not just an assessment generated from the source code. A page can look plausible in code and still clip text. A control can exist in the DOM and do nothing useful. A bookmark can appear to work until the page is refreshed.

Running the application makes those problems observable.

There is a limit to what the result means. Zero errors in this headless run doesn't prove that every browser, device or interaction is bug-free. It means the checks run for this project completed with zero reported runtime errors and zero overflow. That's a concrete result, but not a universal guarantee.

The role of Jouzu

I ran Qwen 4 Preview inside Jouzu, which provided the coding-agent environment.

The model had access to the project files, shell commands and a browser it could use to inspect the application. That matters because this wasn't a chat-only exercise. The model had to create and modify real files, execute code, observe what happened and continue working.

It's useful to separate the roles:

• Qwen 4 Preview was the model doing the reasoning and generating the work.
• Jouzu provided the agent harness and tool environment.
• Headless Chrome provided a way to exercise and inspect the resulting application.

The model and the harness are part of the result. This is not a claim that the model, without tools or an execution environment, independently produced and verified everything.

The numbers

The figures below are from the project output and the Jouzu session trace.

These are measurements from one session, not benchmark scores. They don't tell us how Qwen 4 Preview compares with another model, how repeatable the run is, or how much human review a production version would need.

What I think this demonstrates

The interesting result isn't the 63,258 words. A model generating a large amount of text is no longer particularly surprising.

What is more interesting is that the outputs depended on one another.

The illustration system had to match the story. The flipbook had to contain the story and illustrations. Pagination had to preserve the content. Later changes had to improve the reading experience without breaking what had already been built. And the final application had to survive an actual browser run.

A few takeaways stood out for me:

A good brief is a form of project management. Fixed requirements, explicit dependencies and measurable constraints gave the agent a target that could be checked.

Long context isn't the same as reliable state. The project needed explicit continuity information. A model having a large context window doesn't automatically mean it will maintain every detail correctly across a long task.

Reusable structures are more reliable than repeated instructions. The SVG character library made visual consistency part of the implementation rather than a recurring request.

Tool use is only half the story; feedback is the other half. Giving an agent access to a browser is useful. Having it run the application, inspect the result and correct problems is much more useful.

The final artefact matters. There is a difference between a demo that looks convincing in a screenshot and a project with source files, a complete book and an application someone else can open.

I would still want to repeat the experiment, try another model under the same conditions, test on a wider range of devices and get human readers to assess the manuscript. Those are worthwhile next steps, but they weren't part of this run.

So I see this as an existence proof, not a benchmark.

Try the result

You don't have to take my word for what was built.

• Open the interactive flipbook
• Explore the GitHub repository
• Read the four prompts

The repository includes the novel, individual chapter files, SVG character library, cover and chapter illustrations, prompts and the final HTML application.

Qwen 4 Preview is a newly released flagship preview model. I wanted to test it on something more demanding than a short coding task. This was one project, one run and one set of constraints.

The question I started with was simple: could an agent carry a complicated brief through multiple stages and finish with something real?

In this run, it did. The interesting part was not how much it generated, but how much of the original intent it managed to preserve while building, changing and testing the result.

Model: Qwen 4 Preview | Harness: Jouzu | Project: Bureau of Lost Things

For the current official model listing, see Qwen4-Max-Preview documentation.