Qwen3.5-4B-3D-Coder: A 4B Open Model That Writes Three.js Scenes

Qwen3.5-4B-3D-Coder is an early-preview, Apache-2.0 fine-tune of Qwen3.5-4B that writes self-contained Three.js scenes, and its Q4_K_M build is only about 2.7 GB. An independent developer, CCORE, published it on Hugging Face on October 25, 2026, and the model card says it is "not an official Qwen release." The repo had 196 likes and roughly 6,900 downloads on October 28, which is why it surfaced in the trending list.

It matters because it tests a specific bet: that a very small model, trained narrowly, can produce rich interactive 3D output that people usually expect from far larger systems. This post covers what the card actually says, how to run it, what is promised but not yet shipped, and where to stay skeptical. It sits alongside our recent coverage of small open models such as Nemotron 3.5 Bolt E4B and the offline coding agent built on Qwen3.5 9B.

Quick facts: the TL;DR table

What does the model card actually say?

The card describes the project as "an experiment exploring the feasibility of small language models for general-purpose coding and high-quality 3D scene generation." It is a work in progress, shared while training continues. The developer reports that "initial hands-on results have been promising for coding in general, and especially for generating 3D scenes."

The most useful detail is the checkpoint history. Both GGUF files were refreshed on October 27, and the card says "one-shot success has improved substantially, along with overall scene quality," while admitting that "some scenes can still require another attempt or a correction." If you downloaded an earlier file, you are told to download it again.

The Hub metadata also lists a context length of 262,144 tokens for the architecture, inherited from the Qwen3.5 base, and the tags code, threejs, 3d and preview.

What does the output look like?

The card includes a progression image of one scene, a stylized Rome with the Colosseum, Roman Forum and Pantheon built from blocks, across the October 25, 26 and 27 checkpoints. It is the clearest evidence of the claim that quality moved quickly between checkpoints.

You can see the progression image on the model card.

The first checkpoint produces a recognisable but sparse layout. By October 27 the scene has labelled landmarks, trees, tiny figures and layered stonework. That is a visible jump, but it is also a single hand-picked prompt. The gallery on the card adds a Sakura temple garden, a sunset village, a dragonrider aerie, a voxel launch site, a bookbinding bench, a CPU socket, a pelican on a bike, a bow-front secretary desk and a bonsai. They are rendered Three.js scenes built through HTML and JavaScript.

Worth noting what this is not: it is not a text-to-3D-mesh model like the image-to-asset systems from large labs. It writes code, a single HTML file that imports Three.js and builds the scene procedurally, so the output is editable, diffable and runs in any browser.

How do I run it?

Qwen3.5-4B-3D-Coder running locally on a laptop with a small quantized GGUF file

The repo ships two quantized files, so the practical path is a GGUF runtime.

The card gives the same generation settings for both:

Two practical points from the card. First, in LM Studio you must disable multi-token prediction, which that app enables by default, or the model will not work properly. Second, use the recommended system prompt, which tells the model to use only the Three.js core ES module from cdnjs (version 0.160.0), not to import addons or legacy example paths, and to implement camera controls directly in the HTML. That constraint is what keeps output self-contained.

A user prompt that follows the card's own examples looks like this:

Please create one self-contained HTML file with Three.js from cdnjs showing
a canal lock and weir complex with a central island.
Render it as a deliberate 3D voxel model built from visible cubic blocks,
with clear depth, readable silhouettes, and solid spatial relationships.

Save the reply as an .html file and open it in a browser. If the console shows a redeclared variable, rename the duplicate and reload, which matches the failure mode the card describes.

Why a 4B model for 3D code?

Coding model glyph representing a narrowly fine-tuned small model for code generation

Three reasons make this more interesting than another fine-tune.

Narrow tasks reward small models. A single-file Three.js scene has a bounded vocabulary: a fixed library, a handful of geometry and material classes, a render loop. A 4B model trained heavily on that distribution can plausibly outperform a general model of similar size, in the same way company-specific fine-tunes have beaten large models on one task. We covered a measured example in Exowatt's fine-tuned Qwen3 that beat Claude Opus on alarm triage. The difference here is that no measurement has been published yet.

Local and private. At 2.7 GB the model runs on hardware people already own, with no API bill and no prompt leaving the machine. For teaching, game prototypes and visual explainers, that is attractive.

Verifiable output. Code that renders is easy to check by eye: it either shows a coherent scene or it does not. That makes small-model experiments like this easier to evaluate than free-form text, and it is why the "one-shot success" metric the card uses is meaningful, once it is quantified.

What is claimed versus what is verified?

The honest summary is that the evidence is a gallery and a progression image. That is enough to try it, not enough to rank it. The promised technical report, which the card says will show prompts and results across training checkpoints, is the thing to wait for. If it also includes a held-out prompt set and a pass rate, the claim becomes testable.

What should builders check before using it?

1. Dataset provenance. The training dataset is promised but not yet public. Until you can see what the scenes were trained on, treat licensing of the outputs as an open question, even with an Apache-2.0 model license.
2. Reproducibility. The checkpoint changed three times in three days. Pin the file hash you test, and re-test after any re-download.
3. Sandboxing. The model emits HTML and JavaScript that you will open in a browser. Run generated pages in a throwaway profile, and review any network calls, as you would with any model-written code. Agent workflows that execute model output deserve the same caution described in our agent security coverage, and the AgentBeam platform from the explainx.ai team at agentbeam.com exists for stopping agents before they take dangerous actions.
4. Fallback plan. For production work, keep a larger model in the loop for the scenes that fail. A 4B model that needs one retry in a few cases still saves time, but only if you can tell which ones failed.

How does it compare with other small open models?

These are different jobs, so numbers are not comparable across rows. The common thread is that 2B to 4B models are increasingly built for one narrow task and shipped with a runtime-ready file, rather than as general assistants.

What this means for what you build

If you make browser games, product configurators, data-visualisation prototypes or teaching demos, this is cheap to try: one file, one system prompt, a few minutes. If you need dependable results today, use it as a fast first draft generator, not a final authority. If you care about evidence, bookmark the model page and look for the technical report; the developer committed publicly to a date, and the repo history will show whether it landed.

A final point on process. The developer posted three checkpoints in three days and wrote the changes into the card. That is a healthy way to ship an experiment, and it is also why you should avoid quoting any single screenshot as the model's typical quality.

Related reading

• Nemotron 3.5 Bolt E4B: a 4 GB open edge model
• Offline coding agent with OpenCode, Ollama and Qwen3.5 9B
• Exowatt: a fine-tuned Qwen3 beats Claude Opus on alarm triage
• Microsoft UserRepGen-4B
• Strands Decider 2B
• Model card on Hugging Face and Three.js

Details reflect the model card and Hub metadata as of October 28, 2026; the developer was still updating the repo.