Code Agents Level Up: Terminal Tasks, 3D Modeling, and the Shift Toward Engineering Execution

1. Terminal Task Capability: From “Running Commands” to “Completing a Real Development Loop”

Terminal task capability is one of the key dimensions for evaluating whether a code agent has real engineering value. Unlike traditional code completion or single-file generation, terminal tasks require a model to understand a relatively complete engineering goal and perform environment assessment, file operations, script execution, error diagnosis, and result verification within a command-line environment.

In terminal benchmarks such as Terminal Bench 4.0, models typically face multi-step tasks such as:

• Reading the project directory structure;
• Locating problematic files based on error messages;
• Modifying configuration or scripts;
• Re-executing commands and confirming results;
• Providing workable alternatives when permissions are restricted or dependencies are missing.

This process goes well beyond “generating a piece of code” and is much closer to a real developer’s daily workflow. As a result, terminal benchmark scores can, to some extent, reflect a model’s reliability in an “engineering loop.”

The change observed in this round is that a new generation of code agents has shown notable improvement in terminal task scores. Taking the latest version of a domestic model as an example, it achieved a score of 65.7 on Terminal Bench 4.0, a significant increase over the previous generation. More importantly, this score has surpassed the earlier result held by a frontier overseas model at the same period and now trails only one closed-source model known for strong engineering capabilities.

This shift in ranking is worth noting: it shows that in the specific direction of terminal tasks, the gap between different models is narrowing quickly. Capability ranges that were once dominated by a few closed-source models are now seeing more participants.

For developers, this means that when selecting a model, it is no longer sufficient to judge terminal task capability solely by brand recognition. A more practical approach is to:

1. Include terminal task capability in the evaluation criteria;
2. Use benchmark sets close to your own business or build your own test set;
3. Observe the model’s state retention across multi-turn interactions;
4. Check whether the model can provide effective remediation paths after failure.

Terminal tasks are not the product of a single inference pass but the accumulation of continuous decisions. Whether a model can maintain clear contextual understanding at every step often determines the final success of a task more than the quality of a single generation.

---

2. 3D Modeling and Spatial Reasoning: From Text Generation to Tool Operation

3D modeling is an important direction for extending code agent capabilities. In the past, large models in the 3D domain were mostly used for generating model parameters from text descriptions, constructing simple geometry, or understanding scene descriptions. The current change is that models are beginning to directly operate professional modeling tool scripts.

In the Bench CAD test, models relying on tool assistance have reached a score of 92.7, approaching the 95.9 and 96.2 scores of leading closed-source models. This score range means the model has practical capabilities in the following areas:

• Understanding geometric relationships in 3D space;
• Generating automation scripts for Blender, CAD, and other tools based on requirements;
• Adjusting layout, materials, and geometric parameters of models;
• Completing asset construction and refinement.

The practical change this brings is that developers no longer have to rely on external tool-calling protocols or complex plugin chains. Instead, they can let the model directly produce modeling scripts and then execute them in a local environment. The workflow is simplified into a loop: “natural language requirement → script generation → tool execution → result feedback.”

For example, a typical scripted modeling request can be described as:

Create a circular array of 12 cylinders, each with a radius of 0.3 meters,
a height of 4 meters, an array radius of 6 meters, and a material of basic metallic gray.

The model needs to convert this into an executable Blender Python script and correctly handle angle calculations, object duplication, material binding, and other steps. This requires the model to simultaneously possess mathematical computation ability, API usage ability, and 3D spatial imagination.

From practical results, current models can already handle most medium-complexity scripted modeling tasks. For more complex scenarios such as parametric building facades, mechanical part assembly, and interior layout adjustment, model performance still fluctuates, but it already has engineering assistance value.

It should be noted that 3D modeling tasks place higher demands on code generation quality. A script that is syntactically correct but semantically wrong may cause the model to generate a structure in 3D space that is completely inconsistent with expectations. Therefore, in practical applications, developers are advised to:

• Perform necessary parameter checks before script execution;
• Break modeling tasks into multiple small steps;
• Explicitly declare key geometric parameters;
• Keep script versions from each iteration for traceability.

Models can significantly improve modeling efficiency, but the final design judgment should still be made by the developer or designer.

---

3. Hallucination Control: From “Willing to Speak” to “Speaking Accurately”

Hallucination has always been a core obstacle in deploying code agents. For developers, a model that fabricates API names, invents function signatures, or incorrectly describes tool behavior poses risks that far outweigh its benefits.

In internal stress tests, the error rate of the new-generation model dropped from 23.4% in the previous generation to 8.3%. This numerical change may look like only a percentage improvement, but in real development scenarios, its significance is more intuitive:

• Out of every 100 inferences, the proportion of factual errors dropped from about 23 to about 8;
• In continuous multi-turn interactions, the probability of error accumulation decreased significantly;
• When dealing with details such as library versions, configuration items, and command-line parameters, the model behaves more conservatively.

The decline in hallucination rate usually comes from improvements in several areas:

1. Higher training data quality: cleaner code corpora, more accurate API documentation, and more complete tool usage records;
2. Optimized post-training strategies: stronger feedback signals guide the model to choose conservative answers when uncertain;
3. Enhanced context utilization: the model is better at extracting real information from the current environment rather than relying on vague patterns in memory.

For developers, although hallucinations cannot be completely eliminated, their impact can be further reduced through engineering measures:

• Explicitly require the model in the prompt to say “I am not sure” when uncertain;
• Require the model to provide references or verification methods for key APIs;
• Add result validation steps in automated workflows;
• Avoid letting the model guess system state without environment information.

The goal of hallucination control is not to make the model “always correct,” but to make errors easier to detect and easier to correct. Only when the error rate drops to a certain level does the model truly become ready for automated pipelines.

---

4. Cost Efficiency: The Balance Between Performance and Resource Consumption

In practical applications of code agents, cost is always an unavoidable variable. A complete terminal task execution may involve dozens or even hundreds of model calls. If the cost per call is too high, even with a high task success rate, the return on investment may still be unsatisfactory.

According to official statistics, the new-generation model is one of the best frontier models in cost control on Terminal Bench 4.0. In contrast, some low-cost models have extremely low per-call prices but perform noticeably worse on the same benchmark, resulting in a higher total cost to actually complete tasks.

This phenomenon reveals a key point: To evaluate the cost efficiency of a code agent, you cannot look only at unit price; you must look at the “effective cost of completing a task.”

Effective cost can be roughly estimated as follows:

Effective cost = cost per call × average number of calls required to complete a task

If a low-cost model needs 50 calls to complete a task while a medium-priced model needs only 8, the latter’s effective cost may be far lower than the former’s. More importantly, the more calls are required, the greater the risk that the task fails or deviates from the goal.

In engineering practice, cost optimization can focus on the following directions:

• Task tiering: use lightweight models for simple tasks and high-performance models for complex tasks;
• Caching and reuse: cache repeated context fragments to reduce redundant inference;
• Prompt compression: reduce input token count without losing key information;
• Batch processing: merge independent subtasks to reduce interaction rounds.

For enterprise users, model cost is only part of overall R&D cost. A more reliable model can reduce manual troubleshooting time, lower rework rates, and shorten delivery cycles. These implicit benefits are often more valuable than direct token expenses.

---

5. Overall Observation: Code Agents Are Entering a Stage of “Deep Tool Integration”

From terminal tasks to 3D modeling, from hallucination control to cost efficiency, the changes observed in this round point to the same trend: Code agents are shifting from “text generation tools” to “engineering execution proxies.”

Early code models mainly solved the problem of “writing a piece of code.” Users gave clear requirements, the model returned code snippets, and subsequent execution, testing, and debugging were all done by the developer. At the current stage, models are beginning to take on more execution responsibilities:

• They need to understand the current runtime environment;
• They need to determine which tool to use;
• They need to generate executable scripts;
• They need to adjust strategy based on execution results;
• They need to provide remediation plans when failures occur.

This shift places higher demands on models’ foundational capabilities, tool-calling abilities, and context management. At the same time, it redefines the collaboration relationship between developers and models.

Developers are no longer just “question askers” but more like “task definers” and “result validators.” Developers are responsible for clarifying goals, defining boundaries, and providing environment information, while models are responsible for exploring execution paths within those boundaries. This change in human-machine division of labor is an important sign of code agents moving toward maturity.

Of course, current models are still some distance from fully autonomous execution. In scenarios such as complex system design, architectural decisions, security compliance, and performance tuning, developers’ professional judgment remains irreplaceable. But for a large number of repetitive, process-oriented, and tool-operation-intensive tasks, models have already demonstrated sufficient engineering value.

For teams, a practical strategy at this point is to:

1. Start by introducing code agents in localized scenarios;
2. Choose models that match your own tech stack;
3. Build an internal evaluation case set;
4. Continuously track changes across model versions;
5. Treat human review as a necessary step during the transition period.

The pace of model capability improvement is worth watching, but engineering adoption has never been as simple as “switching to another model.” Reasonable process design, clear acceptance criteria, and effective rollback mechanisms are the foundation for making agents work reliably.

In this process, the compute, storage, container environments, and monitoring capabilities provided by cloud platforms are also playing an increasingly important role. A complete code agent application often requires coordination between underlying infrastructure and upper-layer model capabilities. Developers can gradually explore agent workflows suitable for their own teams within their engineering environments.