HyperFrames: rendering HTML scenes to MP4 for coding agents

The problem: agents can write HTML, but not a video timeline

Coding agents are good at producing structured text and markup. They are bad at driving a timeline-based compositor, because a timeline is a stateful GUI model that has to be opened, scrubbed and exported. HyperFrames takes the opposite route: the scene is HTML, CSS, media elements and animations that can be seeked to a given time, and the output is an MP4. The README describes the project as a framework for turning HTML, CSS, media, and seekable animations into deterministic MP4 videos, usable locally with the CLI, from AI coding agents with skills, or as the rendering core behind hosted authoring workflows.

That framing tells you who it is for. The primary user is an agent or a developer wiring an agent into a video pipeline, not a motion designer working frame by frame. The word deterministic matters here: if the same HTML produces the same frames, an agent can lint a composition, render it, look at the result, and change the source. A tool where rendering depends on wall-clock timing breaks that loop. The README also states the project is built for agents in its tagline, which is a positioning claim rather than a technical one, but the skills directory and the plugin folders for Claude, Codex and Cursor back it up.

How the monorepo is wired: packages, skills and a manifest

The repository is a Bun workspace monorepo. package.json declares workspaces under packages/*, and the build script chains filters in a deliberate order: parsers, lint and studio-server first, then core, then engine, producer, player, studio, shader-transitions, aws-lambda, gcp-cloud-run and sdk, and finally cli and sdk-playground. That ordering is the dependency graph in disguise, and it is the most useful thing in the file for anyone trying to understand the architecture without reading source.

The second structural layer is the skill pack. skills-manifest.json and the skills/ directory hold 20 skills that agents load on demand. The README describes /hyperframes as the router and capability map, and lists creation workflows such as /product-launch-video, /faceless-explainer, /pr-to-video, /embedded-captions, /talking-head-recut, /motion-graphics and /music-to-video. Each workflow carries its own scope note: product-launch-video is capped at roughly three minutes with a 30 to 90 second sweet spot, while motion-graphics is described as short, unnarrated and under about ten seconds. Those are authoring constraints, not renderer limits, and they are the kind of thing that only shows up in the skill descriptions.

The third layer is deployment. examples/aws-lambda/, examples/gcp-cloud-run/ and examples/k8s-jobs/ exist as top-level example directories, and the build script includes dedicated filters for @hyperframes/aws-lambda and @hyperframes/gcp-cloud-run. So the intended production shape is a render job on managed compute, not a laptop export.

Installing HyperFrames and rendering a first clip

There are two entry points and the README treats them differently. The agent path installs skills; the local path uses the CLI. Start with the skills install, which is the one the README puts first.

npx skills add heygen-com/hyperframes

The README warns that the picker opens with nothing pre-selected and that the Core Skills group is all you need, because the /hyperframes router installs each creation workflow on demand. For a non-interactive or agent run, the README says to use a different command, since a bare skills add without --skill installs all 20.

npx hyperframes skills update

That command installs exactly the core set from the current main. The README notes that skills add resolves the skills.sh registry blob, which can lag main by hours, so the update command is the one to reach for when you need the newest copy of a skill. Installing a single skill by name uses a bare name with no leading slash.

npx skills add heygen-com/hyperframes --skill product-launch-video

For local development, .env.example states that no environment variables are required for basic usage, and points at two commands: bun run dev to start the studio, and npx hyperframes render to render video. The only optional variable listed is GEMINI_API_KEY, described as AI image captioning during website capture at roughly $0.001 per image.

bun run dev

The studio is the dev server for the studio package. What you should expect after these steps is a running local studio, a core skill set installed, and a render command that produces an MP4 from a composition. The README does not document the render command's flags in the excerpt available here, so treat npx hyperframes render as the documented entry point and read the CLI package for options.

Where the agent workflow gets awkward

The install story has a real seam in it. The README admits that skills add resolves a registry blob that can lag main by hours, which means two developers running the same documented command on the same day can end up with different skill files. The workaround exists, but you have to know it, and the failure mode is silent: the agent simply behaves according to an older workflow.

The second seam is the interactive picker. The README states plainly that the picker is interactive-only and that a non-interactive or agent run without --skill installs all 20 skills. That is a surprising default for a tool whose headline audience is agents, and it cuts against the project's own advice to keep installs lean. If you are running this inside CI or a container, the bare command is the wrong one.

The third constraint is scope. The skills encode length budgets: product-launch-video tops out around three minutes, motion-graphics sits under about ten seconds. Those ceilings come from the authoring workflows, and nothing in the README suggests the renderer refuses longer output, but a team expecting to produce a twenty-minute explainer through the documented skills is working against the grain of the design. For long-form or heavily composited work, a timeline-based tool remains the better fit.

HyperFrames compared with Remotion

The comparison people search for is HyperFrames versus Remotion, and the difference is architectural rather than cosmetic. Remotion is a React framework: compositions are React components, and the developer writes JSX against a React render pipeline. HyperFrames is described as taking HTML, CSS, media and seekable animations, which means the authoring unit is a document rather than a component tree. An agent that can write HTML can produce a HyperFrames scene without knowing React at all, and that is the whole point of the design.

The second difference is the delivery model. HyperFrames ships a skill pack with a router and named creation workflows, plus plugin directories for Claude, Codex and Cursor. The README's own example prompt is an instruction to an agent rather than a code sample: asking for a ten-second product intro with a fade-in title, a background video, and subtle background music. Remotion's ecosystem is oriented around developers writing and versioning components. If your team already has a React codebase and wants compositions to live beside application code, Remotion fits that shape. If your team wants an agent to go from a brief or a URL to an MP4 with HTML as the intermediate representation, HyperFrames is the one designed for it.

Licence, release cadence and what upgrades cost

HyperFrames is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is a permissive licence, and it is a meaningfully different posture from a source-available licence with revenue restrictions. This is not legal advice; if you are embedding the renderer in a product, have counsel read the LICENSE file rather than a summary.

The release record shows v0.8.15 on 2026-08-26, v0.8.16 on 2026-08-27 and v0.8.17 on 2026-08-28, with the last push to the repository on 2026-08-28. Three releases in three days is a fast cadence, and the version prefix is still 0.x. The practical cost of that cadence is upgrade churn: a monorepo with this many packages and a chained build script means a version bump can touch parsers, core, engine and producer together. The repository carries scripts named verify:packed-manifests, validate:release-channel, set-version and release:prepare, which suggests the maintainers have automated part of that work, but the automation is for them, not for you.

Pin the version you adopt. The repository publishes no changelog entry explaining what changed between v0.8.15 and v0.8.17, so budget time to read releases/ before moving a production pipeline forward.

What to check before you commit a pipeline to it

Three things are worth confirming on your own machine before you build on HyperFrames. First, the build toolchain: package.json uses Bun workspaces and every script is invoked through bun run, so your CI image needs Bun, not just Node. The README's badge links to nodejs.org, and the repo ships a Dockerfile.test, but the build itself is Bun-driven.

Second, the skill install path. Run npx hyperframes skills update and confirm the core set lands where your agent expects, then check whether your agent of choice (the README names Claude Code, Cursor, Gemini CLI and Codex) picks up the router skill. If the agent cannot see /hyperframes, none of the creation workflows will trigger.

Third, the render output. The README's claim is deterministic MP4 from seekable animations. Determinism is the property your pipeline depends on, and it is the one to verify with your own compositions rather than assume. Render the same scene twice and compare. The repository documents no determinism test harness, so this check is on you.

Editorial conclusion

Adopt HyperFrames if your video work is generated from a brief, a URL or a pull request and you want the authoring step to be plain HTML that an agent can lint and re-render. Skip it if you need a mature compositing timeline, a large third-party plugin ecosystem, or you are unwilling to pin a version in a repo that shipped v0.8.17 on 2026-08-28. Before committing, verify two things: that the Bun-based build in package.json resolves on your CI image, and that the skills you need install from the current main rather than the lagging registry blob.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes