Advanced Post-Training for LLMs: Breaking Down Capabilities from Code Agents to 3D Script Generation

Recently, a domestic large language model team released a new post-trained version, presenting noteworthy benchmark results across three key directions: code tasks, 3D modeling, and financial document reasoning. Rather than focusing on specific brands or product models, this article treats the update as an observational sample. We will deconstruct the underlying logic of how the “post-training” technical trajectory drives capability enhancements and explore how developers can integrate these capabilities into their own engineering systems.

I. Why Post-Training is the Primary Source of Capability Leaps

While the base model determines the capability ceiling, what truly dictates a model’s usability in vertical tasks is the post-training phase. Post-training typically involves three types of work:

1. Supervised Fine-Tuning (SFT): Utilizing high-quality task trajectory data to “align” the base model’s general capabilities to specific task formats. For example, training the model to output tool-calling parameters in a fixed format.
2. Preference Optimization (RLHF/DPO, etc.): Using pairwise preference data to make the model favor more robust and human-expected paths among multiple viable solutions.
3. Reinforcement Learning with Verifiable Rewards (RLVR): For tasks with objective criteria—such as code, math, and structured generation—this method uses signals like unit tests, compiler feedback, and schema validation as rewards to directly optimize the probability of “getting it right.”

Code and 3D script generation fall perfectly into the third category: whether the output is correct can be automatically verified. This is the fundamental reason the new generation of models shows significant improvements in these two directions. It is not that the model has “seen more,” but rather that the training signals are denser and closer to the real execution environment.

II. Code Agents: Capabilities and Costs of Terminal Tasks

2.1 The Significance of Terminal Benchmarks

Terminal-style benchmarks (like Terminal Bench) do not examine single-function completion. Instead, they test a model’s ability to perform multi-step operations in a real shell environment: reading files, modifying configurations, running tests, and retrying based on error logs. These tasks require a composite set of model capabilities:

• Long-context management: Maintaining goal tracking across multiple rounds of tool calls.
• Error recovery: Understanding stderr after a command fails and adjusting the strategy accordingly.
• Instruction adherence: Strictly outputting according to the tool schema to avoid parsing failures.

If a model can score close to top-tier closed-source models on these tasks, it indicates that its tool-calling stability and multi-step planning capabilities have reached a practically usable threshold.

2.2 Cost: An Underestimated Engineering Metric

Many discussions focus solely on scores, but in production environments, cost per task is often more critical than peak scores. On the same benchmark, the single-task cost among different models can vary by multiples. For developers, a pragmatic selection method is to calculate the “effective cost”:

Effective Cost = Average Token Consumption per Task × Unit Price ÷ Task Pass Rate

If a low-priced model has only half the pass rate of a high-scoring model, its effective cost may not necessarily be lower. Therefore, when evaluating, it is recommended to record three metrics simultaneously: pass rate, average interaction rounds, and average token consumption. Comparing only unit prices can lead to incorrect conclusions.

2.3 Integration Recommendations

When integrating code agents into an engineering pipeline, consider these practical guidelines:

• Restrict tool whitelists: Expose only necessary commands and file paths to reduce the risk of accidental operations.
• Set round limits and timeouts: Prevent the model from consuming budgets in infinite loops.
• Retain full trajectory logs: The sequence of tool calls is valuable post-training data that can be used for subsequent fine-tuning.
• Perform secondary validation on critical steps: For example, run a static check before applying a patch.

III. 3D Script Generation: Direct Modeling Without Specialized Protocols

3.1 Technical Route Differences

Traditionally, there are two ways for a model to operate 3D software. The first uses an intermediate layer (like a model context protocol) to wrap software capabilities into tools for the model to call. The second involves the model directly writing scripts for the target software (such as the modeling software’s built-in scripting language), which the software then executes itself.

The latter approach offers several advantages:

