Post-Training Advances in Domestic LLMs: Code, Modeling, and Financial Reasoning

As foundation model iteration cycles stabilize, the real differentiator in user experience increasingly comes from the post-training stage. Drawing on a recent model version upgrade aimed at professional tasks, this article breaks down capability changes across four directions—code agents, 3D script-based modeling, financial document reasoning, and hallucination suppression—and discusses what these changes mean for developers and enterprise users.

1. Why Post-Training Has Become the Main Battleground for Capability Leaps

Foundation pre-training determines a model’s knowledge breadth and language foundation, while post-training (instruction fine-tuning, preference alignment, verifiable-reward reinforcement learning, etc.) determines its usability on specific tasks. For tasks like coding, modeling, and financial analysis—where results are verifiable and workflows are orchestrateable—post-training is especially effective: task success can be automatically judged by compilers, geometry engines, or numerical verification programs, forming a high-quality training signal loop.

As a result, even a version bump of just 0.1 can bring significant capability leaps—the key is whether the task distribution in post-training data closely matches real-world workflows. The upgrade discussed here advances precisely in the direction of “staying close to real terminals and professional toolchains.”

2. Code Capabilities: Effectiveness and Cost in Terminal-Style Tasks

2.1 Why Terminal Tasks Are Harder Than LeetCode-Style Problems

Traditional code evaluations are mostly function-level completions with clear inputs, outputs, and closed context. Terminal-style tasks, by contrast, require the model to complete multi-step operations in a real command-line environment: reading error messages, locating files, modifying code, running tests, and revising based on feedback. These tasks test a combination of long-horizon planning, tool use, and self-correction—much closer to developers’ daily work.

Based on public evaluation trends, top models’ scores on such tasks roughly show a distribution of “first tier at 65–70, second tier at 55–65.” One noteworthy phenomenon: the open-source or open-weight route has entered the edge of the first tier for the first time, with scores above 65 and the gap to closed-source leaders narrowed to single digits. This means that when enterprises make technology choices, local deployment and data residency are no longer a passive “trade performance for compliance” decision.

2.2 The Cost Curve Often Matters More Than the Score Curve

In agentic coding, token consumption per task is far higher than in ordinary conversation: multiple rounds of tool calls, long context feedback, and retries all amplify cost. Therefore, evaluating a code model requires introducing a “cost per task” dimension:

Evaluation Dimension	Focus	Engineering Implication
Task pass rate	First-attempt success rate on multi-step tasks	Directly determines manual rework
Cost per task	Average tokens and calls per task	Determines feasibility of scaling
Retry friendliness	Whether failures can self-correct from errors	Affects hidden overhead on long-tail tasks

According to public information, this version’s cost control on comparable terminal tasks is among the better levels of frontier models. It’s worth emphasizing that low cost does not equal low capability: some lightweight models have lower unit prices but insufficient pass rates on multi-step tasks, which instead raises total cost through repeated retries. For enterprises, a more reasonable approach is to build a two-dimensional evaluation matrix of “pass rate × cost per task” rather than looking only at the quoted price.

2.3 A Reusable Evaluation Scaffold

The following pseudocode shows how to collect both effectiveness and cost in internal evaluations. Readers can replace it with their own task sets:

def evaluate_agent(model, tasks, sandbox):
    results = []
    for task in tasks:
        ctx = sandbox.reset(task)
        tokens, calls, ok = 0, 0, False
        for step in range(MAX_STEPS):
            resp = model.complete(ctx)          # Returns action and usage
            tokens += resp.usage.total_tokens
            calls += 1
            obs = sandbox.exec(resp.action)     # Execute in isolated environment
            ctx = ctx.extend(obs)
            if obs.done:
                ok = obs.success
                break
        results.append({
            "task": task.id, "success": ok,
            "tokens": tokens, "tool_calls": calls,
        })
    return summarize(results)   # Output pass rate and per-task cost percentiles

The key points: sandbox isolation ensures reproducible evaluation, usage tracking makes cost visible, and a step limit prevents runaway tasks from breaking the evaluation.

3. 3D Modeling: From “Calling APIs” to “Writing Scripts”

3.1 Capability Positioning

In evaluations relying on professional 3D CAD tools, this version scores above 92, placing it at the leading edge of open-weight models, with a gap of 3–4 points to closed-source leaders. More noteworthy is the change in implementation path.

Previously, having a large model operate 3D software was commonly done by invoking wrapped tool functions through a dedicated protocol (such as an external tool-access layer like the Model Context Protocol): the model only had to “select a tool + fill in parameters.” This mode is quick to adopt but limited by the granularity of the toolset—capabilities the tools don’t provide, the model can’t perform.

