img2threejs takes a single reference image of an object and rebuilds it as procedural Three.js code — not a mesh file, not a photogrammetry scan, but a TypeScript factory function that constructs the object from primitives, procedural shaders, and generated geometry. The project appeared on GitHub on July 15, 2026 and has collected roughly 4,800 stars in eleven days, which puts it among the fastest-rising 3D repositories of the month. It is Apache-2.0 licensed and ships as an agent skill rather than a standalone application. ## Reconstruction by Code The distinction the project draws is deliberate. Conventional image-to-3D pipelines output a mesh: a binary blob of vertices you can view but not meaningfully edit. img2threejs outputs source code. The result is a `createObjectNameModel(spec, options)` factory returning a `THREE.Group`, alongside an `ObjectSculptSpec` JSON describing the full component tree, materials, repetition systems, and sockets. That choice cascades into everything else. The output is diffable, reviewable, and version-controllable — a few kilobytes of TypeScript instead of a multi-megabyte GLB. It runs in the browser with no asset downloads. And because the generator emits a runtime hierarchy exposed through `root.userData.sculptRuntime` — pivots, sockets, colliders, destruction groups — the model arrives animation-ready rather than as what the README calls "an inert lump." The showcase gallery demonstrates the range: Sony WF-1000XM3 earbuds with their case, a Gerber paracord knife, an isometric Doraemon house diorama, each running live in-browser with viewable generated source. ## The Gated Pipeline The project's real engineering is in its refusal to trust the model. Generation runs through a fixed sequence of build passes — `blockout` → `structural-pass` → `form-refinement` → `material-pass` → `surface-pass` → `lighting-pass` → `interaction-pass` → `optimization-pass` — and a pass unlocks only after the previous one has been rendered, screenshotted, packaged into a side-by-side comparison sheet, and scored at or above threshold by the agent's vision. Several gates sit in front of that loop. A suitability gate asks whether the image is a viable 3D target at all. A strict-quality gate blocks code generation until the spec is deep enough for the object's complexity, so no tokens are spent rendering something that was underspecified from the start. Before any of it, the pipeline enumerates a `detailInventory` of identity-defining small features — bevels, fasteners, engraved linework, gloss versus matte zones, wear — and every entry must map to a real component or material. After each pass the agent picks exactly one action: `continue`, `refine-spec`, `refine-code`, `request-input`, or `stop`. Release v1.3, tagged July 23, added a deterministic review harness with input-integrity and geometry-truth gates plus CIEDE2000 color math. ## Token Economics The token-efficiency claim is the project's second pitch, and its mechanism is straightforward: push mechanical work into deterministic scripts and spend model tokens only on judgment. The Python side handles validation, gating, spec authoring, PBR evidence extraction, comparison-sheet packaging, and pipeline state — none of it scores visuals. The model's contribution per pass is looking at one packaged comparison sheet and deciding pass or fail. Those scripts are pure Python 3.10+ standard library. No pip, no PIL, no numpy, no Playwright; PNG reading and writing is done with `struct` and `zlib`. Nothing to install means nothing to debug in-context, which matters more than it sounds when the consumer is an agent with a finite context window. The generator also emits only the currently unlocked pass rather than regenerating the whole model each iteration. ## Pros and Cons The strengths are the output format and the discipline around it. Editable, diffable, animation-ready code beats an opaque mesh for anyone building interactive scenes, and the gating architecture is a more rigorous answer to agent hallucination than most image-to-3D tooling attempts. Zero-dependency scripts and agent-agnostic design — it runs under Claude Code, Codex, or OpenCode, using whatever vision the host provides — keep setup friction near zero. The caveats are substantial. The project is eleven days old with two contributors and about twenty open issues; API stability and maintenance are entirely unproven. It requires an agent host with vision, so it is not a standalone tool. Procedural reconstruction suits hard-surface objects far better than organic ones, and the README concedes that characters come out as stylized reconstructions rather than photoreal likenesses. A single image cannot reveal hidden sides, so unseen faces are inferred by mirroring visible ones. And the multi-pass review loop, however token-efficient per pass, still means many agent turns per model — cheaper than a naive loop, not cheap in absolute terms. ## Outlook The published roadmap is ambitious in a way that invites skepticism: v1.4 for photorealistic hard-surface weapons, v1.5 for characters, v1.6 for environments, v1.7 for Unity and Unreal exporters, through to v2.0 promising procedural city generation. Shipping v1.0 through v1.3 inside nine days is evidence of pace, but the gap between reconstructing a loot chest and generating a playable world is not a scheduling problem. The near-term question is narrower and more answerable: whether code-as-3D-output is the right target for agent pipelines at all. The showcase gallery is a decent argument that for hard-surface props, it is. ## Conclusion img2threejs is worth trying for web developers and game prototypers who need editable 3D props from reference images and already work inside an agent CLI. Teams needing photoreal characters, organic shapes, or a stable production dependency should wait — the ideas are sound and the gating is unusually well thought out, but eleven days and two contributors is not a foundation to build a pipeline on yet.