Post-Training Iterations in Chinese LLMs: Advances in Coding Agents, 3D Modeling, and Financial Reasoning

Why Post-Training Versions Deserve Separate Discussion

A full model iteration in LLM engineering typically involves two stages: pretraining of the base model, and post-training targeted at specific capability dimensions. The former determines the model’s knowledge capacity and language foundation; the latter directly determines how usable the model is on real tasks—instruction following, tool calling, long-horizon reasoning, and format stability are almost entirely polished during post-training.

A common misconception is that post-training versions are just “minor touch-ups.” Real-world engineering experience suggests the opposite. Once base capabilities reach a certain level, the marginal gains from post-training are often substantial—especially in agentic tasks, where the model must call tools across consecutive steps, read feedback, and correct errors. Any drop in stability at a single point in the chain causes the entire task to fail. So when evaluating a post-training update, the focus should not be single-metric benchmark scores, but success rates and cost structures on long-chain tasks.

This article reviews a recent post-training update of a Chinese model across three dimensions—coding agents, scripted 3D modeling, and financial document reasoning—with an emphasis on what these changes mean for developers, and on how the “write scripts directly to operate professional software” paradigm might reshape the toolchain.

Coding: Position Shifts on Terminal Tasks and Cost Structure

Why Terminal Benchmarks Are Harder

In coding evaluation, terminal-based tasks are a particularly tough category. Unlike single-turn code completion, terminal tasks require the model to work in a real command-line environment to:

1. Understand a goal described in natural language
2. Plan a multi-step sequence of operations
3. Execute commands and parse the results
4. Self-correct based on error messages
5. Converge to the correct state within a limited number of steps

This is essentially a sequential decision-making problem with feedback. The model doesn’t just need to “write code”—it needs to “debug the code it wrote.” Score distributions on these benchmarks tend to be far steeper than on plain code generation: the gap between top-tier and mid-tier models gets significantly amplified.

Key Signals from This Iteration

Based on public information, this post-training version has entered a new position range on terminal-based coding tasks: it leads among comparable Chinese models, has narrowed the gap with top closed-source models, and performs notably well on cost control.

Two points are worth unpacking:

First, the position change matters more than the absolute score. In agentic tasks, moving from “clearly behind” to “close to the top” means the model has materially improved stability in multi-step error correction, command semantics understanding, and output format constraints. Improvements like these typically come from injecting high-quality trajectories into post-training data, along with reinforced constraints on tool-call formats.

Second, cost structure is a hidden gate in model selection. A model with high scores but excessive per-task token consumption and frequent retries will see deployment costs spiral out of control. In terminal tasks, cost consists of three main components:

• Input side: the length of environment feedback (command output, error messages) fed back into the context
• Output side: the commands and explanatory text the model generates
• Retry side: the number of re-planning rounds after failure

Staying restrained across all three suggests the model has improved its probability of “getting it right the first time,” reducing reliance on trial and error. For developers, this is more valuable than raw scores—it maps directly to API bills and task latency.

Practical Advice for Developers

If your team is building coding agents, evaluate models from these angles:

# Pseudocode: a minimal evaluation loop for terminal tasks
def evaluate_agent(model, tasks, max_steps=15):
    results = []
    for task in tasks:
        state = init_env(task)
        history = []
        for step in range(max_steps):
            action = model.plan(task.description, history, state.observation)
            state = state.step(action)
            history.append((action, state.observation))
            if state.done:
                break
        results.append({
            "success": state.success,
            "steps": len(history),
            "tokens": state.token_usage,   # the core cost metric
        })
    return results

When evaluating, don’t just look at the success rate—always track average steps and average token consumption as well. Many models have similar success rates but very different step distributions, and final costs can differ by several multiples.

3D Modeling: Direct Script Generation Bypasses the Middle Layer

From “Calling Plugins” to “Writing Scripts Directly”

Previously, the mainstream approach to involving LLMs in 3D creation was to wrap modeling software capabilities as tools behind intermediate protocols like MCP (Model Context Protocol). The upside is standardized interfaces and controllable permissions; the downside is that the middle layer itself becomes the bottleneck—tool descriptions are limited in expressive power, and the model cannot express complex geometric logic or parametric relationships.

A clear signal from this iteration: the model can now generate scripts for professional modeling software directly, without relying on intermediate protocols—handling asset construction, refinement, layout adjustments, and changes to materials and geometry parameters. The technical implications deserve a closer look:

• Expressiveness: scripting languages are Turing-complete. The model can express loops, conditionals, and parametric modeling, far beyond the expressiveness ceiling of fixed tool interfaces
• Reproducibility: scripts are plain text—versionable, diffable, and re-runnable with different parameters
• Debugging loop: script execution errors are explicit, so the model can self-correct based on them

