motion-anything: a chat-native motion engine for agent-driven animation

The gap motion-anything is aiming at

Motion work usually splits into two jobs that never share a tool. A designer builds the animation in a timeline editor, exports a file, and hands it to an engineer who rewires it into the page. The handoff is where intent dies: the spring that felt right in the editor becomes a cubic-bezier someone guessed at. motion-anything attacks that handoff directly. The pitch in the README is one sentence: describe the feeling, and your AI ships the animation. The intended user is not a motion designer. It is a front-end or product engineer who already has a coding agent open and wants a hero animation, a card entrance, or a launch video without leaving that context. The project ships 403 curated motion recipes and 230 portable skills, which is the part that makes the chat loop plausible: the agent is not inventing easing curves from nothing, it is selecting from a catalog the project already vetted. The second half of the pitch is where it differs from a generator. You edit motion on the running page, component by component, with a keyframe editor and spring easing. Generation is the entry point, not the product.

How the agent, the recipes and the page fit together

The architecture visible in the repository is a local-first engine wrapped by agent CLIs. The README lists 8 coding-agent engines plus BYOK: Claude Code, Codex, Cursor, OpenCode, Grok Build, Hermes, Gemini and Open Design Cloud. The engine does not ship its own model. It routes your prompt to whichever CLI you have configured, and the agent picks recipes from the library and writes motion into the page. The repository layout backs this up: a cli/ directory, an app/ directory, and a recipes/ directory split by surface (recipes/web/ for page effects, recipes/slides/ for kinetic text). Each recipe is standalone. The README states the showcase tiles run with two script tags on any page, with no React, no three.js and no build step, which is a deliberate constraint rather than an accident. The motion vocabulary is bounded on purpose: 4 triggers, 13 motion verbs, spring easing. MOTION-SPEC.md at the repository root is the document that defines those verbs, and it is the file to read before trusting the output. Export targets are JSON, CSS, React, Lottie, MP4 and GIF, so the engine is positioned as a producer for other pipelines rather than a runtime you must keep.

Installing motion-anything and animating one component

The README advertises a one-command quickstart and zero npm dependencies, and the repository has a cli/ directory, but the README excerpt does not print the exact install command. Treat the CLI entry point as the thing to confirm in the repository before you script anything around it. What the material does document is the recipe path: a recipe lives under recipes/web/<name>/ and is meant to run from static files. If you want to see the engine's output before wiring an agent, start with the smallest kinetic-text recipe and load it directly.

ls recipes/web/shiny-text/

The recipe directories are self-contained, so listing one tells you what the two script tags actually point at. The README describes shiny-text as a sheen that sweeps across text-clipped gradient type, applied with one class. The 4 triggers and 13 motion verbs are the knobs an agent sets when it writes motion into a component; MOTION-SPEC.md is where those names are defined, and the agent output should be checked against it. For a launch video rather than a page effect, the README points at 58 HyperFrames video templates and a document called HTML-TO-VIDEO.md, which describes the route from an HTML prototype to MP4 or GIF. Export is the last step: JSON, CSS, React, Lottie, MP4 or GIF. If your target is a React codebase, the React export is the one that matters, and the CSS export covers the case where you want the effect to survive without the engine.

Where motion-anything is the wrong tool

The engine is chat-native, which means the quality of the output is bounded by the agent you point it at. The README lists 8 engines plus BYOK, so an unconfigured install has no model behind it. If your team has no coding-agent subscription and no API key, the core loop does not run, and the recipes alone are just a static effects library. The second constraint is determinism. A timeline tool produces the same curve every time you open the file. A prompt-driven engine produces a result that depends on the model, the recipe it picked, and the wording you used. For a marketing hero that is fine. For a product animation that must match a spec frame for frame, it is the wrong shape. Third, the project is at v0.1.0, released on 2026-07-06, and the last push to main was on 2026-07-07. That is a young codebase with a single release, and the README does not document rollback or version pinning for exported motion. If you need a frozen artifact you can diff in review, export to JSON or CSS and commit that, rather than regenerating.

How it differs from Figma-based motion and from Lottie pipelines

The README positions the project as a figma-motion-alternative, and the difference is structural rather than cosmetic. In a Figma motion workflow, the canvas is the source of truth and the export is a snapshot. In motion-anything, the prompt and the recipe are the source of truth, and the page is where you edit. That inverts who owns the file. A Lottie pipeline sits at the other end: it assumes a designer produced a vector animation in After Effects or a similar tool, and the runtime plays it back. motion-anything produces Lottie as one of six export formats, so it can feed that pipeline, but it does not replace the authoring tool that makes hand-drawn vector motion. The closer comparison is a WebGL or canvas effects library, and there the difference is the catalog plus the agent. The recipes are curated and dependency-free by design, and the agent's job is selection and wiring rather than synthesis. If you want a library you call by name from code, a plain effects library is simpler. If you want a sentence to become a wired-in effect, the agent layer is the whole point.

Licence, ecosystem coupling and what an upgrade costs

The licence is Apache-2.0, which permits commercial use and modification, and the README states there is no watermark and no per-render fee. That matters for video output: MP4 and GIF export without a per-render charge changes the economics of a launch-video workflow, since you are not metering renders. Apache-2.0 also means the attribution obligations are the standard ones, and the repository carries an ATTRIBUTION.md and a SOURCES.md, which suggests the recipe library includes ported work with its own provenance. Read those two files before you ship a recipe in a commercial product, and treat that as a provenance check rather than a legal opinion. On upgrade cost: the project is wired into the Open Design ecosystem, with 59 DESIGN.md brand packs, 58 HyperFrames video templates, 112 HTML prototype templates and 2,680 icons. That coupling is the value and the risk. The recipe library is the thing most likely to change between releases, and because recipes are plain files under recipes/, an upgrade can be reviewed as a diff rather than a black box. The engine list is the other moving part: 8 CLIs plus BYOK means an upgrade can change which agent backends are supported.

Editorial conclusion

Adopt motion-anything if your team already runs a coding agent and wants motion work to happen in the same chat loop, with exported JSON, CSS or React as the deliverable. Skip it if you need a deterministic timeline tool with a stable API surface, or if you cannot supply an engine key. Before committing, open MOTION-SPEC.md to see what the 13 motion verbs actually mean, check the recipe folder for the effect you need, and confirm which of the 8 engines you can authenticate against.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. nexu-io/motion-anything on GitHub
4. README
5. Releases