Qwen3.5-4B-3D-Coder: Local Three.js Scene Generation
Qwen3.5-4B-3D-Coder is CCORE’s independent fine-tune of Qwen/Qwen3.5-4B, not an official Qwen release. It focuses on coding and interactive Three.js scenes, returning editable HTML and JavaScript rather than a 3D mesh or image. Try it for local scene prototypes when you can inspect the generated code and correct rendering issues.
Content reviewed:
Use this model
Official model repository
- Get the model and setup instructions
Model card, downloads and license conditions.
Local tools and guides
- CCORE recommended Three.js system prompt and settings
Follow the tool’s installation and hardware requirements.
Good first tasks
- Draft a small interactive Three.js scene from a written layout brief.
- Turn a reference image into an approximate voxel scene with the optional vision setup.
- Prototype a browser-based visual or teaching aid, then inspect and correct its generated code.
What does Qwen3.5-4B-3D-Coder generate?
The publisher describes Qwen3.5-4B-3D-Coder as an early preview focused on general coding and interactive Three.js scenes, usually delivered as HTML and JavaScript that you can edit and open in a browser.
That output is different from a model that creates a mesh, texture, or rendered image. Choose this fine-tune when you want a procedural browser scene or a code draft. If you need a production-ready asset, expect to review geometry, interactions, performance, and browser errors yourself.
| Item | What the publisher lists |
|---|---|
| Publisher and base | CCORE; independent fine-tune of Qwen/Qwen3.5-4B |
| Main use | Coding, especially interactive Three.js scenes |
| Output | Text/code, commonly HTML and JavaScript |
| Weights | Q4_K_M and Q8_0 GGUF; FP16 Safetensors |
| License | Apache License 2.0 |
| Hosted API price | No hosted API price listed on the model card |
What does a local run cost?
Qwen3.5-4B-3D-Coder offers Q4_K_M and Q8_0 GGUF files. A third-party CPU run reported 2.71 GB and 4.48 GB file sizes respectively; those are download sizes, not the memory required to load the model. The optional vision projector adds another approximately 644 MiB, and images use part of the same context as the prompt and generated code.
Webdiga’s October 27 report describes a Q4_K_M run with Ollama 0.40.11, 8 vCPUs, no GPU, thinking disabled through the API and a 16,384-token context. Ollama reported 4.1 GB for the loaded model; a 10,609-token scene took 18 minutes 25 seconds and needed code fixes before it rendered. This records one prompt on that GGUF; it does not test the FP16 release added October 29 or the optional vision setup added October 30. Your runtime, context, CPU/GPU offload and scene length change the footprint and time.
For a budget, include the machine or rented instance, electricity while generating, setup and review time, and any retries. No hosted API rate is listed on the card, so there is no verified per-token price to use for an API estimate.
| Cost item | What to count |
|---|---|
| Download | Chosen GGUF or FP16 files and the optional vision projector |
| Local hardware | Available memory, runtime allocation and accelerator time |
| Electricity | Power during model loading and generation |
| Human work | Code review, browser testing and repairs or retries |
How do you try it with Ollama?
The Qwen3.5-4B-3D-Coder model card documents a Hugging Face model tag for Ollama. Pull the Q4_K_M version first; it is the smaller of the two published GGUF options. Once it loads, ask for one HTML file and give it a concrete scene layout. The card recommends temperature 0.6–0.8, top-p 0.90–0.95, top-k 20–40 and repeat penalty 1.0.
At the chat prompt, try: “Write one HTML file for an interactive Three.js canal lock with a gate that opens when clicked.” Save the generated HTML, open it in a browser and inspect the console. For scene generation, the publisher also recommends a system prompt that pins Three.js core 0.160.0 and avoids addons. The browser needs network access to fetch that module. If you use LM Studio, disable multi-token prediction (MTP), which its default setting can make this model handle incorrectly.
ollama run hf.co/ccore/Qwen3.5-4B-3D-Coder:Q4_K_MHow reliable are the generated scenes?
CCORE’s October 28 report evaluates the scenes Qwen3.5-4B-3D-Coder generates using eight development prompts on the Qwen3.5-4B base model and eight fine-tune checkpoints. It is an exploratory study, not a benchmark: each case allowed up to five attempts, used the first accepted result and allowed up to three local syntax or identifier repairs. The base model stopped at its first technical render; fine-tune checkpoints needed a recognizable scene and the requested controls. Checkpoint 8 met those criteria on all eight scenes in 18 calls. Six selected outputs kept their original code and two received repairs; two scenes passed unchanged on the first try (four if repaired passes count). Eight calls ended in reasoning loops before returning HTML.
In Webdiga’s October 27 CPU run, the first scene did not render because of a duplicate declaration. Two code fixes produced a coherent scene, though its animation continued creating marker meshes on every frame. This is one prompt on one setup, not a success-rate estimate. The model card also lists duplicate variable names among known issues. When you try it, open the HTML, inspect the browser console, test interactions and watch for repeated work inside the animation loop.
Can it use an image as a scene reference?
Qwen3.5-4B-3D-Coder supports optional image input in its Q4_K_M and Q8_0 GGUF versions. It uses the original Qwen3.5-4B vision encoder/projector, downloaded separately at approximately 644 MiB, alongside the model file in llama.cpp. The card demonstrates asking for a Three.js interpretation of a reference image; it cautions that the generated scene interprets the reference rather than reproducing every detail.
Image tokens share the context window with the written prompt and output. The publisher says its llama.cpp b11889 checks used short requests and were not full-context stress tests. The added projector and image tokens also affect memory, so check your runtime’s available memory before increasing image size, context or parallel requests.

Before you use it
- The model card does not give a general minimum RAM or VRAM requirement. GGUF file size alone does not determine the full runtime footprint.
- The publisher’s comparison is exploratory rather than an independent benchmark, and the model card lists no hosted API price for a per-token estimate.
How to get started
Review generated HTML and JavaScript before opening or sharing it. Check external module imports, browser console errors, interactions and animation work. The publisher’s example imports Three.js from cdnjs, so rendering that example requires a network connection.
Sources
Sources (6)
- CCORE technical report and exploratory evaluation ↗
Source checked:
- CCORE model card, license, files and usage ↗
Source checked:
- Official Qwen3.5-4B base model ↗
Source checked:
- Webdiga CPU run and repair report ↗
Source checked:
- CCORE’s Reddit checkpoint discussion ↗
Source checked:
- LocalLLaMA first-use discussion and MTP note ↗
Source checked: