Large Language Models Directly Writing 3D Scripts: Technical Analysis of the Capability Leap

1. From Conversational to Capable: The Core of This Iteration

Over the past two years, the focus of large model evaluation has shifted three times: initially to knowledge QA and text generation, then to reasoning and math, and now rapidly towards “agentic tasks.” The current benchmark is whether a model can autonomously plan, execute, and correct errors in a real software environment until a task is fully completed.

Recent model updates from various institutions share a common characteristic: while base architectures haven’t changed drastically, massive post-training has led to step-level improvements on “hard tasks” like terminal coding, 3D modeling, and financial analysis. For instance, in public benchmarks, new open-source models have scored over 65 on terminal coding—approaching top closed-source models and surpassing international first-tier closed-source counterparts. In modeling-tool-based 3D evaluations, they scored over 92, narrowing the gap with leading closed-source models to under 3 points. On real financial document QA, they scored over 64, leading all evaluated models.

These numbers represent the intersection of three technical trends: agentic task execution, script-mediated precise control, and verifiable-reward-centric post-training. Let’s break these down.

2. Terminal Coding: The Litmus Test for Agentic Capabilities

2.1 Why Terminal Tasks are the Hardest

Terminal tasks are considered “hard benchmarks” because they test a complete engineering loop rather than single-shot code completion:

• Environment Interaction: Models must operate real command-line environments, install dependencies, run tests, and read errors.
• Long-Horizon Planning: A task often breaks down into dozens of steps; a misstep in any step amplifies subsequent costs.
• Error Recovery: Build failures, dependency conflicts, and path errors are the norm. Models must iterate based on feedback rather than starting over.

A typical agent loop can be abstracted as follows:

# Agent terminal task loop (pseudo-code)
task = load_task("Fix build failure and add unit tests")
history = []
while not task.solved:
    observation = terminal.exec(task.next_action)       # Execute command, capture output
    analysis    = llm.reflect(task, history, observation)  # Identify root cause
    task.next_action = llm.plan(analysis, tools)        # Plan the next command
    history.append((task.next_action, observation))

2.2 Beyond Scores: Evaluating Cost

Benchmark scores answer “can it do it,” while cost curves answer “is it worth it.” Industry observations show that single-task cost differences among frontier models on the same terminal benchmark can vary by multiples. Some models trade lower costs for significantly lower success rates, while others use higher inference overhead to achieve near-perfect stability. For engineering teams, the true focus should be on the position along the cost-score Pareto frontier—who can push the success rate highest under the same budget.

Recent models have pushed the unit cost of terminal tasks to the lowest tier of frontier models while maintaining a first-tier success rate. This is driven by three factors: post-training reduces detours and invalid retries; inference-side speculative decoding and KV cache optimization lower per-step overhead; and data compression and batch processing for tool-calling sequences further amortize costs.

2.3 Implications for the Open-Source Ecosystem

Open-source models stepping into the first tier for high-barrier tasks like terminal coding is more significant than a single benchmark score. Enterprises can use open-source weights for private deployment, keeping code and data strictly within their internal networks while achieving task completion rates close to closed-source frontiers. This directly challenges the default assumption that “sensitive scenarios can only use closed-source APIs.”

3. Direct 3D Script Writing: Applied Spatial Reasoning

3.1 Why Script Writing is a Pragmatic Approach

There have long been two routes for 3D content production: end-to-end generation (text directly to mesh or point cloud) and procedural generation (models output scripts executable by modeling software). The latter offers distinct advantages:

• Precise Control: Geometric dimensions, material parameters, and lighting positions are explicit values, making them modifiable and reproducible.
• High Editability: Changing a single parameter can batch-generate variants, rather than being a one-shot deal.
• Industrial Pipeline Compatibility: Models generated via scripts can directly enter rendering, animation, and 3D printing workflows.

Early solutions required external orchestration frameworks to call modeling software. New-generation models can directly write script interface code for professional modeling software, complete asset construction and detailing, and adjust layout, materials, and geometry. This requires a stable understanding of software APIs, 3D coordinate systems, and geometric topology simultaneously—essentially a combination of spatial reasoning and code generation capabilities.

3.2 A Runnable Example

Using “generate a 3D-printable desk lamp” as an example, the model-generated script looks roughly like this:

# Pseudo-code: Parametric desk lamp modeling script generated by an LLM
scene = ModelingSession()
# 1) Basic geometry: Base and support pole
base = scene.primitives.cylinder(radius=0.06, height=0.015)
pole = scene.primitives.cylinder(radius=0.008, height=0.34)
pole.translate(z=0.015)
# 2) Lampshade: Formed by rotating a contour curve, easy for later parametric adjustments
profile = scene.curve.bezier([(0.05, 0.30), (0.11, 0.36), (0.13, 0.42)])
shade = scene.ops.lathe(profile=profile, segments=96)
# 3) Materials and lighting
shade.material = scene.materials.translucent(
    color=(1.0, 0.92, 0.75), transmission=0.55)
scene.lighting.add_area_light(position=(0.3, 0.4, 0.8), power=40)
# 4) Export print file
assert shade.min_wall_thickness() >= 0.002   # Validate minimum wall thickness
scene.export("desk_lamp.stl", unit="mm")

Note step 4: Wall thickness validation is a critical prerequisite in 3D printing. The model actively generating such assertions indicates its understanding has deepened from “drawing it” to “manufacturing it.”

3.3 From Benchmarks to Product Loops

In modeling-tool-based 3D evaluations, new open-source models have scored over 92, narrowing the gap with top closed-source models to around 3 points, while significantly distancing themselves from other open-source models. This represents the best result in the open-source camp. The evaluation tests exactly: “Given a modeling software environment, can the model complete modeling, modification, and export according to requirements?”

The product-side loop has also formed. Some platforms have launched online 3D generation features supporting real-time preview, online editing, one-click 3D print file export, and the ability to export results as videos or GIFs for sharing. Public cases cover interior scene setup, complex mechanical structure modeling (like scroll engines), and printable physical objects (like desk lamps), proving a complete validation chain from visual rendering to tangible prints.

3.4 Will It “Break the Circle” in the Creative Industry?

Will direct 3D script writing break out into the creative industry? The answer is yes, but with conditions:

• Where it will break out: Concept design, prop assets, scene setup, and educational models. These scenarios have high tolerance for precision variance but demand fast iteration. The “script generation + online editing” workflow can compress hours of manual modeling into minutes.
• What it won’t replace yet: Film-grade character modeling, high-precision topology, rigging, and animation. These rely on artistic aesthetics and manual details; current script generation can only handle primary assets and rough drafts.

The real barrier isn’t the model but the workflow. Once “generate—preview—edit—export” forms a closed loop in a single interface, and exports are directly usable (printable, asset-ready), non-technical creators will have the incentive to migrate. The capabilities are here; what remains is product refinement.

4. Financial Scenarios: The Testing Ground for Long-Chain Reasoning

Financial analysis tests models differently than coding. Inputs are often hundred-page real-world documents (financial reports, announcements, research papers). Tasks usually involve retrieval, cross-document verification, and multi-step numerical reasoning. A single error pollutes the final conclusion. A typical reasoning chain is:

1. Retrieval: Locate the section and table containing target metrics from massive documents.
2. Verification: Check if the same metric is consistent across different documents and footnotes; verify if units and currencies require conversion.
3. Calculation: Execute multi-step operations like YoY, MoM, and ratio breakdowns on verified numbers.
4. Attribution: Cross-reference numerical conclusions with business narratives to avoid “right numbers, wrong story.”

Public benchmarks show new models scoring over 64 on tests based on real financial documents that evaluate retrieval, cross-document verification, and multi-step numerical reasoning, leading all evaluated models. On benchmarks covering the complete investment workflow (from target screening to profitability analysis), they showed significant improvement over previous generations, scoring just behind the best closed-source model. This proves post-training not only boosts general reasoning but is also evolving deeper into “domain workflow support.”

5. Hallucination Control: From “Generating Correctly” to “Refusing to Fabricate”

In high-risk domains, hallucination rates are a more critical metric than peak capabilities. Industry stress-testing typically constructs highly inductive question sets—questions containing false premises, ambiguous references, or non-existent facts—to see if the model plays along or explicitly corrects the premise. Public data shows new models have reduced hallucination error rates from over 20% in previous generations to around 8%, entering single-digit territory. This relies on a combination of techniques:

• Verifiable-Reward Post-Training: For tasks with objective answers (executable code, verifiable numbers, retrievable facts), execution results rather than human preferences are used as reward signals, directly suppressing “fabrication” behavior.
• Retrieval Grounding: Forcing citations of evidence before generating key claims; if no evidence exists, downgrading the statement or refusing to answer.
• Calibration Training: Aligning the model’s confidence with actual accuracy, actively expressing uncertainty when “unsure.”

Crucially, hallucination rates and capability limits do not conflict. Stress tests show that stronger models with sufficient post-training actually have lower hallucination rates and fewer invalid attempts, meaning fewer “made-up answers.”

6. Security Research: Capability Spillover and Governance

An easily overlooked signal: as post-training scales, model capabilities in vulnerability research tasks also continue to improve, including understanding binary behavior, analyzing crash samples, and constructing reproduction paths. This is a boon for defenders (automated auditing, patch suggestions, fuzz testing guidance) but equally adds pressure to the attack surface.

Engineering teams should simultaneously do three things: treat all model-generated code as untrusted input, sandboxing and statically checking it; enable tiered management and audit logs for requests involving vulnerability details; and establish internal red-team evaluations, treating “abuse risk” as an acceptance criterion weighted equally with “capability metrics.”

7. Technical Foundation: Why Post-Training is the Deciding Factor

Looking at this leap collectively, the shared technical foundation is post-training, which has evolved in three ways:

1. From Preference Alignment to Verifiable Alignment: Early models relied on human preference ranking, risking “sycophancy.” Now, there’s a massive shift towards using execution results as rewards. Test pass rates, geometry validation rates, and numerical accuracy are inherently verifiable signals.
2. In-Environment Training: Models “move into” real environments like terminals and modeling software during training. They learn “operational workflows” rather than just “answer text,” generalizing better to new tasks.
3. Data Flywheel: Failed execution trajectories are corrected and fed back into the training set, forming a “generate—execute—feedback—retrain” loop. Data utilization is vastly higher than with static corpora.

The takeaway for users: when evaluating a model, don’t just look at what it “knows,” but at how many iterations it takes to get it right in your real environment.

8. Actionable Advice for Developers

Based on the analysis above, here are four actionable recommendations:

1. Evaluation-Driven Selection. Build a small evaluation set (20-50 real cases) using your own tasks. Record both success rates and unit costs, and plot a Pareto curve before making a decision. Enterprises can also leverage evaluation and hosting capabilities provided by platforms like Baidu AI Cloud to integrate model services into their existing business pipelines, avoiding the redundant investment of building an in-house inference stack.
2. Treat Models as “Code Generators,” Not “Executors”. Have the model output scripts or code, execute them deterministically in a sandbox, and have humans review critical outputs. This paradigm applies equally to 3D assets, data processing, and DevOps automation.
3. Build a Validation Layer for Generated Artifacts. Validate geometric legality (manifold, normals, wall thickness) for 3D scripts, check numerical standards for data analysis scripts, and set whitelists and rollback points for terminal commands:

# Sandbox validation workflow for generated scripts (pseudo-code)
with Sandbox(allow=["modeling_api"], deny=["os", "network"]) as sb:
    static_check(generated_code)     # Static check: dangerous calls and unauthorized APIs
    result = sb.run(generated_code)  # Isolated execution
    validate(result.mesh)            # Geometric validation: manifold, normals, wall thickness
    archive(result, versioned=True)  # Archive output, retaining version and prompt

1. Replace Subjective Feelings with Hallucination Stress Tests. Construct inductive question sets containing false premises and non-existent facts, and include the “correction/refusal rate” as an acceptance standard for model upgrades.

9. Conclusion

The value of this model iteration lies not in setting new benchmark highs, but in three curves simultaneously crossing the practical threshold: terminal task success rates approaching top closed-source models at the lowest unit cost tier; direct 3D script writing打通ing the complete loop of “generate—edit—print—share”; and hallucination rates pressed down to single digits. As “models that write code” evolve into “models that work in real software environments,” originally high-barrier fields like 3D creation, financial analysis, and automated DevOps will experience a workflow rewrite. For developers, the most important thing now isn’t asking “which model is the strongest,” but quickly turning your business tasks into measurable, verifiable benchmarks. Whoever completes this step first will capture the dividend of this capability wave.