• Greater expressiveness: Scripts can describe parametric and procedural modeling logic, whereas tool wrapping often covers only a limited set of operations.
• Reproducibility: Scripts are version-controllable assets, facilitating team collaboration and regression testing.
• Fewer dependencies: No need to maintain an additional protocol service, resulting in a shorter deployment chain.

The trade-off is a higher requirement for the model’s code generation quality. A single geometric parameter error in the script can render the entire model unusable.

3.2 Spatial Reasoning is the Real Threshold

The difficulty of 3D generation lies not in “writing syntactically correct scripts” but in “writing geometrically sound scripts.” The model needs to understand:

• Coordinate systems and transformation order (the composition of rotation, scaling, and translation).
• Topological consequences of boolean operations (e.g., difference operations may produce non-manifold edges).
• Separation of materials and geometry (which properties belong to the object and which to the material node).

Based on public demonstrations, tasks like interior scene setup, mechanical structure modeling, and lighting product modeling can now be completed via scripts—from rough drafts to detailed adjustments. This indicates that the model has achieved initial reliability in the step of “translating natural language requirements into parametric geometric descriptions.”

3.3 Online Preview and Export Pipeline

Complementary online preview and editing capabilities close the loop of “generate—inspect—modify.” The model outputs the script, the platform renders the visual result, and the user adjusts the layout and materials directly in the browser before exporting to a printable format or video. The engineering value of this pipeline lies in freeing 3D content production from specialized software, lowering the barrier to entry for non-professional users.

For developers looking to build similar capabilities, core modules should include: a script sandbox execution environment, geometry validation (manifoldness, normal direction, unit scale), a render preview service, and export format conversion. The sandbox execution must enforce resource and permission isolation to prevent malicious scripts from affecting the host.

IV. Financial Document Reasoning: Retrieval, Verification, and Multi-step Numerical Calculation

The difficulty of financial scenarios differs from code scenarios: there is no compiler to judge right or wrong, but the answer can often be strictly derived from the document. These tasks test three capabilities:

1. Cross-document retrieval: Establishing relationships between different tables and footnotes within the same financial report.
2. Numerical reasoning: Unit conversion, year-over-year and month-over-month calculations, and caliber alignment.
3. Anti-hallucination: Clearly stating “cannot be determined” when information is missing, rather than fabricating numbers.

Based on benchmarking trends, the score improvements of new-generation models in this area primarily stem from two factors. First, more stable parsing of table structures within long contexts. Second, the introduction of more “refusal to answer” samples during the post-training phase, making the model more inclined to output conservative answers when evidence is insufficient. The latter is particularly crucial for financial scenarios—the cost of an incorrect number is far higher than a simple “I don’t know.”

Recommendations for engineering implementation:

• Split retrieval and reasoning into two phases. In the retrieval phase, use rules or vector recall to lock in candidate document fragments; in the reasoning phase, hand them over to the model.
• Require the model to provide source fragments for every numerical conclusion to facilitate manual review.
• Establish an internal stress testing set specifically constructing samples where “the answer does not exist in the document” to continuously monitor the hallucination rate.

V. Three Principles for Turning Capabilities into Solutions

First, select models based on task form, not leaderboard rankings. Code tasks require tool-calling stability and effective cost; 3D tasks require geometric soundness; financial tasks require anti-hallucination performance. The weighting of these three is entirely different.

Second, treat post-training data as a long-term asset. Tool call trajectories, failure cases, and manual correction records from production environments are high-value inputs for the next round of fine-tuning. It is recommended to log them in a structured manner from day one.

Third, drive iteration with verifiable signals. For any task where right and wrong can be automatically determined (compilation success, schema validation, numerical comparison), establish automated regression. This provides an objective basis for model upgrades rather than relying on subjective feelings.

Conclusion

The most noteworthy aspect of this update is not a single benchmark score, but the clear technical path it demonstrates: deepening post-training with verifiable rewards to rapidly push models toward a usable level in three types of tasks with objective criteria: code, geometry, and numerical reasoning. For developers, understanding this path is far more valuable than memorizing specific numbers—because when the next update arrives, the methodology will still apply.