Can a Local Model Code a 3D Supercar? Flash Next Got a Car-Like Model in 100 Minutes, Then Lost Its Reflection
We gave Qwen3.8-Flash-Next a Three.js supercar prompt on an A100 held to about 12 GiB. Through OpenMausBot it made no file in 43 minutes. Called directly, it made a car-like model in about 100 minutes, with an incomplete reflection, then lost the reflection in the next round.

Can a Local Model Code a 3D Supercar? Flash Next Got a Car-Like Model in 100 Minutes, Then Lost Its Reflection
A post on social media described a video of Fable 5.5 building a 3D supercar with Three.js: body, paint, lighting and floor reflection, all from code. We wanted to know how far a model on our own GPU would get with the same kind of job.
We could not find the video, its prompt or how many attempts it took, so this post makes no comparison with Fable 5.5. It only reports what Qwen3.8-Flash-Next did for us.
This is the best car it produced. No person edited its code, and the file loads no 3D model or texture. It took three rounds on an A100, two of them after automatic screenshot feedback, and about 100 minutes of wall time. That leaves out the failed route below, and the time does not carry over to other cards.

In our software-WebGL render, it is recognizably a car, but we would not call it a finished supercar. The body is one low wedge whose windows barely show, the wheels stick out from it, and a red brake caliper sits on top of each tire. The reflection is also incomplete. The next round made the body slightly better and removed the reflection altogether.
Before that, our first route produced nothing: 43 minutes in OpenMausBot, zero files, and a job marked as completed.
What we asked for and how we checked it
The prompt asked for this, and we kept it fixed:
Build a 3D supercar showroom in one HTML file using Three.js loaded from a CDN. Do not load any external 3D model or texture. Build the car entirely in code. It needs a sculpted body, four wheels with rims and brake discs, a glossy painted finish, studio lighting, and a dark reflective floor that shows the car's reflection. I should be able to drag to orbit around the car.
We counted a file as passing only if our own browser run met all four checks:
- The file opens with no console errors.
- Dragging changes the view.
- The code and the page's network requests show no model or texture files.
- Our render shows a body, four wheels with rims and discs, and a floor reflection.
How good it looks was not scored. You can judge that from the pictures.
The engine was Strata, set up as in our OpenMausBot post: Qwen3.8-Flash-Next IQ2_XS at CONTEXT=128k and PARALLEL=2, on an A100 80GB held to about 12 GiB. This is one run per route on an A100 with a memory limit, not a test on a real 12 GB card. In the direct route, the Strata processes used 8,524 + 1,530 MiB of GPU memory (10,054 MiB in total) and the container peaked at 49.83 GiB of system RAM in docker stats.
Route 1: 28 minutes of thinking, then no file
We first gave the job to a bot in OpenMausBot with a Local VM, adding a last sentence asking it to test in the browser, look at a screenshot and fix problems.
The first request started with a prompt of 50,150 tokens. The model then spent 1,703.7 seconds, about 28 minutes, on this first step, mostly reasoning, and produced 60,766 tokens before calling a single tool.
In that first turn, its only real calls were two lookups, computer_get_guide and computer_list_apps. Then, where it needed to run a command in the VM, it wrote the call as plain text rather than making it. The name was also wrong: it wrote vm_exec, and the app's tool is agents_vm_exec. That command never ran. The job still ended as "completed", with no red error and no retry from MausBot.
We sent one follow-up saying that the call had come out as plain text and no file existed. The model spent about 507 more seconds, ran computer_list_apps again, and again wrote vm_exec as plain text. The total was 2 messages, about 43 minutes of job time and 0 files. We searched the VM's home folder across both messages and /tmp during the follow-up, and found no HTML. The logs show no tool call that could have written a file.
Route 2: no tools, and we send the screenshots
We then called Strata directly with the same server settings and no tools. The model could not open a browser, so a script did it. The prompt's last sentence became: "Reply with the complete HTML file in one code block. I will open it and send you back screenshots and any console errors."
Our script opened each reply in headless Chromium and took two screenshots, before and after a drag. It sent them back with the console output and the same fixed sentence every round:
Here are screenshots of your file from two angles and its console output. Fix what looks wrong and reply with the complete updated file.
We allowed up to five rounds and stopped at 20:30. Round 5 was cut off at that limit, about 20 minutes in, and never produced a file.
| Round | Time | Output tokens (with reasoning) | File size | Console | Checks |
|---|---|---|---|---|---|
| 1 | 35 min | 81,700 | 21,987 B | Script error | Fails 1, 2 and 4 |
| 2 | 26 min | 58,267 | 23,532 B | Clean | 1, 2, 3 pass; 4 partial |
| 3 | 37 min | 83,730 | 27,565 B | Clean | 1, 2, 3 pass; 4 partial |
| 4 | 41 min | 84,072 | 29,372 B | Shader error | Fails 1 and 4 |
Most of that time was spent before any of the reply appeared. In the four rounds, the first reply text arrived after 90-93% of the round's time. Output tokens divided by round seconds gives 34-39 tokens per second. That is A100 speed, and other jobs shared the GPU for part of rounds 3 and 4, so read it as a rough figure.

