3dicon: a Claude Code skill that turns one prompt into a looping animated icon

The tool is a Claude Code skill, not a library you call

3dicon is described as one prompt in, a looping animated 3D icon out, with real transparency, and the repository description calls it a Claude Code skill. The install section in the README makes the delivery mechanism explicit, with two commands:

/plugin marketplace add samyost1/3dicon
/plugin install 3dicon

The repository layout matches that framing. There is a `.claude-plugin/` directory at the root and a `skills/` directory that holds the actual skill, and the README links a banner image from `skills/3dicon/examples/`. The audience is therefore a Claude Code user, not a Python developer integrating a package, and the unit of work is a prompt rather than a function call. That distinction matters for expectations. There is no published PyPI package, no GitHub releases, and no API to call; what there is a skill that an agent can invoke, and a Python script underneath it that does the work.

One OpenRouter key covers both the image model and the video model

The setup has three steps after the plugin is installed, and the README says it plainly: one OpenRouter key covers the whole pipeline, because the image model and the video model both run through it.

cd ~/.claude/skills/3dicon
pip install -r requirements.txt
cp .env.example .env

Then you put your key in the `.env` file, in the form `OPENROUTER_API_KEY=sk-or-...`, and the README links openrouter.ai/keys for getting one. Two requirements are stated that are easy to miss. `ffmpeg` must be on PATH, and the first run downloads a roughly 180MB matting model. The second point is the interesting one, because a matting model is what removes the background from every frame, and 180MB on a first run is a real cost that the README does not hide.

The pipeline asks twice before it spends anything

The Use section explains the interaction model in two sentences, and it is the part of the design that makes this a tool rather than a script. You ask for it in plain words, for example making an animated 3d fire icon using /3dicon. It then generates one still, shows it, and waits for you to approve it before spending anything on motion. After that it proposes the motion and waits again. So there are two approval gates, one for the image and one for the animation, and the expensive part of the pipeline, the video generation, happens only after a human has looked at the still and agreed with it. For a tool that spends money per call, that ordering is the difference between a useful utility and a way to burn a credit card on nine bad frames.

The same still is both the first and the last frame

The How it works section gives a mermaid flowchart, and the README explains the central trick in one line. The flow runs from your prompt to a still image, which is then used as both the first frame and the last frame of a video model call, and the result is passed through background removal on every frame to produce an animated WebP with real alpha. The trick is in the middle: the same still is sent as both the first and the last frame, so the model returns to where it began and the loop closes with no visible seam. That is a small piece of engineering with a large payoff. A generative video model given a start and an end image will interpolate between them, and asking it to return to the original start image is what makes the result usable as a loop with no visible join rather than a clip that has to be cut.

Background removal against a chosen colour is why edges stay soft

The README explains the second technical decision, and the reasoning is more interesting than the result. The background is removed against a colour we chose ourselves, which means the original colours can be solved for exactly rather than guessed, and that is what keeps soft edges soft instead of leaving a halo. A naive approach removes the background by classifying each pixel as foreground or background, which produces a hard mask and a fringe of the background colour around every soft edge. Choosing the background colour in advance turns the removal into an arithmetic problem, where the contribution of the known background can be subtracted from the observed pixel to recover what the foreground colour was. It is the same class of trick that a green screen plays in live action, applied with exact arithmetic instead of a camera.

Where 3dicon is the wrong tool

Two limits follow directly from the design. The first is duration and shape. A looping icon is by construction one still and one clip that returns to its origin, so anything that needs to travel, change state, or loop through several distinct poses is outside what the pipeline can produce, and a prompt asking for a walk cycle or a loading spinner with multiple phases will not get it. The second is the dependency chain. Two hosted models behind one key, a local matting model of roughly 180MB, ffmpeg on the PATH, and a Python environment set up by hand in a directory inside the Claude skills folder. That is a reasonable amount of setup for a designer or a solo developer, and a poor trade for a build server that needs to produce a hundred icons reproducibly. The project is also quiet about failure modes, since the README does not discuss what happens when the video model returns a clip that does not actually return to the still.

Generated icons are yours, which is unusual for a hosted pipeline

The Licence section is short and worth quoting. It is MIT, and the icons you generate with it are yours, with no restrictions. That is a real statement to make about a tool whose output is produced by a third party image model and a third party video model, and it is the kind of term that would otherwise need checking in the terms of those services. The repository itself is MIT licensed with the LICENSE file at the root, the default branch is main, and the last push was on 2026-09-23. The project publishes no GitHub releases, so there is no versioned artefact to point at, and the practical lifecycle is a skill directory on your machine that you install and update by re-running the plugin commands.

Editorial conclusion

3dicon fits a developer building an app who wants a small set of animated 3D icons without commissioning an artist, and who is happy to have an image model and a video model called on their behalf. It is the wrong tool if you need more than a short loop, since the whole design is one still plus one clip that returns to where it began, and it is the wrong tool if you cannot run ffmpeg or accept a roughly 180MB model download on first run. Before you use it, read the approval flow carefully, because the tool deliberately stops and asks before it pays for motion, and check the licence position, which is that generated icons are yours with no restrictions.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. samyost1/3dicon on GitHub