Anatomy Skill Local Test: Full-Chain Failure with a 1.7B Small Model

An Experiment Doomed to Be Unequal

What happens when you take an Agent Skill designed for frontier models, stuff it into a Debian machine with no GPU, and pair it with a local 1.7-billion-parameter model? A developer used the Anatomy project to run a fairly honest stress test, and the conclusion comes in two layers: the tooling itself is real, but a small model can't drive it.

Anatomy is an MIT-licensed Agent Skill. From its repo creation on October 8 to the morning of the 13th, it had racked up 6,632 GitHub stars. It runs in Claude Code, OpenCode, Codex, and Antigravity: you type /anatomy plus an idea, and the Agent has to invent a physical machine whose operating mechanism itself expresses that abstract concept, then assemble dozens of small shadowed parts into an interactive isometric-projection SVG.

The tester's hardware was an 8 vCPU, 16GB RAM Linux box (only about 4GB free during testing) with no GPU. No Claude Code, no Codex, no cloud API key. So the experiment became: OpenCode 1.19.0 pointing at qwen3:1.7b in Ollama, pure CPU inference.

Agent Skill is a capability package loaded on demand in Agent frameworks like Claude Code and Codex, typically consisting of a SKILL.md main file plus several reference docs, scripts, and example directories. It differs from an ordinary "prompt template" in three ways: first, the Agent can read sub-documents from it on demand at runtime; second, it can encapsulate deterministic executable scripts (build, check, screenshot); third, it defines a complete workflow that requires the Agent to call tools step by step rather than outputting results directly from memory. This design lets strong models produce stable, verifiable artifacts, but the cost is a large prompt footprint and a long call chain, which places high demands on the model's long-horizon instruction-following ability. Understanding this is the premise for understanding this article's conclusion that "the tool layer works, but the model layer doesn't."

Tool Layer Performance: Fast, Deterministic, Self-Auditing

Before introducing any model, the tester first got the non-intelligent parts working—and this is exactly where Anatomy is most impressive.

Zero-Dependency Deterministic Build

Three example projects were rebuilt with pure Node scripts, with no npm dependencies, all exit codes 0, a clean git status, and rebuilt artifacts byte-identical to the versions committed in the repo. The heaviest Raptor engine example took 115 seconds, matching the documentation's claim of "a few minutes."

This byte-level reproducibility means the toolchain itself is verifiable and won't produce random output due to environment drift.

Geometry Auditing Is the Real Highlight

It's not just about rendering graphics. It has to prove that no part passes through another, and that every overlap is drawn in the correct order. The arcade cabinet example's audit output: 15 pipelines, 243 entities, 349 items, 1,290 overlap pairs, 1,290 draw-order rules, completed and passed in 11 seconds.

This auditing mechanism solves the most easily overlooked problem in generative graphics tools: when a model draws a bunch of seemingly plausible shapes, no one knows whether their internal logic is self-consistent. Anatomy fills this gap with deterministic checks.

Isometric projection is a special kind of axonometric projection: three coordinate axes unfold at equal angles on the picture plane (usually 120° apart) and produce no perspective foreshortening. It's often used in technical illustrations, game assets, and engineering assembly drawings, because objects of the same size stay the same size anywhere in the picture, making it easier to express "the mechanical relationships between parts." In this article, Anatomy requires the Agent to assemble an isometric-projection SVG from dozens of small shadowed parts, which is precisely leveraging this property of isometric projection: the occlusion, layering, and interpenetration relationships between parts must be explicitly ordered to draw it correctly—which also explains why the geometry audit counts "overlap pairs" and "draw-order rules" rather than merely rendering the graphics.

Headless Browser Checks

The screenshot script can produce images with live readouts (e.g., "readout is 13.8 px"), the line-end check confirms that none of the 367 lines are floating unsupported, and the console is clean with no errors. These numbers all come from the graphic's own model—which is the core promise of this Skill: every number comes from the graphic's own model, not conjured out of thin air.

Model Layer Performance: Three Complete Failures

When the experiment entered the stage that truly required model driving, things took a sharp turn for the worse. The Skill itself is a 31,600-byte SKILL.md, plus about 300KB of nine reference guides, loaded on demand at runtime. The injected prompt alone is about 7,700 input tokens, and reading this prompt on CPU takes 45 to 70 seconds, with generation speed around 4 to 5.5 tokens per second.

None of the three tests produced a qualified graphic:

Token bucket rate limiter (standalone HTML, light theme): Ran 16 minutes, exit code 0, but no file was written. The model dumped the entire task onto OpenCode's explore subagent, which returned an empty result. It spent 1,560 tokens thinking and ultimately didn't answer.