The new path is directly generating modeling scripts: after reading scene requirements, the model writes scripts targeting the professional modeling software’s API to complete geometry construction, material assignment, layout adjustment, and detail refinement. This brings three engineering benefits:

1. Expressiveness not limited by the toolset: scripts can combine arbitrary API calls, covering complex operations beyond the toolset;
2. Versionable results: scripts are plain text—they can be committed to a repository, diffed, and reproduced;
3. Easy batching: parametric scripts are naturally suited to batch generation of variants, such as multiple sizes or layouts of the same structure.

3.2 Typical Skeleton for Script-Based Modeling

Take the procedural generation of an “indoor greenery scene” as an example (pseudocode for structure, not specific interfaces):

scene = Scene.new()
for i in range(N):
    pos = sample_position(region)          # Spatial sampling to avoid overlap
    plant = Asset.load(kind=pick_species())
    plant.scale = random_uniform(0.8, 1.4)
    plant.rotation.z = random_uniform(0, 360)
    scene.add(plant, at=pos)
apply_material(scene, preset="matte_green")
scene.export("interior_forest.glb")

This structure reflects the core advantages of script-based modeling: random sampling, parametric variants, and batch material assignment can all be expressed in a few lines of code. Similar approaches apply to mechanical parts, lamp housings, and other scenarios—only the solver needs to be swapped for the corresponding geometry kernel.

3.3 Online Preview and Downstream Integration

The last mile of modeling capability is “producing usable assets.” The accompanying online preview and editing entry lets users view models in the browser, fine-tune parameters, and export directly to printable formats or shareable assets like rendered videos and animated images. For team collaboration, this means the pipeline from requirement description to printable asset is compressed into a single session, reducing back-and-forth between modeling software and communication tools.

4. Financial Scenarios: Retrieval, Verification, and Multi-Step Numerical Reasoning

Financial document analysis is a classic high-rigor scenario: earnings reports, prospectuses, and audit reports run into hundreds of pages, and questions often require cross-document verification and multi-step numerical calculation. Related evaluations typically cover three capability layers:

• Retrieval layer: locating relevant tables and footnotes in long documents;
• Verification layer: comparing differences in scope across documents (e.g., consolidated statements vs. parent-company statements);
• Reasoning layer: performing ratio calculations, trend judgments, and consistency checks on extracted data.

According to public information, this version scores above 64 on complex analysis evaluations over real financial documents, placing it at a leading position; on evaluations covering the full investment workflow of “target screening—profitability analysis,” it shows clear improvement over the previous generation, with a score close to 59. These two numbers reflect different aspects: the former leans toward “reading accurately,” the latter toward “workflow completing end-to-end.”

4.1 Reducing Hallucination Is More Critical Than Raising the Ceiling

In high-rigor scenarios, the cost of a wrong answer is far higher than that of a refusal. In internal stress tests, this version’s error rate dropped from 23.4% in the previous generation to 8.3%—a reduction of more than 15 percentage points. The impact of this change on deployment may be greater than score improvements: once the error rate drops to single-digit territory, the sampling ratio for manual review can be lowered, truly unlocking efficiency.

Recommended supporting practices include:

1. Mandatory citations: require the model to attach document locations when giving numbers, for easier verification;
2. Structured intermediate outputs: first output extracted tables and formulas, then conclusions, for segmented validation;
3. Confidence-based routing: route low-confidence questions to humans rather than forcing an answer.

5. Practical Recommendations for Developers and Enterprises

1. Build task-specific eval sets: use your own business data to construct 50–200 automatically judgeable tasks, covering both success paths and common failure paths, rather than relying only on public leaderboards.
2. Report cost percentiles: record P50/P90 of tokens and tool calls per task—long-tail cost is often the real budget killer.
3. Script-first: for modeling, data processing, and similar scenarios, prefer “generate script + sandbox execution” to gain reproducibility and auditability.
4. Front-load hallucination governance: build citation verification and confidence routing into the pipeline rather than relying on manual fallback after the fact.

Conclusion

The highlight of this upgrade is not a single score refresh but the convergence of three trends: post-training continues to lift professional task capability, the script-based path opens expressive space beyond the toolset, and cost and hallucination control make scaled deployment more feasible. For developers, what’s truly worth investing in is the evaluation system and engineering scaffolding—models will keep iterating, but a reliable evaluation and integration methodology can be reused over the long term.