Dual Breakthroughs in LLMs: Deep Dive into Terminal Coding and 3D Modeling Capabilities

I. Background: From Code Generation to Terminal Execution

Over the past year, the competition among Large Language Models (LLMs) in code generation has evolved from simple “function completion” to “completing real-world engineering tasks.” Real-world engineering tasks require models to operate within a terminal environment: reading error logs, modifying files, executing commands, and iteratively verifying until a runnable repository passes its tests. These tasks demand significantly higher capabilities in context management, tool invocation discipline, and error recovery than single-turn code generation.

Against this backdrop, terminal-level coding benchmarks have become a critical metric for measuring a model’s engineering utility. A recent version of a domestic frontier model achieved a milestone score of 65.7 on such a benchmark. For the first time among domestic models, this places it in the tier “just behind top-tier closed-source models,” surpassing newly released model versions from overseas competitors in the same period. The significance of this result lies not in a single-point victory, but in proving that domestic models have achieved engineering viability in the paradigm of multi-turn tool invocation + environment feedback loops.

This article will explore these advancements along two main trajectories—terminal coding tasks and 3D modeling—analyzing the technical implications, cost structure changes, and how developers can implement these capabilities in practical projects.

II. Terminal Coding Tasks: Three Dimensions of Capability Leap

2.1 Capability Composition Behind the Score

The scoring logic of terminal-level benchmarks is typically not about “how elegant the code is,” but “whether the task is completed.” A typical task might involve: locating a failing test, modifying source code, adjusting dependencies, and re-executing verification. The model must maintain awareness of the repository structure throughout this process and re-plan after every command output.

The meaning of a 65.7 score can be broken down into three points:

• Long-range planning capability: The model can maintain its goal without drift over dozens of interaction rounds, rather than falling into repetitive trial-and-error by the third or fourth round.
• Tool invocation discipline: The granularity and sequence of commands are logical, avoiding common issues like “executing a large script at once, making errors impossible to locate.”
• Error attribution capability: The ability to extract key signals from compiler or testing framework outputs, rather than being overwhelmed by noisy logs.

These three points are precisely the differences developers perceive most easily during actual use. A score approaching top-tier closed-source models indicates that for most medium-complexity tasks, the model’s first-time fix rate is sufficient to support a “human review + machine modification” collaboration mode.

2.2 Cost Structure: An Underestimated Selection Variable

Beyond performance, cost deserves closer attention. In the official statistics of this benchmark, this new version is among the best in cost control among frontier models. Here, two concepts must be distinguished:

• Single-call cost: Determined by the input/output token pricing.
• Total task cost: Determined by the combination of unit price × number of rounds × failure retry rate.

Terminal tasks are characterized by multiple rounds and long contexts. Therefore, a model with a low single-call cost does not necessarily have a low total cost—if it requires more rounds to converge, the total consumption might be higher. Conversely, a model with a moderate unit price but a shorter convergence path might offer significantly better end-to-end cost efficiency. Some models promoting extreme low prices do have lower single-item pricing, but their inability to complete complex tasks leads to retry overheads that offset their unit price advantage.

For developers, this means model selection should be evaluated using “total task cost” as the metric. An actionable practice is to extract 20 to 50 real issues from your codebase, run the complete repair process using candidate models, record token consumption and success rates, and then calculate the “average cost per successful repair.” This metric is much closer to production reality than any leaderboard score.

2.3 Implementation Suggestions for Engineering Integration

When integrating such models into the R&D pipeline, it is recommended to follow a tiered routing strategy:

# Pseudo-code: Tiered task routing example
def route_task(task):
    if task.complexity == "single_file_patch":
        return cheap_model      # Small single-file changes, prioritize cost
    elif task.complexity == "cross_module_refactor":
        return strong_model     # Cross-module refactoring, prioritize success rate
    else:
        return strong_model_with_human_review

The core idea is to route by task complexity rather than using a single model for all scenarios. Concurrently, a sandbox execution environment should be established to limit the scope of commands, and automated regression verification should be applied to every patch generated by the model. The primary risk in terminal tasks comes from modifications that “appear successful but actually break things,” making the verification phase indispensable.

III. 3D Modeling: From Tool Dependency to Direct Script Driving

3.1 Improvement in Spatial Reasoning

The enhancement in 3D modeling capabilities is the other main trajectory of this update. Unlike coding tasks, 3D creation demands that the model excel in spatial reasoning and structured description: the model must understand hierarchical object relationships, geometric constraints, and the interplay between materials and layout.

In benchmarks oriented towards CAD scenarios, this version scored 92.7 under conditions where tools are utilized. This places it in the same tier as top-tier closed-source models scoring 95.9 and 96.2, representing the highest score among open-source models for this project currently. This score range indicates that the model can handle “constrained geometric construction” tasks, rather than merely generating descriptive text.

3.2 Direct Script Driving Without External Tool Protocols

A more practical change lies in the simplification of the interaction method. Previously, having a model operate professional modeling software typically required an external tool protocol as an intermediate layer, responsible for translating natural language intent into software-executable calls. This approach has a long chain, high debugging costs, and is limited by the scope of interfaces exposed by the protocol.

The new version supports directly writing scripts for modeling software to complete asset scaffolding, detail refinement, layout adjustments, and modifications to materials and geometric parameters. The practical benefits of this include:

• Broader interface coverage: Scripts can access the software’s native API without being limited by the intermediate layer’s exposed scope.
• Shorter debugging chain: When errors occur, they can be directly pinpointed to specific lines in the script, rather than being troubleshooted back and forth between the protocol layer and the software layer.
• Stronger reusability: The generated scripts themselves are version-controllable assets that can be standardized into a team’s modeling workflow.

A typical script-driven modeling workflow can be abstracted as follows:

# Pseudo-code: General structure for script-driven modeling
scene = create_scene()
base = add_primitive(scene, "cube", size=(2, 1, 0.2))
apply_material(base, roughness=0.4, metallic=0.1)
detail = add_bevel(base, width=0.02, segments=3)
layout(detail, position=(0, 0, 0), rotation=(0, 0, 0))
export(scene, "asset.glb")

The model’s value lies in generating and adjusting such scripts based on natural language requirements, including parameter values, object hierarchies, and combinations of constraints. What developers need to do is establish a template library and validation rules for the scripts to ensure the output conforms to the project’s asset specifications.

3.3 Quality Control During Implementation

Although the direct script driving mode has a shorter chain, it requires stricter control over output quality. It is recommended to incorporate three checkpoints into the workflow:

1. Syntax and API validation: Perform static checks before execution to avoid interruptions caused by incorrect interface names or parameters.
2. Geometric rationality check: Conduct basic validations on the generated assets, such as bounding boxes, polygon count, and normal directions, to intercept obvious anomalies.
3. Render regression comparison: Retain baseline render images for key assets, and perform pixel-level or perceptual-level comparisons after new scripts produce outputs.

These three checkpoints elevate “the model-generated script can run” to “the generated asset is usable,” which is the critical step from demonstration to production.

IV. Comprehensive Assessment: The Triangular Balance of Capability, Cost, and Scenario

Looking at both trajectories together provides a clearer assessment framework. The improvement in model capabilities is not a linear substitution but forms a triangle with cost and scenarios:

• In terminal coding tasks, a success rate approaching top-tier closed-source models, combined with superior cost control, makes it suitable for handling medium-to-high complexity automation tasks within the R&D pipeline.
• In 3D modeling, the direct script driving capability lowers the threshold for tool-chain integration, making it suitable for scenarios requiring batch asset generation or parametric modeling.
• In cost-sensitive tasks, routing should be based on task complexity rather than uniformly defaulting to the lowest-priced model.

For enterprises and developers, what truly needs to be established is not a conclusion on “which model is the strongest,” but a reusable evaluation methodology: measure success rates using proprietary task sets, calculate costs using an end-to-end metric, and control risks using sandboxes and regression verification. Models iterate rapidly, and methodology holds more long-term value than a single model selection.

As domestic models continue to strengthen their tool invocation discipline, spatial reasoning, and script generation, LLMs are transitioning from “assisting in writing code” to “assisting in completing engineering tasks.” This shift also changes the requirements for developers: one must know how to write prompts as well as design verification loops; one must pay attention to leaderboard scores as well as the actual cost of each successful delivery. Mastering these two aspects is the only way to truly transform capability leaps into productivity.