Post-Training Practice for Domestic LLMs: Engineering Leaps in Visual Aesthetics and Coding Ability

From Parameter Count to Engineering Capability

Over the past year, the competitive focus for open-source LLMs has centered on parameter scale. Ultra-large base models have demonstrated impressive training-side engineering—operator optimization, parallel strategies, and compile/communication scheduling—all validated only on massive clusters. However, an increasingly clear fact is emerging: parameter count defines the capability ceiling, but post-training determines whether that capability is actually reachable.

A typical example comes from real-world command-line benchmarks. Early ultra-large base models performed strongly on general knowledge evaluations, but scored extremely low on tasks testing “real terminal fundamentals”—tasks requiring the model to understand file systems, execute commands, read outputs, and correct errors across multi-turn interactions. This essentially reflects long-horizon Agent capability, not single-turn Q&A ability. Simply stacking more parameters does almost nothing here.

This iteration chose a more pragmatic path: retain the full-capability base model skeleton, use long-duration, broad-domain reinforcement learning post-training to close capability gaps, and simultaneously reduce inference costs. This approach offers greater reference value to developers because it answers a general question: how do you “train up” a model to be truly productive without replacing the base model?

A 99-Day Timeline: Parallel External Toolchain and Internal RL

Reconstructing the upgrade into a timeline reveals two parallel workflows:

Phase	Engineering Action	Purpose
Month 0	Release of the ultra-large open-source base model	Establish capability ceiling and training engineering baseline
Months 1–2	Desktop intelligent coding toolchain iteration: built-in browser, visual annotation, plan/goal dual modes	Prepare sandbox, terminal, and browser execution environments for long-horizon Agents
End of Month 2	Subtle version number teasers	Community expectation management
Early Month 3	Anonymous participation in public competitive evaluations; community identifies the model via output fingerprinting	Blind validation under real-world distribution
Mid Month 3	Official launch of post-training results; commitment to open full weights within a limited period	Open-source commitment fulfilled

Two signals in this timeline deserve developer attention:

First, the toolchain comes first. Before model capability upgrades, the execution environments (sandbox, terminal, browser) were refined for two months. This is not coincidence—reinforcement learning requires a stable, reproducible execution environment to obtain verifiable reward signals on real tasks. Without reliable sandboxes and tool-calling protocols, RL training degenerates into fitting noise.

Second, blind testing precedes release. Anonymous participation in public competitive evaluations means capability validation occurs under real user distribution, not on self-built test sets. For developers, this is a critical reference dimension for judging a model’s actual level: self-built benchmarks are prone to overfitting, while relative rankings under anonymous blind testing are harder to fabricate.

Three Pillars of the Upgrade: What Gets Stacked Instead of Parameters

In one sentence: full-capability base skeleton + joint reinforcement learning across over a hundred domains + significant reduction in inference cost. These three correspond to capability, alignment, and usability—none can be omitted.

Pillar One: A Jump in Comprehensive Intelligence Index

Third-party evaluation institutions reported a comprehensive intelligence index improvement of approximately 11 points over the initial version, placing it in the global first tier. The difficulty of improvement in this score range is nonlinear—at the high end of the index, each incremental point typically requires simultaneous improvements across multiple sub-domains, not a single breakthrough.

An objective caveat: the comprehensive intelligence index is a weighted aggregate of multiple sub-tasks. It reflects overall level but cannot substitute for scenario-specific evaluation. When selecting models, developers should treat the comprehensive index as an “entry ticket” and domain-specific evaluations as the “decision basis.”

Pillar Two: Visual Aesthetics as a Differentiator

The most striking phenomenon in this upgrade is the leap in visual aesthetic tasks. “Visual aesthetics” here does not refer to image recognition accuracy, but rather the model’s subjective quality judgment when generating front-end interfaces, 3D scene descriptions, layout, and color scheme solutions.

Why does this matter? Front-end code generation is currently the highest-frequency programming Agent scenario, and its evaluation criteria are dual:

• Functionality: Does the code run; are components correctly mounted; does state flow as expected?
• Aesthetics: Is the layout reasonable; is hierarchy clear; do spacing and color follow design conventions?

Traditional evaluations cover almost exclusively the first dimension, allowing models to generate code that “runs but looks bad.” In real production workflows, aesthetically substandard output is rejected directly by designers, incurring high rework costs. Therefore, incorporating visual aesthetics into the RL reward system is a key step from “runnable” to “usable.”

From an engineering perspective, the core difficulty in training this type of capability is constructing reward signals: functional correctness can be automatically verified with unit tests and render snapshots, but aesthetic quality is difficult to describe with rules. Feasible methods include introducing multimodal scoring models as reward proxies, building pairwise comparison data, and performing structural similarity and layout consistency checks at the render-result level. This path offers transferable insights for any team seeking to improve front-end generation quality.

The illustrative pseudocode below demonstrates an automated “functional + render” dual-layer verification approach for constructing reward signals in RL training:

# Illustrative: dual-layer reward construction for front-end generation (pseudocode)
def build_reward(generated_code, design_spec):
    # Layer 1: Functional correctness—executable and renderable
    ok, render_tree = safe_render(generated_code)
    if not ok:
        return 0.0
    # Layer 2: Structural consistency—alignment with the design's layout tree
    struct_score = tree_similarity(render_tree, design_spec.layout_tree)
    # Layer 3: Visual quality proxy score—provided by a multimodal judge
    visual_score = multimodal_judge(render_tree.snapshot, design_spec.image)
    # Weighted combination; weights must be calibrated on a validation set
    return 0.5 * struct_score + 0.5 * visual_score

