Post-Training in Large Models: Measured Gains in Visual Aesthetics and Coding Capability

From Base-Model Breakthroughs to Post-Training: A Compressed Evolution Timeline

Over the past year, the main narrative of the large-model race has been quietly shifting. Early competition centered on parameter scale and base-model capability—whoever first got trillion-parameter training working, and whoever performed more reliably on hardcore scenarios like operator optimization and compiler principles, could claim the technical high ground. But the marginal returns from base scale are diminishing. What actually separates product experiences now is the long, low-profile post-training process that follows release.

Looking back at the iteration cadence of one flagship model over recent months, this logic becomes clear:

Stage	Key Action	Technical Significance
Stage 1	Released an ultra-large-scale open-source base model whose aggregate benchmark scores edged out leading closed-source models of the same period	Demonstrated the ability to train a world-class base model, showing strength in low-level operator and compiler optimization scenarios
Stage 2	Launched a desktop intelligent coding tool with a built-in browser, visual annotation, and dual-mode task planning	Packaged command-line capability into a graphical interface, completing the toolchain for long-horizon agent tasks
Stage 3	Teased a new version obliquely; an anonymous model performed strongly in blind arena testing	Validated real-world feel through community blind tests rather than self-reported scores alone
Stage 4	Officially released the post-trained version, committing to open full weights within a set period	A comprehensive post-training release went live, fulfilling the open-source commitment

The most noteworthy element of this timeline is not the version number jumps but the “silent period” in between. Rather than rushing to stack a larger next-generation base model, the team did two things in parallel: externally, it iterated rapidly on coding and workflow tools, continuously refining the sandbox–terminal–browser toolchain; internally, it ran 99 days of reinforcement-learning post-training on the existing base. The former addressed the engineering question of whether the model can get work done; the latter addressed the capability ceiling of how well it does that work.

In one sentence, the formula for this evolution: new version = full-strength base skeleton + joint reinforcement learning across more than a hundred domains + significantly reduced API pricing. No parameter stacking—just compute and training strategy. For developers, this path is actually more pragmatic, because capability gains do not come at the cost of exploding inference expenses.

Why Post-Training Can Deliver Cross-Generational Leaps

Many vendors’ “.1” releases are routine fine-tunes, with changes concentrated in data mixing ratios and a small number of SFT samples, yielding limited perceptible improvement. But the results from this post-trained version were described by many evaluators as cross-generational. To understand where that leap comes from, it helps to first clarify what post-training actually does.

Decoupling Base Capability from Alignment Capability

The base model determines knowledge capacity and the upper bound of reasoning potential, while post-training determines how much of that potential can be reliably invoked. A model with a strong base but insufficient post-training typically shows this symptom: solid performance on knowledge Q&A, but breakdowns the moment multi-step reasoning, tool calling, or format adherence is required. On a terminal benchmark testing real command-line fundamentals, the first-generation version passed only 13%—a textbook case of inadequate post-training. The model “knew” what to do but could not execute reliably across long operation chains.

How Joint Reinforcement Learning Works

The core of joint RL retraining across more than a hundred domains is unifying large numbers of verifiable tasks under a single reinforcement-learning framework: code generation verified by unit tests, math reasoning verified by answer matching, tool calling verified by environment feedback, and interface generation verified by rendered output and visual scoring. When the reward signals from these tasks are optimized jointly, the model no longer learns isolated task tricks but cross-domain general execution strategies—how to decompose goals, how to self-verify, and how to roll back and retry after failure.

The cost of this training approach is compute and engineering complexity; the benefit is capability density. At the same parameter scale, sufficient versus insufficient post-training can mean a full tier of difference in practically usable capability.

What Benchmark Results Actually Tell Us

In a third-party blind test of a composite intelligence index, the new version improved substantially over the first generation and entered the global top tier, with only a few leading closed-source models ahead of it. The value of blind testing is that it strips out the bias of vendor-reported data, producing a relative ranking through a unified question bank and anonymous matchups. For developers, the reference value of such indices lies not in the specific rank but in the trend it confirms: the capability gap between open-weight models and top closed-source models is narrowing.

Visual Aesthetics: A Long-Underestimated Capability Dimension

The most unexpected highlight of this evaluation was visual aesthetics. On two task types—3D scene generation and front-end interface design—the new version clearly outperformed leading closed-source models compared in the same period. This dimension has rarely been part of model evaluation frameworks, yet it has an outsized impact on real productivity.

Why Aesthetics Is a Hard Capability, Not a Soft Metric

Front-end interface generation, 3D scene construction, and chart color and layout are tasks whose correctness cannot be measured by unit tests. Between an interface that “works” and one that “looks right” lies an entire body of design knowledge: layout hierarchy, whitespace rhythm, color contrast, component consistency. To produce aesthetically sound results, a model must have seen large volumes of high-quality design samples during training and be able to transfer abstract design principles onto concrete code structures.

From an engineering perspective, aesthetic capability directly affects delivery efficiency. A front-end page with sound layout and standardized styling costs far less to maintain than a version that is “functionally correct but structurally messy.” This is why visual aesthetics is becoming a new dividing line between model tiers.

Observations on 3D and Front-End Tasks

