Introduction

Over the past few months, we have seen a steady stream of new LLMs being released, including models such as Anthropic’s Fable and Mythos; OpenAI’s Astra and its model family—Luna, Terra, and Sol; and open-source and open-weight models such as the latest Qwen3.8 27B model.

For a while now, models have been very good at writing and coding, and they have continued to improve at reasoning. The latest models, however, seem to be pushing the boundary much further. They are getting better at spatial reasoning for tasks such as 3D design and modeling, while improvements in visual reasoning have made computer-use features possible. A model can now control a computer much as a person would, moving the mouse around, opening menus, clicking buttons, and searching for the option it needs.

I have been testing some of these features, especially computer use, almost by accident. It started with simple questions about software, such as how to enable a feature in an application’s preferences. In some cases, it became easier for the LLM to show me where to click—and do it for me—than to explain the steps and guide me through them. The most surprising part is how human the interaction can look: it moves through menus and explores the interface until it finds the setting being requested.

But enough about that. The main reason I wanted to write this post was to test and show how far spatial reasoning and 3D modeling capabilities have come.

I have wanted to develop an application that requires a fairly complex 3D model for some time. I know how to use tools such as SolidWorks to create 3D models, but my experience is mainly with parametric, engineering-style shapes rather than organic forms. Designing an articulated human model is a very different challenge, and I would also need to take it one step further by animating that model into different movements and poses—something I had never done before. It seemed like the perfect opportunity to test these newer models and their design capabilities.

That made this a good test for the latest generation of AI tools. Creating a useful organic 3D asset requires a different combination of skills from writing code. The model needs to reason about shape, topology, proportions, rigging, deformation, animation, camera composition, and the errors it finds while operating Blender.

So I gave three models the same task: create an original, gender-neutral fitness avatar in Blender, rig the full body, animate a wrist and finger stretch, and deliver renders, a video, and an editable Blender file.

This was not intended to be a scientific benchmark. It was a practical stress test of what each model could accomplish while controlling a real Blender session.

The experiment

The models received the same cleaned prompt. It asked for:

  • A complete full-body character with hands, fingers, thumbs, feet, and toes.
  • A deformable armature with independently controllable fingers and thumbs.
  • An animation named Wrist_Finger_Stretch, with a resting pose, transition, hold, and return.
  • A full-body resting render, a stretching render, a wrist close-up, a preview video, and the editable .blend file.

The prompt also instructed the models to create an original design. I used two external images as private visual references: a photograph for the wrist and finger position, and a stylized fitness-trainer image for the general presentation. They are not included in the repository, and the generated characters were explicitly told not to copy them.

Hardware and software

The tests were run on my Linux desktop. Kali Linux was the distribution available on that machine; Ubuntu would probably be a smoother starting point for a new setup, but Kali worked for this experiment.

CategoryConfiguration
CPUIntel Core i9-14900K
Memory32 GB RAM
GPUAMD Radeon RX 7900 XTX
Operating systemKali Linux
3D softwareBlender 5.2.1
Blender integrationOfficial Blender MCP add-on and server
OpenAI runsCodex, using Astra and Luna at extra high reasoning
Local runQwen3.8 27B GGUF UD-Q4_K_XL through llama.cpp and OpenCode at xhigh reasoning

The Blender MCP bridge allowed the models to inspect and operate the Blender scene directly. Astra and Luna ran through Codex. Qwen ran locally because the non-native model was not working reliably through the same Codex MCP setup at the time. That difference matters: these results compare complete workflows, not isolated model intelligence under perfectly identical conditions.

Astra and Luna were both run with Codex’s extra high reasoning setting. Qwen was run locally with the xhigh reasoning setting in OpenCode. The reasoning effort is included here because it affects how much time and compute each model can spend planning, inspecting, and correcting the Blender scene.

The repository contains the setup notes and configuration, as well as the prompt and reference-image attribution.

Results

I’ll start with the local Qwen run, continue with Luna, and leave Astra until the end. That order makes the progression easier to judge from the artifacts themselves.

The interactive GLB previews below all use the shared resting pose exported from frame 1. The MP4 previews retain the complete movement into and out of the stretch.

Qwen

Qwen was the most interesting surprise. It is a 27-billion-parameter model. Running locally at roughly 30 tokens per second, it took about four hours and forty minutes, and it spent a lot of that time finding and trying to repair problems with clothing, hair, hands, feet, and other details.