Pay attention to the final weight handling: reward weights must be calibrated on an independent validation set, not set by experience. Otherwise, RL will quickly exploit the weights—for example, optimizing only structural similarity while generating “skeleton pages” with no visual hierarchy.

Pillar Three: Structural Inference Cost Reduction

Alongside capability improvements, API pricing was further reduced by approximately one-third. The engineering significance of this is often underestimated: inference cost directly determines the feasible boundary of Agent architecture.

Long-horizon programming Agents are characterized by high frequency, multi-turn interaction, and long context—a single task may involve dozens of tool calls, each carrying accumulated context. Under this load, small differences in per-call cost amplify to orders of magnitude. A one-third cost reduction means budgets that previously only supported single-turn Q&A can now sustain multi-turn Agent loops; scenarios limited to offline batch processing can now attempt near-real-time interaction.

This is the technical basis for the claim of “obtaining flagship-level coding capability at lower cost”: it is not a simple price war, but a reduction in per-task cost. The multiplicative effect of capability improvement combined with price reduction is the true value.

Coding Benchmark Performance and Real Productivity Boundaries

What the Benchmark Surpasses, and What That Means

On coding benchmarks, this upgrade surpassed some closed-source flagship models. But developers should focus on the gap between benchmarks and production environments.

Current mainstream coding benchmarks fall into three categories:

1. Single-function completion: Given a signature and comments, complete the function body. Tests syntax and local logic; corresponds to IDE autocomplete scenarios.
2. Repository-level repair: Given a real repository and issue description, locate and fix the defect. Tests cross-file understanding and retrieval; corresponds to daily bug-fixing scenarios.
3. Terminal task: Complete multi-step operations via command line in a sandbox. Tests long-horizon planning and error recovery; corresponds to Agent scenarios.

The initial base model performed adequately on the first two categories but was severely deficient on the third—which is precisely where post-training focused its efforts. The improvement in terminal tasks fundamentally represents a shift from “knowing how to write code” to “knowing how to get things done.”

Three Boundaries That Must Be Acknowledged

Even with strong results, production deployment requires clear recognition of three boundaries:

Boundary One: Aesthetic evaluation is subjective. Visual quality reward proxies are ultimately proxies; they carry systematic bias against real designer judgment. Models may over-prefer certain layout styles and perform well under a specific design system, then lose accuracy under a different design language. In practice, position model output as a “high-quality draft” and retain a human review step.

Boundary Two: Error accumulation in long-horizon tasks. The longer the Agent loop, the higher the risk that small per-step errors get amplified. Terminal task benchmarks typically cover ten-step operations, while real engineering tasks may involve hundreds of steps. Mitigations include setting staged checkpoints, introducing rule-based verification at critical nodes, and forcing manual confirmation for irreversible operations.

Boundary Three: Benchmark scores do not directly translate to team fit. A model’s ranking on public benchmarks reflects its capability on the benchmark distribution. The language composition of a team’s own codebase, framework versions, coding conventions, and internal toolchains all significantly affect actual performance. It is recommended to build a small private evaluation set from the team’s own repositories during model selection. The scale need not be large, but it must cover real task types.

A Reusable Deployment Evaluation Checklist

Based on the above analysis, here is a checklist for engineering teams:

• Capability: Evaluate single-function completion, repository-level repair, and multi-step terminal tasks separately—do not rely only on aggregate scores.
• Cost: Measure as “total token consumption to complete one representative task,” not per-call price.
• Stability: Run the same task multiple times and compute the variance of success rates; in Agent scenarios, variance matters more than the mean.
• Controllability: Verify whether the tool-calling protocol can be constrained, the sandbox can be isolated, and output can be structurally parsed.
• Compliance: Confirm the scope of open weights, data flow, and deployment options meet internal requirements.

Conclusion: Post-Training Is a More Worthy Investment

The most important takeaway from this upgrade is not a specific score, but a methodology: as base model capabilities converge toward homogeneity, the organizational capability of post-training becomes the source of differentiation.

This methodology has three transferable points:

First, the execution environment precedes model capability. To teach a model to do things, you first need reliable sandboxes, terminals, and tool-calling protocols; otherwise, RL cannot obtain effective rewards.

Second, reward signal design is the core engineering work. Functional correctness can be automated; soft metrics such as aesthetics, maintainability, and safety require constructing proxy rewards—while guarding against exploitation of those proxies. Weight calibration, adversarial sample injection, and periodic manual spot-checking are all necessary steps.

Third, cost and capability must be optimized together. Improving capability without lowering cost still leaves Agent architectures infeasible; lowering cost without improving capability keeps output out of production. The product of the two is what truly determines usability.

For teams evaluating LLM-based coding capabilities, the recommendation is to shift focus from “leaderboard rankings” to “per-task cost and success rate on a private evaluation set.” The former is an industry signal; the latter is the decision basis. For teams seeking to build their own post-training pipelines, start with a minimal closed loop: a reproducible sandbox environment, a set of automatable reward functions, and a validation set covering the real task distribution. Only after this three-piece suite is running should you scale up.