I Ran Anatomy's /anatomy Skill on a 1.7B Local Model. The Kit Passed Every Check; the Figure Was 738 Bytes.

Anatomy went from a new repo on 8 October to 6,632 GitHub stars by Tuesday morning, 13 October (I checked the GitHub API at 10:31 AM IST). It's an MIT-licensed Agent Skill for Claude Code that also runs in OpenCode, Codex and, as of this week, Antigravity. You type /anatomy plus an idea, and the agent is supposed to invent a physical machine whose working is that idea, then build it as an interactive isometric SVG figure out of dozens of small shaded parts.

The demos are lovely: a Raptor engine that comes apart into 11 assemblies, a ripple tank with WebGL caustics, a dial gauge you can slide. I wanted to know two things the demos can't tell me. Does the machinery underneath actually hold up on a plain Linux box? And how much of the result is the skill, and how much is the model driving it?

Short version: the kit is real, fast and honest about itself. The skill, though, is written for a strong model, and a small local one doesn't come close. Here's exactly what I ran.

What I tested and what I didn't

The box is Debian with 8 vCPUs, 16 GB of RAM (about 4 GB free during the test) and no GPU. There was no Claude Code, no Codex and no cloud API key on it. So the agent was OpenCode 1.19.0 pointed at a local qwen3:1.7b through Ollama on CPU.

I tried to pull qwen3:4b as a step up. The download failed on this box's network ("redirect target not allowed"), so 1.7B was the only model I could run.

That shapes everything below. I tested:

• The install path, with the skills CLI the README recommends
• The kit on its own: building the examples, the test suite, the geometry audit, and the headless-Chrome checks
• Three real /anatomy prompts in OpenCode, taken from the README and the skill's own evals

I did not test Claude Code or Codex, or any frontier model. I also skipped the React output, the 3D (beta) mode, the WebGL figures driven by an agent, and the new community-gallery publishing flow. The figures in the README were almost certainly made with a much stronger model than mine, so please read the agent results as "what happens at the bottom end," not as a verdict on the skill.

Install: one Node catch and a different folder

The README's quick start is one line:

npx skills add wheresryan22/anatomy -g -a opencode -y

On the box's Node 20.19.2 it crashed immediately:

npm WARN EBADENGINE   required: { node: '>=22.20.0' }
SyntaxError: The requested module 'fs/promises' does not provide an export named 'glob'

Anatomy itself only needs Node 20.10+, but the skills CLI (1.7.2 here) needs 22.20+. The README does mention this in a collapsed section, but it's easy to miss. On Node 22.20.0 the same command finished in 7.6 seconds. It showed a security summary ("Gen Safe, Socket 0 alerts, Snyk Low Risk") and copied 13 MB.

One surprise: it installed to ~/.agents/skills/anatomy, not ~/.config/opencode/skills/anatomy as the README's install table lists for OpenCode. OpenCode found it anyway, since it also reads the .agents folder:

opencode debug skill
# ... "name": "anatomy", "location": "/home/box/.agents/skills/anatomy/SKILL.md"

The kit on its own: fast, deterministic, and it checks itself

Before involving any model, I ran the parts that don't need one. This is where Anatomy impressed me most.

The examples rebuild from Node scripts with zero npm dependencies:

node examples/dial-indicator/build.mjs
node examples/desk-computer/build.mjs
node examples/arcade-cabinet/build.mjs
git status --short     # empty

All three exited 0, and git status was clean afterwards. The rebuilt pages were byte-identical to the committed ones, which is exactly what CONTRIBUTING promises. The Raptor engine, the heaviest example, took 115 seconds to build, in line with the README's "a few minutes."

The test suite ran 225 tests in about 38 seconds:

# tests 225
# pass 220
# fail 5

All five failures were react-*.test.mjs files that require React, which isn't installed. The README says React is only needed for React output, so this is a setup gap rather than a bug. I'd still like those tests to skip cleanly instead of failing.

The geometry audit is the standout. It doesn't just render the figure. It proves that nothing passes through anything and that every overlap is painted in the right order:

$ node examples/arcade-cabinet/build.mjs --audit
audit · 15 tubes · 243 solids · 349 items · 1 depth states · 1290 overlaps · 1290 order rules · 11.0 s
audit passed

The headless-Chrome checks worked too, once I set CHROME_PATH:

$ node scripts/capture.mjs examples/dial-indicator/dial-indicator-light.html --out dial.png
saved dial.png
clip 395,64 650x485 · readout "block 2 · reads 13.8 px" · scrolls sideways: no
console: clean

$ node scripts/lines.mjs examples/dial-indicator/dial-indicator-light.html
line ends: 0 of 367 ends on 23 lines float
console: clean

The capture took about 4 seconds. That readout ("block 2 · reads 13.8 px") comes from the same model that moves the gauge needle, which is the skill's core promise: every number in the figure comes from the figure's own model.

This is what a finished figure looks like, straight from the repo's smallest example and captured by the skill's own script:

Running /anatomy in OpenCode with a local model

The skill is a 31,600-byte SKILL.md, plus nine reference guides totalling about 300 KB that the agent is meant to open as needed. When you run the command, OpenCode injects SKILL.md into the prompt. Ollama's logs put the first request at roughly 7,700 input tokens before the model had written a word. On CPU, just reading that prompt took 45 to 70 seconds, and generation ran at about 4 to 5.5 tokens per second.

I hit two snags before any figure work began.

1. opencode run sat at "init" for 13 minutes. It was waiting on stdin. Adding < /dev/null fixed it:

opencode run --model ollama/qwen3:1.7b --command anatomy \
  "explain how a token bucket rate limiter works, interactive. Standalone HTML, light theme." < /dev/null

2. The first real run died after five minutes:

ProviderHeaderTimeoutError: Provider response headers timed out after 300000ms

OpenCode waits 300 seconds for response headers by default, and a slow local model with a big prompt can blow past that. Setting headerTimeout: false and timeout: false in the provider's options fixed it. That was the only fix I tried.

Then I ran three prompts from the README and the evals.

Token bucket rate limiter (standalone HTML, light). This one ran for 16 minutes and exited 0, but it wrote no file. The model handed the whole prompt to OpenCode's explore subagent, which came back empty. It then spent 1,560 tokens thinking and never answered. By the end, the context was 15.8k tokens.

CDN edge cache, hit vs miss, TTL 60 s (just the SVG). This one took 8 minutes 23 seconds and two turns, and it did write a file. The file was 738 bytes: three plain circles, two of them labelled "Hit" and "Miss", plus two "60s" labels. It never opened the kit, an example, or a reference. It ran no build or check, even though the skill's workflow ends with "verify it like a critic." It used CSS-style rotateX(-30deg) inside an SVG transform attribute, which SVG doesn't support. Chrome ignored those transforms, so the Hit and Miss circles landed stacked on top of each other in the top-left corner, mostly off the canvas. It also wrote the file into the skill's own install folder (~/.agents/skills/anatomy/examples/cdn-cache.svg), not the project directory. Its closing message: "File written successfully... No further action required."

Database connection pool: 10 connections, a queue when all are busy (standalone HTML, dark). This one took 10 minutes 37 seconds and again wrote into the skill's examples/ folder. The page is a plain 2D SVG on a black background. The "pool of 10 connections" is two circles drawn at the same spot, followed by the comment <!-- ... (add 10 circles) -->. The queue is one circle and <!-- ... (add 5 circles) -->. No isometric camera, no kit, no readout, no motion, and no check. Its last line: "The file was written successfully."

Here's that CDN file as Chrome renders it, at the same size it was written:

To be fair, this is a 1.7-billion-parameter model on CPU being asked to follow a 7,700-token craft manual. The skill tells the model to collect true numbers, invent an object, write a parts list, build the geometry with the kit, and then audit and screenshot every joint. That's a long agentic loop, and a model this small doesn't hold onto it. What the runs do show is that nothing in the skill makes up for a weak model. The kit only helps if the agent actually calls it.

What worked and what broke

Worked:

• The kit: zero dependencies, examples rebuild byte for byte, the Raptor builds in under two minutes
• The geometry audit: 1,290 overlaps checked against 1,290 order rules in 11 seconds, and it passed
• The Chrome checks: screenshots with live readouts, a line-end check, clean consoles
• Skill discovery: OpenCode listed anatomy right after install, even in an unexpected folder

Broke or surprised me:

• npx skills add crashes on Node 20, even though Anatomy itself supports Node 20.10+
• The CLI installs to ~/.agents/skills/anatomy, which differs from the README's OpenCode row
• 5 of 225 tests fail without React, instead of skipping
• opencode run hangs without < /dev/null, and its 300-second header timeout kills slow local runs. Both are OpenCode issues, not Anatomy ones
• With qwen3:1.7b, none of the three runs produced a real figure. One wrote nothing. One wrote a 738-byte SVG with invalid transforms. One wrote a 1,049-byte page whose pool of 10 connections is two circles and a comment saying "add 10 circles". Both files landed in the skill's own install folder, and the agent never ran a single check

Should you use it?

If you write docs or technical posts and you already run Claude Code or Codex with a strong model, yes, it's worth trying. The best part isn't the prompt. It's the kit underneath, which is deterministic and checks itself in ways I haven't seen in other "make me a diagram" tools. Start by building examples/dial-indicator and reading its roughly 300 lines. That tells you more about the output than any screenshot.

If you were hoping a local model could drive it, not at 1.7B. The skill is long, and the workflow is long, and the README says it's "slow on purpose." Budget a long session with a capable model, and expect to read the PNGs it makes.

Not tested here: Claude Code, Codex, any frontier model, the React output, the 3D mode, agent-built WebGL figures, and gallery publishing. If you've run it on a strong model, I'd love to hear how long one figure took you and what it cost in tokens. The new community gallery says it records both.