The final result is clearly less refined than Astra’s, and it has errors in the feet, shorts, shirt, and finger-placement animation, but it still performed reasonably well overall in a surprisingly ambitious task. It created the character, rig, animation, renders, and source file instead of getting permanently stuck in a correction loop. With a stronger quantization, more inference performance, and more supervision, I would expect the result to improve. But for a 27-billion-parameter model, it is certainly punching above its weight. Despite having to compact the context ten times, I think the harness did a great job: after each compaction, it summarized the tasks and status without ever getting confused.

Download the Qwen GLB model

Rest poseStretch poseWrist close-up
Qwen avatar in the resting poseQwen avatar in the final stretching poseQwen wrist and hand close-up

Luna

Luna was much faster and produced a coherent character and a convincing animation. Its main weakness was the body design: the proportions became noticeably bubbly, which made the avatar feel less like an application asset. The motion itself was better than I expected from such a short run. It also had an error in the right wrist, which made the animation look off. The hair and background were much better than Qwen’s, but the overall result was not as satisfactory. It also consumed very few tokens—only 1% of my five-hour usage limit.

The initial run did not produce a video, so I asked for that separately in a second message. Luna rendered the preview frames and used an external Python library to assemble them into an MP4 instead of using the Blender MCP.

Download the Luna GLB model

Rest poseStretch poseWrist close-up
Luna avatar in the resting poseLuna avatar in the final stretching poseLuna wrist and hand close-up

Astra

Astra produced the strongest result of the three. It made better design decisions without needing much correction, and the final stretch was easy to understand from the pose alone. The assisting hand and stretched fingers were separated more successfully, which made the exercise read clearly rather than looking like a collection of overlapping shapes. I did notice that it took the time to make sure the fingers and hand were properly placed and not overlapping. The clothes, hair, and other details were much better. It did, however, consume 82% of the five-hour usage limit.

Download the Astra GLB model

Rest poseStretch poseWrist close-up
Astra avatar in the resting poseAstra avatar in the final stretching poseAstra wrist and hand close-up

Comparison at a glance

ModelInterfaceReasoningTimeOverall result
Qwen3.8 27BOpenCode + llama.cppxhighAbout 4 h 40 min5/10
LunaCodexextra high15 min 11 s4/10
AstraCodexextra highAbout 36 min7/10

What I learned

The hard part was not making something that looked vaguely human. All three models could get there. The difficult part was making the complete asset behave like a usable production asset. And honestly, none of the models produced an asset at that level yet; even Astra’s result needs more work.

Hands exposed the difference most clearly. Fingers need their own bones, plausible proportions, usable deformation, and enough separation that the final pose remains readable. A model can satisfy the instruction to include fingers while still producing hands that do not hold up in a close-up. Other elements that were not explicitly mentioned in the prompt, such as the feet, were also not handled well by two of the three models.

The experiment also showed why 3D work benefits from iterative inspection. Geometry, rigging, skinning, animation, and presentation are connected. A small problem in the armature can become a broken wrist pose, a bad pose can make the model look poorly proportioned, and a good model can still be hard to evaluate if the camera and lighting are not considered.

My overall ranking is Astra first, Qwen second, and Luna third for this particular task. That result was honestly a bit unexpected, but Luna’s model was very ugly in comparison. This ranking should not be interpreted as a universal model ranking: Astra and Luna used a different interface and execution environment from Qwen, and the task rewards long-horizon computer use as much as it rewards raw modeling ability. I am sure that better quantization or more capable hardware for running Qwen could produce a better result.

What comes next

I also think that, in order to get better results, the 3D character could be designed separately—either created from scratch or downloaded or purchased—and the animation could then be handled as a separate stage. The character and the animation could be developed iteratively together, rather than leaving the whole process unattended. Also, when using a model for design, clear guidelines and feature requirements must be provided; otherwise, it can make the wrong decisions, as in the case of the feet.

We are still only at the beginning of this new generation of models, and more powerful models are being developed every day, so it will be interesting to see how the results hold up in a few months.

For this test, the most important result was not simply that one model performed better than the others. It was seeing that all three could move beyond a text description and produce a complete, inspectable 3D asset, even if none of them was ready for production. This was also a multimodal test: all three models received images as part of the prompt, so they had to combine visual references with written instructions. These models are already useful collaborators for this kind of work, but they still require clear constraints, supervision, and human judgment. They are capable enough to create, but not yet reliable enough to leave unattended.

Reproduce the experiment

The public 3D test repository contains the setup, generated outputs, reference attribution, and the exact prompt used for the runs.