Round 1: a black screen

The file stopped with Cannot read properties of undefined (reading 'set'). It calls mirror.material.layers.set(0), but in the version it loaded, three@0.160.1, materials have no layers property. Objects do. The model's round 2 reasoning went through several suspects before deciding material.layers was likely undefined. The next file set layers only on objects and ran.
Round 2: a flat slab with wheels

The console was clean, but the object was barely a car. The checks count this as partial because the parts exist, which is why we show the pictures as well.
Round 3: the car at the top of this post

Our automatic message said nothing about shape. The model's reasoning did: "User screenshots show car not looking like supercar, extruded cabin appears as open box?" It rebuilt the body into the wedge you saw. This one round is the clearest sign that it was using the screenshots, though one run cannot show how often that works.
Round 4: the fix that removed the reflection
In round 4 the model focused on the floor, noting that the reflection looked "weirdly offset, only lower parts". It then replaced the fragment shader in Three.js's Reflector with its own, which starts like this:
#include <common>
#include <colorspace_fragment>
uniform sampler2D tMap;The second line is the bug. In three@0.160.1, that include expands to gl_FragColor = linearToOutputTexel( gl_FragColor );, a statement that has to sit inside main(). Placed at the top of the file, it is a syntax error, so the shader failed to compile and the floor stopped showing a reflection.

The console error went back to the model in round 5, but our time limit ended that round before it replied. So we do not know whether it would have fixed the shader.
What this run does and does not show
No file passed all four checks. The closest, round 3 of the direct route, passed three and partly passed the fourth with no human code fixes. That is one run, one prompt, one model.
The two routes are not a fair contest. Route 1 started from a 50,150-token prompt and had tools. Route 2 started from 163 tokens, and our script did the browser work. Route 1 got 2 messages and 43 minutes, and route 2 got up to 5 rounds and 165 minutes, which yielded 4 files. It would be wrong to conclude that direct calls beat OpenMausBot from one attempt at each.
"Completed" did not mean there was a file. The app marked the job completed. When we searched the VM's working folders ourselves, we found no HTML file from this job.
The newest round was not the best round. Had we kept only the last file, we would have kept the one without a reflection. If you run a loop like this, save every round.
Our limits. All of our renders used software WebGL on the CPU, so we measured no frame rate and did not check how the file renders on a real GPU. Yours may look different when you open it. Other processes also shared the GPU in 55 of our 1,589 memory samples, about 6 seconds apart, between 18:50 and 20:24, and total GPU use reached 18,613 MiB in those samples. We ran no second attempt, so we cannot say how often the model would get this far. We did not time any hosted model.
If you want to see where the other OpenMausBot jobs landed on the same setup, read our OpenMausBot post.