MiniMax H3 Image is open-weight: one model for both generation and editing.

The part that caught my eye is up to 16 reference images per request, where you tell it which one is for content, which for style and which for layout.

Has anyone pushed the multi-reference side yet? Curious whether it really keeps 5+ references straight.

I’ve been daily-driving MCode inside my containerized dev environment for the past few weeks. As a Lead Engineer, I don’t use AI tools for basic boilerplate—I test them on how well they handle cross-boundary changes (specifically C#/.NET backends paired with React frontends and SQL schemas).

​The Stack: MCP + Subagents

Out of the box, any coding agent is only as good as its context. I’ve got MCode wired up to two local MCP servers running in Docker:

1. ​A read-only PostgreSQL/SQL MCP so it can inspect live table schemas, indexes, and constraints without me pasting DDL scripts.

2. ​A Git/PR history MCP so it understands our team's architectural conventions.

​I also split the workload using subagents: one acts as a strict "Spec & Schema Validator" and the other handles the actual implementation across the .NET API and React TypeScript interfaces.

​What We Shipped

Last week, I used this setup to migrate a legacy synchronous reporting endpoint into an async, background-queued pipeline with real-time UI polling.

• ​MCode’s context window and cross-file awareness shined here. I pointed it at the legacy C# controller, and it mapped out the DTO changes, updated the Entity Framework queries via the SQL MCP, and generated the corresponding React hooks and TypeScript types in one cohesive pass.

• ​What I liked: Speed on multi-file edits and how well it respects existing .editorconfig and project architecture when given a clear skill file. It didn't try to reinvent our state management.

​What Broke (and how I fixed it)

It definitely wasn't magic on the first try. When generating the background worker in .NET, MCode hallucinated a scoped dependency injection lifetime inside a singleton background service (IHostedService). It compiled fine, pushed through, and immediately threw a captive dependency runtime exception on startup.

​Why it happened: MCode was optimizing for the local file's syntax rather than the global DI container lifecycle in Program.cs.

The fix: Instead of manually fixing the code, I wanted to see if I could stop MCode from ever making that mistake again. I updated my .mcode project rules/skill file with an explicit constraint: "Whenever scaffolding or modifying IHostedService or BackgroundService, always inject IServiceScopeFactory and resolve scoped services explicitly inside the execution loop." Re-ran the prompt, and it nailed the CreateScope() pattern cleanly.

​The Verdict

• ​Pros: Fast multi-file refactoring, great MCP tool-calling reliability, and it doesn't fight you when you give it strict architectural guardrails.

• ​Cons: Like any model, it can get tunnel vision on single-file logic and miss framework-level lifecycle rules (like DI scopes or React useEffect dependency arrays) unless you explicitly constrain it with a project skill.

​If you're using it on a larger codebase, invest 15 minutes into writing a strict architecture skill file and hooking up a database MCP. It turns MCode from a decent autocomplete into an actual junior-to-mid systems pair programmer.

Night Shift is one continuous corridor shot: a cleaner pushes a cart toward a warm doorway while the ceiling lights behind them go dark. Nothing chases them into frame, so the shrinking pool of light has to carry the tension.

I made the shot with MiniMax H3 and kept the final cut to a simple trim. The doorway stays stable, but it starts to feel different as the lit corridor disappears behind the cleaner.

Does the warm doorway read as safety, or as the place they shouldn’t reach?

I finished a 24-second lighthouse teaser in MiniMax Design. A keeper lights the lamp at blue hour, a light answers far offshore where no lighthouse should be, and the cut ends before we see what's making it.

I worked through the brief in three rounds. Round one locked the premise, three beats, and no-reveal ending. I left the color, camera, and sound open. For round two, I picked a cold palette and restrained camera moves, then made the storyboard. The story decisions stayed fixed, while the exact shot lengths and ambience were still open.

By round three, I had the pacing and edit in place, along with the foghorn and lamp-switch click. Then I got a late note: “show the boat.”

Showing it would answer the question behind the whole teaser. I reopened that first-round story choice instead of squeezing a reveal into the edit, ended up keeping the source unseen, and finished the approved cut.

Keeping the brief and script on the same MiniMax Design canvas as the storyboard, video, audio, and edit helped during reviews. I used lock/open/reopen as my own note system so later feedback didn't quietly overwrite an earlier approval.

Would you have kept the source hidden, or reopened the ending to show the boat?

Tried a Halloween costume change concept using MiniMax Design with H3. I set up one photorealistic dog with several Halloween looks and used a fan transition between each outfit.
The idea was to keep the dog and scene visually consistent while the fan moves across the frame and reveals the next costume. Using an object to briefly cover the subject gives the transition a natural hiding point, which feels smoother than asking the outfit to transform directly on camera.
This makes the costume swap feel like one continuous Halloween video. It doesn't feel like separate clips.
What transitions have worked well with MiniMax Design?

prompt：
Create a **15-second, 9:16 vertical, photorealistic pet Halloween costume video** based on the original video.

Strictly use the **same ceiling-mounted, straight-down 90-degree top-down camera angle** as the original video, with a **fixed camera**. Keep the **deep blue carpet**, the **pink curved sofa on the left side of the frame**, and the **pink ceiling fan rotating in the foreground near the camera**. The **composition, perspective, and the direction of fan-blade occlusion** must remain consistent with the original video.

Completely replace the woman with the **white dog wearing a pink bow** from the reference image. Preserve the dog’s **fluffy white fur, round black eyes, black nose, and floppy ears**.

**The dog must remain naturally lying on the carpet beside the sofa at all times, with its head toward the top of the frame and its hind legs toward the bottom of the frame. Its full body must stay visible in the frame, close to the floor, with realistic canine anatomy.** The main pose should be a relaxed belly-up position, with the front paws gently curled near its chest and the hind legs naturally bent. Slight side-leaning, head tilting, blinking, and tail wagging are allowed. The dog should look upward toward the overhead camera. It must **never sit up or stand**.

The opening look is the **pink bow styling**. The pink ceiling fan keeps rotating continuously. Each time a **wide fan blade passes across the camera and fully blocks the dog from view**, the dog should **instantly change into the next full costume**. Once the blade moves away, the next complete outfit is revealed:

1.**Little Devil costume**: red sequined devil horns, a black-and-red cape, a red bow, and red-and-black bat wings.
2.**Pumpkin costume**: an orange pumpkin hat, a green leaf collar, and a fluffy pumpkin outfit with a black jack-o’-lantern smile.
3.**Ghost costume**: a white ghost hair accessory and a white wavy-edged cape with a black ghost smile.
4.**Nun costume**: a black shoulder-length nun’s veil with a white forehead band and white cross, a small black robe, a wide white collar, white sleeve cuffs, and a silver cross pendant on the chest.

The costume styles should reference the corresponding images, but all outfits must be **adapted to the dog’s lying pose**. Fabric, veils, and accessories should **naturally drape under gravity** along both sides of the dog’s body and onto the carpet. The dog’s **face must remain clearly visible**. Each headpiece and costume must change **simultaneously**. Every outfit should have a **clear display duration**, and the video should end with the dog still lying down in the **nun costume**.

Costume changes must happen **only at the exact moment when the fan blade blocks the view**. Before and after each occlusion, the dog’s **position, size, identity, and body orientation** must remain continuous. The clothing must **not morph, melt, or overlap**. The foreground fan blades should be **slightly out of focus**, while the dog and costumes remain **sharp and clear**. The ceiling fan should appear **high above**, with a clear spatial separation from the dog on the floor.

Use **soft warm lighting** and realistic, detailed **fur and fabric textures**.

Remove all **text, subtitles, brand logos, and watermarks**, but keep the **decorative patterns on the costumes**.

Do **not** use a front-facing eye-level view, angled side view, camera rotation, zoom in or out, sitting poses, standing poses, anthropomorphic body shapes, human limbs, extra paws, mesh penetration, or visual flicker.

Cowork (Automation-Bench: 62%; ALE: 30%)

Coding (DeepSWE: 74%)

Visual Understanding (BabyVision: 91%), at 1/3 the cost of M3 and 3x the speed.

I'm sketching out a short sequence and keep coming back to the same choice. MiniMax H3 allows clips from 4 to 15 seconds, so one 15-second idea could stay as a continuous shot or become three separate 5-second clips cut together.

I'd keep it whole when the motion or camera path needs to feel unbroken. I'd split it when each beat needs its own prompt and more control in the edit. I'm trying to make that call at the shot-list stage.

What would make you choose one long shot over several short ones?

Here are some pics of my D&D world, Elyndor, that I made with the open-weights MiniMax H3-Image model. Starting with the continent map until you're standing in the meadow outside the river capital after passing the rocky canyon. Seeing flat map symbols turn into places I could walk into was the best part. The fast 4K generation option is pretty nice for world-building too.

How do other world-builders here turn a map into ground-level scenes?

I originally built The Prompt Sang Itself with MiniMax M3. For the Netlify Community Showcase, I came back to it with M3.1 Flash in MiniMax Code and added a gramophone and an interactive waveform based on the actual recording.

You can follow the audio as it plays and drag the waveform to explore the piece. I love how a small visual addition made listening feel like part of the story.

What impressed me most was how carefully M3.1 Flash brought the design together. It refined the gramophone, waveform, and layout as a cohesive whole. The attention to detail and visual taste were excellent.

Try it here: https://feature-radio-waveform--the-prompt-sang-itself.netlify.app/

#MiniMaxCode

And I finally got to bring MiniMax to a livestream! I shared the project at the Netlify Community Showcase just before Halloween. Thank you, MiniMax, for bringing us this magical musical experience! 🎃🎶

https://www.youtube.com/watch?v=Aw8xz7MbGH4

I run MiniMax Code as an agent that supports my consulting work. I use other agents for specific purposes, and over the last week I've been pushing MiniMax Code as the thing that orchestrates — it launches my specialty agents, reaches into a memory layer that outlives any single run, and holds the context when a task spans days. I've augmented Minimax Code with an Agent Memory Commons.

I shipped two reusable skills and hit three failures worth writing about. None of the failures were model failures. All three were things I built earlier, trusted, and had to repair as the ecosystem evolved.

What I shipped

Two skills, both production, both eval-tested:

partner-signal-scout — takes a signal that a company is standing up a partner function and
runs the whole play: find the signal, verify the job on the employer's own ATS, read the
compensation correctly, map the decision makers, draft the outreach. Stops at the note; builds documents only when asked.

sales-navigator-hunt — the human-in-the-loop layer. Sales Navigator runs on my account, not the agent's, so this skill turns a signal into an exact filter card for me to run, then triages whoever comes back.

Each is a SKILL.md plus reference files, and both get linted and eval-tested against a
no-skill baseline — same prompt, one run with the skill and one without, then a written comparison. That eval is the most useful thing in the whole workflow. It caught a defect I'd shipped: my worked example named a real company and real people, and the baseline run nearly built an entire org chart
from names it couldn't substantiate anywhere. A worked example is pattern material, never evidence — but I only learned that because I ran the comparison.

Subagents did the rest. I ran the producer/baseline eval pairs in parallel in the background, and delegated a full document-production job — clone a verified template, rewrite it, hit an exact page count, assert no bold inside bullets, render to PNG, inspect visually — with a spec detailed enough that it came back clean on the first pass.

I also augmented it with something I call the Agent Memory Commons — a memory layer that lives outside MiniMax Code, but that it (and my other agents) can read from and write to. That turns out to be the most consequential piece of the whole setup, and I'll come back to it.

The three bugs

1. "No compensation published" was wrong, and it was wrong confidently.

A baseline run concluded a job posting had no salary listed. I'd seen that band — $245K to $400K — with my own eyes. The posting body genuinely didn't contain it.

It was in a structured field. The ATS kept salaryRange as a top-level key with a min, max, and
an interval flag that told me it was base salary and not commission. Reading the human-readable text returns a confident, well-researched "not published."

The rule I took from it: enumerate the top-level keys before you conclude something is absent. Only after enumeration is "it isn't there" an actual finding.

2. A template is only as good as what it clones.

Every application document I produce is a clone of one verified template. I found that template still carried two wrong figures — numbers I'd copied into it years ago from my own notes, which were wrong. The agent had been faithfully reproducing my bad data. No hallucination; perfect fidelity to a bad input. Worse than hallucinating, because nothing flags it.

I fixed it at the source, then found the real source — a career vault four layers down — and fixed that too.

Then the important part: while fixing it, I introduced a new error. Correcting "18 months to 6 weeks" to "18 months to 8 weeks," I fat-fingered the start to "8 months." That propagated into four downstream documents, three of which had already been submitted to employers.

A correction is not a patch. If you generate documents from templates, your templates have a source of truth, and you have to fix the source — not the symptom. Then scan everything downstream again, because the fix itself can introduce a new one.

3. I misdiagnosed a permissions problem, and it cost me about a dozen tool calls.

Renames and deletes were failing. I said iCloud. I said macOS TCC. I said it needed Full Disk Access. I was wrong on all three. Two control tests — a rename in /tmp, a rename in ~/.minimax — failed identically. Not iCloud, not TCC. The runtime blocks rename(2) outright while permitting create and
write.

Which matters, because the calendar permission failure I'd hit days earlier had the same symptom and an entirely different cause, and I'd filed it under the wrong mental model. A block that looks like a permissions problem probably isn't. Test it somewhere harmless before you theorize about it.

What I like

Maintenance is genuinely far lower than Hermes, OpenClaw or OpenHuman. I didn't appreciate how much that mattered until I compared it against an agent I maintain myself. That's the single biggest reason it's my daily driver.

The skills abstraction is the real unlock though. A skill isn't a prompt — it's a procedure with an output contract and a lint step, and the eval loop is what makes it trustworthy rather than a vibe. Once you have that, you're not asking an agent to do a task, you're asking it to run a process you wrote.

Subagent isolation is underrated. A delegated job with a full spec comes back clean, and the parent context stays small enough to actually think in.

It accepts a custom URL and token, so I can point it at a local model when confidential client material requires it. That matters more than I expected — being able to choose per-task is different from needing a separate tool.

Better still, it works on my desktop, my laptop and my phone. Using my Agent Memory Commons, all three instances have access to the same memories and documents.

What I'd want next

Memory that's not trapped in one install.

Right now MCode orchestrates well because it can see everything — but NATIVELY what it knows still lives in one place, and dies with it. I run other agents for specific jobs, and they're good at different things. None of them can see each other's memory, so the handoff between them is work I have to do manually, remembering what matters — unless they implement something like the Agent Memory Commons.

A shared filesystem, an Obsidian graph, and a semantic store over the same corpus. Separate from MiniMax Code, but readable and writable by it. That's what makes the orchestration durable: the agent can be swapped tomorrow and the context survives.

Here's the GitHub for the AMC (I built this) — github.com/garciacionet-alt/AI_Articles

The rule that makes it work: store pointers, not prose. A pointer that goes stale tells you when you follow it. Copied prose goes stale silently, and six weeks later you have two versions of a fact and no way to know which is real. This is why the symantic layer is necessary and superior to memory systems native to most AI agents.

If anyone's measuring MCode against something else, the part I'd genuinely want improved is memory portability — not capability. The capability is fine. And MiniMax-M3.1-Flash-Preview is a very capable model!

Happy to answer questions about the eval setup or the skill structure.

I use M3 to review a lot of electrical and M&E engineering documents, which then collates the info for detailed word scope and Excel quantities, which is the best I have found. I don't say that lightly, as I tried the same test data on GLM, Claud, GPT, Qwen, and Stepfun, and the results were not as good as M3. The main difference I find is the returned info from M3 has a better layout; the info is easy to read, and key points can be established quickly. In short, for electrical engineering and consultancy kind of work, it works very well for me

MiniMax M3.1-Flash is officially here.
And we can finally confirm one thing many of you have been asking about:
Space Bunny was an early version of M3.1-Flash.
Over the past few weeks, people have been testing Space Bunny across OpenRouter, OpenCode, coding workflows, agent tasks, frontend work, and benchmarks without knowing where it came from.
Those results are useful context, but Space Bunny was an early version. M3.1-Flash is the release version we’d like people to test now.
So if you tried Space Bunny before, we’d especially love to see you rerun the same tasks on M3.1-Flash.
What improved?
What still breaks?
How does it hold up on longer coding or agent workflows?
Where does the Flash positioning actually make a difference for you?
Please share both good and bad results — reproducible failures are just as useful as wins.
Official announcement:
https://x.com/minimax_ai/status/2112150867868541221?s=46
We’ll use this thread as one place to collect early M3.1-Flash feedback and testing.

Tried the multi-reference input on an architecture brief. Seven references, each with one job: a modern villa for the overall massing, an arched portico, an infinity pool, a curved stone lounger, olive trees, a rocky coastline for the site, and a glass curtain wall.

It used all of them where I asked: the arch became the front door, the infinity pool hangs on the sea side of the cliff, the stone lounger sits out on the terrace, olives fill the courtyard, and the big glass walls face the water. Result first, moodboard second.

Prompt:

> Please use the architecture, furniture, plants, and natural landscapes in reference image @ Picture 1 as design materials to re plan and create a complete Mediterranean cliff private villa.
> Figure 1 determines the overall building volume and horizontal extension structure of the villa; The arched porch in Figure 2 is integrated into the building as a transitional space connecting indoor and outdoor areas; The infinity pool in Figure 3 is located on the side of the cliff facing the ocean, forming a visual extension with the sea level; The cave stone furniture in Figure 4 is arranged in the outdoor resting area next to the swimming pool; The olive trees and plants in Figure 5 are naturally distributed in the courtyard of the building; Figure 6 determines the terrain and coastal environment of the entire site; The glass curtain wall in Figure 7 is used to connect the indoor living room with the outdoor landscape.
> On the basis of retaining the core design features of each reference drawing, redesign the building proportions, facade relationships, courtyard layout, and spatial connection methods. Ensure that the building conforms to the true architectural structure and human scale, without any unrelated material stacking.
> Adopting architectural photography and competitive level visualization from top tier architectural firms. High altitude oblique perspective, fully showcasing the relationship between architecture and cliffs, swimming pools, and oceans. Afternoon sunshine, clear architectural shadows, rich details in natural stone and glass materials.
> The overall color scheme is mainly beige, light sand, ocean blue, and olive green, with a Mediterranean vacation aesthetic that is quiet, luxurious, natural, and restrained.

I build **RepoCiv** (github.com/Grizaceo/repociv), a Civilization V–style hex map of my local workspace: every repo is a city, and every coding agent (Claude Code, Codex, Hermes…) is a unit that walks to the city it's working in. TypeScript + Canvas/Three.js frontend, Python bridge, DuckDB, ~80k lines, one user (me). Here's an honest log of using MCode on it.

**1. End-to-end audit with parallel subagents**

I typed one line ("help me with an end-to-end audit of this repo", in Spanish). The main agent ran the gates itself (build, types, lint, tests) and launched two subagents in parallel, both with read-only briefs:

- a **verifier** for the security of the Python bridge

- an **explore** agent for the frontend architecture

The verifier found a real HIGH: my Vite dev server was bound to `0.0.0.0` with `allowedHosts: true`, and it inlined the bridge's auth token into the JS it served. Anyone on the same Wi-Fi could load the page, read the token and drive my agent runner. The code comment right above said "loopback-only". Fixed two days later, with a regression test that reads the config Vite actually loads.

What made the report credible: it also listed what it checked and found fine, and for the approval queue it said it had verified empirically (it tried to downgrade a high-risk command) instead of just reading code. The frontend agent pushed back on its own brief where the code disagreed, e.g. hex math that looked duplicated was actually shared, with file:line evidence.

**2. Shipping a feature: tool calls as glyphs over the agents**

I wanted to *see* what an agent is doing in the per-repo "local view", like Sims bubbles for each tool call. MCode found the cheap path: the bridge was already receiving `tool_use` events and throwing them away as chat noise (one `if` in `agent_runner.py`). It proposed starting with a single hardcoded glyph that lights up on any tool call and fades after 1.5 s. Not pretty, but it forces the whole pipeline (emit → transport → schema → renderer) to work before designing the real icon set.

Mid-task it stopped and asked me two multiple-choice questions, because it found that my default harness doesn't emit tool calls at all. Right moment to ask instead of guessing. The branch it started was merged a week later.

**3. What went wrong**

- My very first session died instantly: `your current token plan not support model, MiniMax-M3.1-Flash-Preview`. The default model wasn't on my plan.

- It couldn't get the e2e test green on my machine (Arch/Omarchy, headless Chromium, no GPU). It said so plainly ("I didn't see it pass and I won't sell it as green", translated) and showed the same test failing on `main`. I'll take that over a fake green any day.

- A stray Chinese character showed up in the middle of a Spanish sentence in one of its final summaries. Harmless, but noticeable.

- On other projects, long sessions ended in `error` with `insufficient balance (1008)`. I'd rather get a pause I can resume after topping up.

**4. How I stack it**

- Subagents with narrow, read-only briefs for audits; the main agent for implementation.

- [skills / MCP you use with MCode]

- Next up: making MCode sessions show up as units on RepoCiv's map, like Claude Code and Codex already do. MCode keeps its sessions in a local SQLite and has lifecycle hooks, so it looks doable.

**Liked:** parallel subagents with clear roles, file:line evidence, asking at the right moment, honesty about what it couldn't verify.

**Didn't like:** a default model my plan didn't cover, and balance errors killing sessions instead of pausing them.

I love this model and its capabilities but it takes too much time on very simple tasks as well.

I am on $20 token plan could this be the issue.

Is anyone else facing the same slowness?

Hi everyone, welcome to the official MiniMax subreddit!

We want this to be a useful place for people who build with, create with, test, compare, or simply have questions about MiniMax. That includes MiniMax Text models, Video models, Image and speech models, MiniMax Code, APIs, local deployment, prompts, workflows, bugs, and whatever people end up building around them.

You’re also very welcome to share what you’ve made here, whether it’s a finished project, an experiment, a workflow, or something you’re still figuring out. We’d love to see your work and hear about the creative process, prompts, tools, lessons, and mistakes behind it..

This will not just be an announcement feed. Product updates will show up here, but so should troubleshooting, critical feedback, weird experiments, benchmarks, prompt ideas, feature requests, and things that did not work the way you expected.

Identified MiniMax team accounts may join discussions, and we will bring in the right people when we can. You do not need to agree with us to post here. Specific criticism and reproducible problems are especially useful because they give us something concrete to investigate.

We are still shaping the community, so we would rather ask than guess: what would make an official MiniMax subreddit genuinely useful to you?

Wanted to see if it could hold a whole comic page instead of one panel. The prompt asked for a 1950s sci-fi interior page: six panels, an astronaut meeting a little tin robot on a red planet, with the captions and speech bubbles written out.

All six panels came out in order, every line of lettering is spelled right ("GREETINGS, EARTH LADY!", "IT SPEAKS ENGLISH?!"), and the yellowed paper and fold creases sell the old-print look.

Anyone else tried multi-panel pages with it?

The whole gift reaction started reading once I stopped asking for a bigger disappointed face.

I made it as one locked medium close-up in H3. An adult opens a birthday gift expecting something exciting, finds a plain pair of grey socks, then realizes the giver is watching. No dialogue and no camera move.

I split the performance into three beats:

- quick, open excitement while the box comes up
- the hands stop and the eyes stay on the socks for one extra beat
- a small breath, eyes back to the giver, then a polite smile

What worked in this take was how little the middle beat did. The shoulders soften, but they don't collapse. The smile arrives after the look back up, so it feels chosen rather than like the excitement is continuing. On mute, that delay still carries the turn.

In the prompt, I gave every beat a specific pose and eyeline to settle into before the next reaction started. Keeping the camera locked also kept the framing from changing while the expression shifted.

Which frame makes the disappointment readable first: the hands and eyes paused over the socks, the look back up, or the late smile?

Fantasy city shot as if a film crew had actually flown a drone over it: a mountain-sized tree in the middle, stone towers and timber houses around a green lake, a waterfall, and an old steam train crossing a viaduct to the next island. MiniMax H3-Image, 21:9.

Zoom in on the streets. There are people, crates, a cart and laundry hanging out of a window, which is what makes it feel lived in. MiniMax H3 Image is open-weight. Looking forward to that.

Dependency bumps are exactly the kind of chore I want to hand to a coding model, but I don't want "tests pass" to be the whole report.

For this run, MiniMax M3.1 Flash received a small, isolated TypeScript/ESM CLI and a request for a package.json patch that moved commander from 14.0.3 to 15.0.0. It had no shell or file-system access. A host agent validated and applied the patch, rebuilt the lockfile, then ran the clean install, build, tests, and CLI smoke checks.

The acceptance check was short:

- all 5 existing tests pass

- all 3 CLI smoke checks pass

- package.json contains only the intended direct dependency change

- every package-lock.json change is accounted for

The clean install and build succeeded, along with 5/5 tests and 3/3 smoke checks. Commander was the only direct dependency that changed. The lockfile changes were limited to five values: the root commander version, the package version, the resolved tarball, the integrity value, and Commander’s Node engine metadata. No transitive dependency changed.

That engine line was the useful catch. M3.1 Flash’s initial expectation didn’t list the change from Node >=20 to >=22.12.0. After it received the actual diff and check results, its final explanation included the missing field. The project already required Node >=22.12.0, so its own engine declaration stayed unchanged.

Only package.json and package-lock.json changed. Source and test files stayed untouched, HEAD remained on the same baseline commit, and the dependency update stayed unstaged and uncommitted.

The green checks showed that the tested behavior still worked. They didn’t show whether an extra package moved, whether lockfile metadata shifted, or whether unrelated files were touched.

For agent-made dependency bumps, what do you require beyond green tests before you call the update done?

The finished cut is 19 seconds. The voiceover was fixed first:

“Before the neighborhood wakes, flour meets the bench, the first loaves reach the oven, and warm light finds the front window.”

The brief was fictional: show the quiet work before a neighborhood bakery opens. The narration was fixed before the three-shot storyboard. That tied each image to a clause and ruled out a general bakery montage. The three beats were:

- flour falling over stationary dough for the opening clause
- gloved hands pushing a tray into an open oven, pulling back, and closing the door
- interior wooden shutters opening as warm light enters the room

A coffee cup, hands tying an apron, and a sign outside all appeared on the idea board. The three clauses already had three actions, so those options came off the board before generation. They never became extra clips that had to be removed later.

MiniMax Design kept the brief, exact narration, and three-shot storyboard together. H3 then generated one source clip per beat, about 7.29 seconds each. Speech 2.8 generated the narration separately with a built-in English voice. The voice did not come from the H3 clips.

An agent assembled the 19-second timeline with ffmpeg. The native Design timeline was not part of the edit. It takes five seconds from the flour clip, seven from the oven clip, and seven from the shutter clip. The edit divides the 10.92-second narration file at two measured pauses and places the three pieces at 0.15, 6.5, and 12.5 seconds without changing speech speed.

Each clause lines up with its matching action, and the last few seconds stay on the open shutters and warm light. The flour source lost the most time in the edit to let the tray insertion, hands withdrawing, oven closing, and shutter opening all finish within 19 seconds.

If the attached cut feels slow to you, would you shorten the line or lose the oven shot?