CDN edge cache hit/miss (TTL 60 seconds, SVG only): 8 minutes 23 seconds, wrote one file—738 bytes. Three plain circles, two labeled "Hit" and "Miss," two "60s" labels. It never opened the toolkit, examples, or any reference doc, and never ran any build or check, even though the Skill's workflow explicitly requires "validate like a critic." It also used CSS-style rotateX(-30deg) in the SVG's transform attribute—which SVG doesn't support at all, so Chrome simply ignored it, causing two circles to stack in the upper-left corner, mostly off-canvas. Worse, the file was written into the Skill's own installation directory rather than the project directory.

Database connection pool (10 connections, queuing mechanism, dark theme): 10 minutes 37 seconds. The page was flat 2D SVG on a black background. "10 connections" was two circles drawn in the same position, followed by the comment <!-- ... (add 10 circles) -->. The queue was one circle plus <!-- ... (add 5 circles) -->. No isometric projection, no toolkit calls, no readouts, no animation, no checks of any kind.

Context window refers to the total number of tokens a model can hold at once in a single inference, including system prompts, injected Skill docs, conversation history, and the output to be generated. In this article, the Skill injection alone takes about 7,700 tokens, and stacking on about 300KB of on-demand reference guides rapidly eats into the available budget for a 1.7-billion-parameter small model: once a task requires reading docs across multiple turns, calling scripts, and checking results, early instructions get pushed out of the window or diluted, and the model gradually "forgets" what it's doing. Subagent is a mechanism by which the Agent framework delegates subtasks to an independent context, originally intended to relieve pressure on the main context, but under weak models it easily becomes "passing the buck"—handing off the task and then not collecting the result itself. The "no file was written" in this article's first test is exactly this failure mode.

Where It Breaks Down: The Toolkit Can't Compensate for a Weak Model

To be fair: this is a 1.7-billion-parameter CPU model being asked to follow a 7,700-token craft manual. The Skill has the model gather real numbers, invent an object, write a parts list, build geometry with the toolkit, and audit and screenshot every joint. This is a very long Agent loop that a small model simply can't sustain.

But these runs also make one thing clear: there is no mechanism in the Skill that can compensate for a weak model. The toolkit is only useful when the Agent actually calls it.

This finding has direct practical implications for the local deployment route. Many people expect to use a cheap local small model to drive complex coding and generation tasks, but when a Skill's prompt alone exhausts most of your model's context window, and a single generation takes several minutes while the model can only sustain a few tokens per second, a multi-step workflow becomes an almost impossible task.

Incidental Engineering Problems Discovered

The test also exposed some model-independent engineering friction:

• npx skills add crashes outright on Node 20, even though Anatomy itself only requires Node 20.10+. The CLI toolchain requires Node 22.20+, and although the docs mention it, it's buried in a collapsed section.
• The CLI installed to ~/.agents/skills/anatomy, while the line in the docs corresponding to OpenCode gives a different path. OpenCode happens to also read the .agents directory, so it still works, but the docs and actual behavior are inconsistent.
• 5 of 225 tests fail, all of them React-dependent test files, while React isn't installed. The docs state that React is only required when outputting React, so this is an environment configuration gap rather than a bug—but those 5 tests should skip cleanly rather than fail.
• opencode run without < /dev/null hangs in the init state for up to 13 minutes, because it's waiting on stdin. This 300-second default timeout also kills long responses from slow local models.

To Use or Not to Use

If you already use Claude Code or Codex with a strong model and do documentation writing or technical writing, it's worth a try. The most noteworthy thing isn't the prompt, but the toolkit underneath—it's deterministic and self-checking in ways never seen in other "help me draw a diagram" tools. It's recommended to start by building examples/dial-indicator and reading that roughly 300 lines of code, which is more informative than looking at any screenshot.

If you're counting on a local small model to drive it, the 1.7B level won't cut it. The Skill is long, the workflow is long, and the docs themselves say it's "deliberately slow." Prepare a long session on a machine with headroom, and be ready to inspect the PNGs it generates.

A broader takeaway: the capability ceiling of an Agent Skill depends largely on whether the model it relies on can sustain long chains of instruction-following. The engineering quality of the tool layer can be made very high, but the real bottleneck is often on the model side.

One-line Summary

Anatomy's toolkit is deterministic but needs a strong model to drive it; a 1.7B local model failed all three /anatomy attempts.

Paragraph Summary

The article documents a stress test driving the Anatomy Agent Skill on a GPU-less Debian machine with the qwen3:1.7b model on Ollama. The tool layer performed impressively: three examples rebuilt with zero npm dependencies and byte-identical to the repo versions; the geometry audit checked 1,290 overlap pairs in 11 seconds; headless browser screenshots and console checks passed. But the model layer failed all three tasks—one wrote no file, one output only 738 bytes with invalid SVG attributes, and one generated a flat 2D page with comments in place of parts. The core conclusion is that the toolkit's engineering quality cannot compensate for a weak model, and the Skill is only useful when the Agent actually calls it. The article also lists engineering friction such as Node version, install path, test skipping, and stdin blocking, and offers the practical advice that "it works with a strong model, but not with a local small model."