In hands-on testing, when asked to generate 3D scene layouts and material configurations from natural-language descriptions, the new version performed consistently on spatial relationship plausibility and lighting direction consistency. On front-end tasks requiring responsive-layout page components, the generated results showed class-name organization, style reuse, and semantic structure closer to the handwritten habits of senior front-end engineers, rather than the “runs but hard to maintain” style common in earlier models.

A reproducible validation approach: give the model a component requirement description, ask for directly renderable page code, then score along three dimensions—functional completeness (are interactions usable), structural规范性 (are DOM hierarchy and style organization clear), and visual plausibility (are spacing, color, and alignment coordinated). The first two can be checked automatically; the third can be assisted by a vision model. This method suits teams doing horizontal comparisons during model selection.

<!-- Illustration: maintainable front-end output should have clear semantic structure and style reuse -->
<section class="card-grid" aria-label="Data overview">
  <article class="card card--highlight">
    <h3 class="card__title">Key metrics</h3>
    <p class="card__value">--</p>
  </article>
</section>

The significance of this structure: semantic tags, BEM-style class names, and separated state modifiers are all foundations of downstream maintainability. Whether a model can reliably produce this kind of structure reflects engineering maturity more than whether it can generate flashy animations.

The Real Boundaries of Coding Capability

The Gap Between Benchmark Gains and Real Scenarios

Improvements in coding benchmark scores are visible, but developers should focus more on how benchmarks map to real work. Synthetic benchmarks typically test single-file, short-chain code generation; real engineering involves multi-file, long-chain tasks with external dependencies. The gains from post-training show up mainly in the stability of long-chain tasks: multi-step tool calls rarely break down, errors trigger self-rollback, and format adherence is stricter.

Progress in Terminal and Agent Scenarios

The first-generation version’s 13% pass rate on the terminal benchmark exposed a weakness: it could write code but could not use the command line to get work done. The post-trained version’s improvement in this dimension matters greatly for agent-type applications. A practical implementation pattern:

1. Planning phase: have the model output a step-by-step plan first, validated by a human or rules before execution;
2. Execution phase: run commands in a sandbox environment, capturing exit codes and stderr;
3. Self-verification phase: feed execution results back to the model, asking it to judge whether the goal was met, and retry if not;
4. Convergence control: set maximum retry rounds and timeouts to prevent long-horizon tasks from looping indefinitely.

# Illustration: agent execution loop with self-verification and a retry cap
MAX_RETRY = 5
for attempt in range(MAX_RETRY):
    plan = model.plan(task, history)
    result = sandbox.run(plan.commands)
    if result.exit_code == 0 and model.verify(task, result):
        break
    history.append(result.stderr)
else:
    raise TimeoutError("Task did not converge within the retry cap")

The key here is that the verification step is handled by the model itself—precisely the capability strengthened by post-training. The model has a more accurate sense of whether a task is truly complete, rather than blindly declaring success.

Areas That Still Need Human Oversight

Objectively, the current version still requires human leadership for cross-file refactoring in very large codebases, deep adaptation to proprietary frameworks, and architectural decisions requiring domain-expert knowledge. The model is better suited to execution-type tasks with clear acceptance criteria than to exploratory tasks with vague goals. Teams should adopt a tiered usage strategy: hand high-certainty tasks to the model and retain human review for low-certainty tasks.

Cost Structure Changes and Selection Advice

The one-third cut in API pricing is the most direct impact of this release for developers. Combined with the capability gains, the cost reduction per unit of capability is actually larger. The knock-on effects deserve elaboration:

First, economics must be recalculated for high-frequency scenarios. Code completion, batch document generation, and multi-turn agent tasks—high-token-consumption scenarios previously used selectively due to cost—can now be opened up much more broadly.

Second, evaluation and regression testing become more feasible. Teams can afford large-scale automated regression on model output, turning “choose a model by gut feeling” into “choose a model with data.”

Third, room opens up for localization and private deployment. Full weight availability means teams with data-compliance requirements can deploy in their own environments; combined with quantization and inference optimization, unit costs can be compressed further.

Selection advice: do not rely solely on composite index rankings. Build a small evaluation set close to your own business—sample real historical tasks, define automatable acceptance criteria, and compare candidate models across accuracy, stability, and per-task cost. Composite indices reflect general capability; a business evaluation set reflects fit.

Conclusion: The Competitive Logic of the Post-Training Era

The signal from this hands-on test is clear: the center of gravity in large-model competition is shifting from “who can train a bigger base” to “who can make an existing base work more reliably on real tasks.” The 99 days of post-training investment, joint reinforcement learning across more than a hundred domains, continuous toolchain refinement, and reduced API costs all point to the same goal—converting laboratory capability ceilings into productivity that developers can reliably reuse.

The breakthrough in visual aesthetics reminds us that evaluation dimensions need to expand. The coding benchmark gains remind us that stability in long-chain tasks matters more than single-point scores. Falling costs remind us that technology selection is ultimately a joint optimization of capability and cost. For developers, the most valuable action is not chasing leaderboards but building your own evaluation system—and, amid rapidly iterating model supply, continuously finding the balance of capability and price that fits your business.