HyperFrames and Clipkit are the two tools built explicitly for the same future: AI agents that author finished video. HeyGen's HyperFrames bets on HTML: write a self-contained HTML/CSS/JS page, play its timeline in a headless browser, encode the frames to a file. Clipkit bets on data: a JSON document in an open protocol, validated against a schema, rendered by a GPU engine in a browser tab or a render job.
Disclosure up front: we make Clipkit, and we benchmark against HyperFrames precisely because it's a serious, well-built competitor. Every number below comes from our published corpus (rerunnable from the open repo), and there's a real section on when HyperFrames is the better pick.
What HyperFrames gets right#
Credit first, because it's earned. HyperFrames is genuinely open source (Apache 2.0, the whole framework), free to run with no credits or tiers, and its core insight is strong: the web platform is the most expressive rendering engine ever shipped, and every model has seen a billion HTML pages. An agent that can write a web page can, with HyperFrames, ship a video of it. CSS animations, web fonts, Tailwind, any JS library, actual rendered web content: the ceiling is the browser itself, which is to say, very high.
If the mental model sounds familiar, it's Remotion's bet without the React toolchain: author in web technologies, render frame-accurately through a headless browser. That's a real improvement in accessibility, and HeyGen shipping it open source moved the whole agent-video space forward.
The structural difference#
Both tools describe a video as a text artifact an agent can write. The difference is what kind of artifact, and what you can do with it before rendering.
An HTML page is a program the browser executes. It can express nearly anything, and nothing checks it beyond syntax: a page that parses can still render a blank div, overlap its captions, or animate the wrong element, and you find out by rendering it and looking. A JSON composition is data against a schema. It can express exactly what the protocol covers, and a validator checks the whole document before any rendering happens, returning errors an agent can act on ("elements.0.layer: Required").
That's the entire trade, stated neutrally: HyperFrames buys expressiveness and pays in verifiability. Clipkit buys verifiability and pays in expressiveness. Everything in the benchmark numbers falls out of that one exchange.
What we measured#
From our published corpus: 13 briefs implemented idiomatically in both tools, plus the 60-cell agent-authoring benchmark (5 briefs × 3 model tiers, real agent transcripts, every artifact validated and rendered).
| Metric | Clipkit | HyperFrames | Scope |
|---|---|---|---|
| Agent validity (valid video shipped) | 15/15 (100%) | 10/15 (67%) | 5 briefs × 3 model tiers, real transcripts |
| Authoring tokens (same video) | baseline | median 2.15× more (range 1.49–3.27×) | 13 briefs, idiomatic implementations |
| Agent-loop render latency | 13.4s median | 107.2s median | per-cell median 8.1× faster |
| Head-to-head cells | wins 13/15 | 2/15 | 8 decided on cost, 5 on validity |
| Cost per valid video | $0.89 median | higher on both-valid cells (Clipkit at 0.78×) | agent transcripts |
The validity gap deserves the plain-language version. One agent run in three on the HTML path produced something that didn't survive to a valid rendered video. Not because the models were worse (same models, same briefs), but because HTML fails silently: the page loads, the render completes, and the result is wrong in ways only eyes catch. The schema path converts those silent failures into loud, named, fixable errors before rendering. And the 8× render-latency gap compounds it: when checking your work takes 107 seconds instead of 13, agents check less often.
As always: our benchmark, our framing, public methodology. Rerun it before believing us.
When HyperFrames is the right choice#
- Your video is web content. An animated landing-page tour, a rendered data dashboard, anything where the fidelity you want is "exactly what the browser shows." HTML is the native format for that; a composition protocol isn't.
- You need the browser's full expressiveness. Arbitrary JS libraries, CSS effects the protocol doesn't cover, embedded web fonts and layouts. HyperFrames' ceiling is meaningfully higher than Clipkit's schema, the same way Remotion's is.
- You're in the HeyGen ecosystem. Avatar videos and HeyGen's hosted rendering pair naturally with it.
- Apache 2.0 end to end matters to you. The whole framework is open source with no commercial tiers. Clipkit's protocol and tooling are Apache 2.0, but our engine is source-available (BSL 1.1, converting per release after four years) with a free production tier. If that distinction matters in your evaluation, they win it.
When Clipkit is the right choice#
- Unattended agents. The 100% validity number is the argument: validate-first means a pipeline nobody babysits. At 67%, someone owns the failure queue.
- Iteration speed and cost. 13-second agent-loop renders and free frame previews mean agents check their work constantly. Free browser rendering means iteration never bills.
- End users touch the video. Every Clipkit composition opens in a free, no-login timeline editor in the browser, and users export MP4s client-side at no cost to you. HyperFrames renders through a headless browser you run (or hosted rendering you pay for); there's no equivalent hand-a-user-a-link editing surface.
- Videos as structured data. Granular, targeted edits ("patch this element's start time") beat regenerating or string-editing HTML. Documents diff cleanly, store in database rows, and re-render deterministically: same document, same bytes, browser preview and cloud render alike.
- Token budgets at volume. A 2.15× median authoring-cost difference is noise for ten videos and a line item for ten thousand.
The same video, both ways#
A title card, headline sliding in. In HyperFrames, it's a page:
<div class="scene" data-duration="4"> <style> body { background: #181717; margin: 0; } h1 { color: #FFB800; font-size: 96px; margin-top: 400px; margin-left: 100px; animation: slide 0.7s ease-out forwards; } @keyframes slide { from { transform: translateX(-300px); } } </style> <h1>SHIP FRIDAY</h1> </div>
In Clipkit, it's a document:
{ "width": 1920, "height": 1080, "duration": 4, "frame_rate": 30, "output_format": "mp4", "elements": [ { "type": "shape", "shape": "rectangle", "layer": 1, "width": 1920, "height": 1080, "fill_color": "#181717" }, { "type": "text", "text": "SHIP FRIDAY", "layer": 2, "x": 100, "y": 400, "font_size": 96, "fill_color": "#FFB800", "animations": [{ "type": "slide-in", "direction": "left", "duration": 0.7 }] } ] }
Both are readable, both are agent-writable, and the HTML version will feel more familiar to more people. The difference shows up in what happens next. Ask "is the JSON valid?" and a schema answers definitively before rendering. Ask "is the HTML right?" and the honest answer is "render it and look." Ask for a revision ("start the slide half a second later") and the JSON change is one field in one element; the HTML change means locating and editing the keyframe rule, hoping nothing else in the cascade depended on it. Multiply by a few hundred videos and a few thousand revisions and the two artifacts stop feeling similar.
Operating each in production#
Both frameworks are free to run locally, which is genuinely unusual in this space and worth appreciating. The operational difference is what rendering costs at each stage. HyperFrames renders through a headless browser: CPU-bound per frame, on hardware you run (your machine, your CI, Lambda, or HeyGen's hosted rendering when you want it managed). Every render, draft or final, uses that pipeline.
Clipkit splits the render surface. Iteration happens free (schema validation in milliseconds, single-frame previews, full renders in the user's browser on WebGPU), and paid compute enters only for unattended cloud renders and professional formats. For an agent product where users see or export video in-app, the client-side path also means your render infrastructure is literally your users' browsers: no farm, no queue, no per-render line item.
Running both#
Nothing about these tools is mutually exclusive, and the teams furthest along in agent video often split by workload. Videos that are fundamentally web content (a product-tour capture, a rendered dashboard, anything where browser fidelity is the point) go through HyperFrames. Structured, volume-shaped video (announcements, changelogs, captions, data visualizations, personalized variants) goes through the schema path, where validation keeps unattended runs at 100% and revisions stay cheap. The formats don't interoperate directly, but agents don't care: the same brief routes to whichever substrate fits, and both artifacts live happily in the same repo.
The deeper pattern#
HyperFrames and Remotion are the same bet at different levels of the web stack (raw HTML vs React), and both inherit the same failure mode: the artifact is a program, so correctness is only observable at render time. Clipkit and JSON2Video are the other bet (video as data), and they diverge on openness and where rendering happens. If you're mapping the whole space, that's the two-axis version: program vs data on one axis, open vs proprietary and local vs metered on the other. Our full comparisons of the others: Clipkit vs Remotion, Clipkit vs JSON2Video, and the Remotion alternatives roundup.
The one-afternoon test, as ever: take a brief you'd give your agent, run it through both (HyperFrames is a npm install away; the Clipkit MCP server is one config line), and compare what survives to a finished MP4 without your help. That test is the whole benchmark, miniaturized, on your workload instead of ours.