In other words, the model has shifted from “operating software” to “writing programs that operate software.” That is a jump in abstraction level.

Spatial Reasoning Is the Real Bottleneck

The hard part of script-based modeling is not syntax—it’s spatial reasoning. Without visual feedback, the model must internally construct the 3D structural relationships of objects: relative positions of parts, rotation order, scaling basis, and choice of coordinate system.

A classic pitfall is transform order. In most modeling scripts, the order in which translation, rotation, and scale are combined directly changes the result:

# Different transform order, completely different results
obj.transform(location=(1, 0, 0), rotation=(0, 0, 45), scale=(2, 2, 2))
# vs.
obj.transform(scale=(2, 2, 2), rotation=(0, 0, 45), location=(1, 0, 0))

The first translates then rotates, so the object rotates around the world origin; the second scales, then rotates, then translates—entirely different behavior. The model must understand this semantic difference rather than mechanically concatenating parameters.

Judging by public modeling benchmark performance, this version scores close to top closed-source models in tool-dependent scenarios and ranks well among open-source models. This suggests its spatial reasoning and script organization skills have crossed the “usable” threshold.

Online Preview and Export: Closing the Loop

Even more notable than raw model capability is the supporting pipeline: online preview, in-browser editing, 3D model downloads, 3D printing export, and sharing in the form of videos and animated images.

This pipeline fixes a long-standing gap. Previously, model-generated scripts or model files had to be imported into desktop software for verification—slow feedback cycles, high barriers to entry. Moving preview and lightweight editing online compresses the “generate—verify—correct” loop into the browser, significantly lowering the barrier for non-professional users.

For creative tools, this could be a breakout signal: when the input to modeling shifts from “manual dragging” to “description + scripts,” developers with basic logical thinking can enter 3D content production faster, without spending months learning the details of professional software.

Financial Document Reasoning: Retrieval, Verification, and Multi-Step Numerical Computation

Why This Task Is Genuinely Hard

Financial document analysis is not simple Q&A. It typically involves:

• Retrieval: locating relevant passages in large volumes of real documents
• Cross-document verification: the same metric may be defined inconsistently across different reports
• Multi-step numerical reasoning: computing final results through chained formulas
• Hallucination suppression: numeric tasks are extremely sensitive to fabrication—one made-up number invalidates the entire conclusion

So evaluating financial reasoning requires looking at accuracy and hallucination rate together. An evaluation that discusses scores but not error rates is incomplete.

Two Observations from This Iteration

Public data shows this version leads on a complex analysis benchmark built on real financial documents, and has improved significantly on a benchmark covering the full investment workflow (from target screening to earnings analysis), now approaching the top tier.

Even more noteworthy is hallucination control: in internal stress tests, the error rate dropped significantly from the previous generation’s relatively high level. The practical significance is this: financial scenarios have extremely low fault tolerance—users tolerate “plausible but wrong” output far less than in other domains. A falling hallucination rate is what determines whether this class of model can enter production workflows rather than staying at the demo stage.

Engineering Constraints for Real Deployment

Even with capable models, financial deployments require attention to:

1. Traceable results: every number should point back to its source passage. Consider enforcing citation snippets in the prompt
2. Externalized computation: hand numeric calculation to deterministic code; let the model only extract and orchestrate, reducing arithmetic hallucinations
3. Definition checks: validate consistency when the same metric is taken from multiple sources; surface conflicts explicitly rather than silently choosing one

# Recommended: strip numeric computation out of model output
extracted = model.extract(doc, schema={"revenue": "number", "period": "string"})
verified = checker.cross_validate(extracted, reference_docs)
final = calculator.compute(verified)   # deterministic computation, not model-generated

Overall Assessment: Where This Iteration Stands

Looking at the three dimensions together yields a fairly restrained conclusion:

• Coding agents: now in a comparable range with top models, with cost advantages constituting real competitiveness
• Scripted 3D modeling: past the usability threshold, with the supporting pipeline completing the verification loop—poised to spread into creative scenarios
• Financial reasoning: accuracy and hallucination control improving in tandem, now worth discussing for production environments

One caveat deserves emphasis: there is always a gap between benchmark scores and real business performance. Benchmark tasks are closed and well-defined; real tasks are open with ambiguous requirements. The reasonable expectation for this class of model is: a general foundation with significantly enhanced capabilities, not an out-of-the-box domain solution. Real value release still depends on how teams build evaluation sets, toolchains, and validation mechanisms around it.

For developers, the most pragmatic move is not chasing leaderboards. It is building a small-scale evaluation set from your own real business tasks as soon as possible, measuring success rate, steps, and cost, and letting the data answer the question: “does this model actually work for my use case?” That is more convincing than any public benchmark.