Instructions to use ccore/Qwen3.5-4B-GLB-3D-Coder with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- llama.cpp
How to use ccore/Qwen3.5-4B-GLB-3D-Coder with llama.cpp:
Install (macOS, Linux)
curl -LsSf https://llama.app/install.sh | sh # Start a local OpenAI-compatible server with a web UI: llama serve -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M # Run inference directly in the terminal: llama cli -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
Install from WinGet (Windows)
winget install llama.cpp # Start a local OpenAI-compatible server with a web UI: llama serve -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M # Run inference directly in the terminal: llama cli -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
Build from source code
git clone https://github.com/ggml-org/llama.cpp.git cd llama.cpp cmake -B build cmake --build build -j --target llama-app # Start a local OpenAI-compatible server with a web UI: ./build/bin/llama serve -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M # Run inference directly in the terminal: ./build/bin/llama cli -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
Use Docker
docker model run hf.co/ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
- Llama new
- LM Studio
- Jan
- vLLM
How to use ccore/Qwen3.5-4B-GLB-3D-Coder with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "ccore/Qwen3.5-4B-GLB-3D-Coder" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "ccore/Qwen3.5-4B-GLB-3D-Coder", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker
docker model run hf.co/ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
- Ollama
How to use ccore/Qwen3.5-4B-GLB-3D-Coder with Ollama:
ollama run hf.co/ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
- Unsloth Desktop
- Pi
How to use ccore/Qwen3.5-4B-GLB-3D-Coder with Pi:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
Configure the model in Pi
# Install Pi: npm install -g @earendil-works/pi-coding-agent # Add to ~/.pi/agent/models.json: { "providers": { "llama-cpp": { "baseUrl": "http://localhost:8080/v1", "api": "openai-completions", "apiKey": "none", "models": [ { "id": "ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M" } ] } } }Run Pi
# Start Pi in your project directory: pi
- Docker Model Runner
How to use ccore/Qwen3.5-4B-GLB-3D-Coder with Docker Model Runner:
docker model run hf.co/ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
- Lemonade
How to use ccore/Qwen3.5-4B-GLB-3D-Coder with Lemonade:
Pull the model
# Download Lemonade from https://lemonade-server.ai/ lemonade pull ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
Run and chat with the model
lemonade run user.Qwen3.5-4B-GLB-3D-Coder-Q4_K_M
List all available models
lemonade list
- Hermes Agent
How to use ccore/Qwen3.5-4B-GLB-3D-Coder with Hermes Agent:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
Configure Hermes
# Install Hermes: curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash hermes setup # Point Hermes at the local server: hermes config set model.provider custom hermes config set model.base_url http://127.0.0.1:8080/v1 hermes config set model.default ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
Run Hermes
hermes
- Atomic Chat
- OpenClaw
How to use ccore/Qwen3.5-4B-GLB-3D-Coder with OpenClaw:
Start the llama.cpp server
# Install llama.cpp: brew install llama.cpp # Start a local OpenAI-compatible server: llama serve -hf ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M
Configure OpenClaw
# Install OpenClaw: npm install -g openclaw@latest # Register the local server and set it as the default model: openclaw onboard --non-interactive --mode local \ --auth-choice custom-api-key \ --custom-base-url http://127.0.0.1:8080/v1 \ --custom-model-id "ccore/Qwen3.5-4B-GLB-3D-Coder:Q4_K_M" \ --custom-provider-id llama-cpp \ --custom-compatibility openai \ --custom-text-input \ --accept-risk \ --skip-health
Run OpenClaw
openclaw agent --local --agent main --message "Hello from Hugging Face"
Genuinely impressed — one line, one usable GLB
TL;DR — It is genuinely good at what it claims: with your documented system prompt and sampling settings, a one-line request produced a valid GLB on the first headless export. My improvised "engineering-style" prompt produced a truncated page with my constraints silently ignored. Budget tokens generously, scale and repair the mesh yourself, and it slots neatly into an automated pipeline.
Context: what I'm building
A small multi-legged crawler — chassis and leg links 3D-printed at home, hobby servos, layout and hinge travel already fixed on drawings, target behaviour a slow reptile-style crawl gait. I'm building its MuJoCo model in parallel with the hardware, and everything in the pipeline has to be accepted by a script rather than by my eyes, because a physics simulator rarely errors — it returns a plausible wrong answer.
Why this interface is the right one
"An LLM that emits a self-contained Three.js page with a working GLB export" is a better interface than raw mesh output: the asset is reviewable in a browser before it ever reaches a DCC tool, and the failure mode is visible instead of silent.
How I use it — the part worth copying
It doesn't run as a chat box for me. It runs as a small specialist sub-agent inside a larger agent: a bigger model converts my engineering intent into the short English asset request this model was trained on, leaves your system prompt and sampling settings completely untouched, and then feeds whatever comes back through checks — export the GLB headlessly, measure the bounding box, list node names, test the mesh.
That is noticeably better than driving it directly. The model performs best when the caller adds nothing to its input format and instead validates the output; my single attempt at "improving" the prompt with an engineering-style spec cost me a whole failed run.
Two runs, same part
| Attempt | Prompt | Result |
|---|---|---|
| Mine | Long engineering spec (exact dimensions, hole axes, node name, "no decorative features"), max_tokens=20000 |
finish_reason=length: HTML truncated mid-function, never closed; constraints silently overridden, decorations added anyway |
| Documented | Your system prompt verbatim + Create a low-poly robot leg link with hinge holes at both ends. |
finish_reason=stop, 290 s, valid GLB on the first export (75 kB, 26 named nodes, 1,398 faces) |
The documented run is good-looking and has well-named nodes. It is not dimensionally faithful, and roughly half the nodes are bolts, washers and orange stripes — which is precisely the claimed domain.
The page the documented prompt produced: 26 named nodes, working Export GLB, and yes, bolts.
Field notes for other users
- Use the documented system prompt and sampling, and keep requests short and in English. Don't improvise — the game-art prior wins every time.
- Budget generously and read the right field. It thinks a lot: ~10k tokens of thinking for a one-line request. The answer arrives in
message.content; the thinking sits inmessage.reasoning_content. A client that reads onlycontentconcludes the model returned nothing. - There are no units in the file. Measure the bounding box after loading — a ~60 mm part arrived as a ~3.6 m box and needed a ~0.016 scale factor to be believable.
The exported mesh loaded at face value in MuJoCo, before rescaling.
- Physics meshes need repair.
ExtrudeGeometryoutput arrives non-watertight with duplicated vertices. At MuJoCo's default density the part came out at 14.84 g raw, 11.97 g aftermerge_vertices()and 11.90 g as a convex hull, against 10.7 g theoretical. Use the hull or primitives for collision, and the original mesh as a visual-only geom.
Raw extrude output as loaded — the decorative bolts and washers are part of the collision mass.
- Headless export needs no clicking. Patch
URL.createObjectURLbefore page scripts run, click the button, read the captured Blob — every page this model generated worked unchanged, including ones with no stable button IDs.
Three things that would make it easier to embed
For the planned agent-harness version:
- Fail loudly — one fenced block, no prose, so truncation is obvious rather than silent.
- Honour explicit constraints — units, node names and "no decoration" when a caller supplies them.
- Expose
window.exportGLB()plus a watertight-by-construction mode, so a pipeline can assert on the asset instead of guessing at it.
Thanks for releasing this openly — and the checkpoint improvements for detailed prompts over the first few days are already visible from my side.
first of all, thank you so much for taking the time to test the model so thoroughly and share such detailed feedback! i really appreciate it.
i've actually noticed many of the same limitations you pointed out, and i completely agree that these are important areas to improve. i genuinely believe we can address them with better training data and more targeted validation.
these models have been part of a series of experiments to understand how far we can push small models through carefully designed supervised training.
i started with the original 3d-coder, focused on general scene generation. then, based on feedback from the community, i developed glb-coder to generate reusable assets with glb export.
each experiment has helped me understand more about what these models can learn, where they struggle, and how to improve the training process.
and honestly, the results have made me increasingly confident that small models can achieve performance comparable to much larger models in certain specialized tasks, like operating cad software, 3d modeling tools or coding within specialized agentic harnesses.
that's actually the direction i'm exploring next.
the next 3d model won't be limited to one-shot generation. i'm planning to train it to operate as an agent, interact with tools, inspect its results and make iterative corrections.
your feedback about dimensions, mesh validation, object naming, export interfaces and engineering constraints is particularly valuable, and i'll definitely incorporate these points into the v2 training datasets.
thanks again for such a thoughtful evaluation! i really appreciate this kind of feedback, especially when it highlights limitations that can guide the next improvements.
i'm excited to see how far we can take these small models (:


