From Base to Post-Training: The Technical Path Behind Large-Model Capability Leaps and What Real-World Tests Show

1. Introduction: When Parameter Scale Is No Longer the Only Story

For the past two years, competition among large models has largely followed a brute-force路线 of “more parameters, more data, more compute.” Yet once base models crossed the trillion-parameter threshold, diminishing marginal returns became increasingly evident: a larger base does not automatically translate into stronger real-world productivity. Especially in scenarios that require multi-step reasoning, tool invocation, and long-horizon task execution, there is a significant gap between base capability and “usable capability.”

A path validated by a growing number of teams is: on top of a strong base, apply large-scale reinforcement learning (RL) post-training to convert “knowledge volume” into “task completion rate.” This article takes a recent typical flagship model iteration as an observation sample (referred to neutrally below as “the model”), breaks down the technical logic of its 99-day RL retraining, analyzes its actual performance in visual aesthetics, front-end reproduction, and coding benchmarks, and provides developers with reusable evaluation and selection methods.

---

2. Timeline Review: What Happened in Three Months

To understand a model upgrade, one must first understand its position in the overall product cadence. Below is an abstract summary of key milestones for this model series over recent months:

Phase	Event Type	Technical Meaning
Month 0	First-generation ultra-large base release	Validated the engineering feasibility of an ultra-large parameter base; demonstrated capability in hardcore scenarios such as operator optimization and compiler principles
Month 2	Desktop intelligent coding tool release	Packaged command-line capabilities into a graphical interface with a built-in browser, visual annotation, and dual planning/goal modes, paving the way for long-horizon agents
End of Month 2	Official teaser	Previewed the .1 version via a numeric easter egg, a signal release at the product operations level
Mid Month 3	Anonymous model arena testing	Participated anonymously in blind testing and was identified by the community, a third-party capability check before release
End of Month 3	Official release	Post-training culmination version launched, with a promise to open full weights later

The key information this timeline reveals is: the team did not choose to keep stacking a larger next-generation base, but instead did two things simultaneously—

1. Peripheral engineering: Rapidly iterating intelligent coding tools and workflow products, continuously polishing sandbox, terminal, and browser toolchains to solve “how model capability is stably invoked”;
2. Internal post-training: Conducting 99 days of reinforcement learning on the existing base to solve “how model capability is effectively activated.”

The formula for this evolution in one sentence:

New version = existing ultra-large parameter base + joint reinforcement learning retraining across more than one hundred domains + roughly one-third API price reduction

What is noteworthy about this formula: the main source of capability improvement is not parameters but post-training; the main source of cost reduction is not shrinkage but inference efficiency and economies of scale. This stands in sharp contrast to the industry convention that “releasing a .1 version is just routine fine-tuning.”

---

3. Reinforcement Learning Post-Training: Why You Can Leap Without Stacking Parameters

3.1 What Post-Training Actually Does

A base model acquires a “compressed representation of world knowledge” through pre-training. It excels at continuation and association but is not good at “completing tasks according to goals.” The core objective of post-training is to align this representation to specific task distributions. Common methods include supervised fine-tuning (SFT), preference optimization (such as DPO-style methods), and reinforcement learning (RL).

The value of RL lies in: it can automatically construct reward signals for tasks with “verifiable outcomes.” For example:

• Coding tasks: whether unit tests pass, whether compilation succeeds, whether static checks report no warnings;
• Math and logic tasks: whether the final answer matches the standard solution;
• Tool-invocation tasks: whether commands execute successfully, whether files are correctly generated, whether browser operations reach the target state.

These tasks do not require manual labeling of every step—only an automatically determinable “success/failure” signal—so the model can learn policies through extensive trial and error.

3.2 What “Joint RL Across More Than One Hundred Domains” Means

RL in a single domain easily leads to lopsided capability: too much coding RL may degrade the model’s natural-language expression; too much visual-aesthetics RL may impair logical reasoning. The idea of joint RL is to sample and optimize across multiple task families simultaneously, balancing different capability dimensions through task mixing ratios, reward normalization, and policy regularization.

There are three main technical challenges:

1. Inconsistent reward scales: Code pass rates are 0/1 binary, visual scores are continuous, and text quality is preference-pair comparison. Direct mixing causes gradients to be dominated by one task type. Common solutions are reward normalization or graded rewards.
2. High sampling cost: RL requires extensive rollouts; a single long-horizon agent trajectory may consume tens of thousands of tokens, requiring efficient inference scheduling and cache reuse in engineering.
3. Capability forgetting: Over-optimizing a certain reward leads to regression in the base’s general capabilities, requiring a retained proportion of general data for regularization.

The 99-day cycle indicates this was an engineering campaign of multi-round iteration and continuous tuning measured in weeks, not a one-off training script run.

3.3 A Simplified RL Training Loop Illustration

The pseudocode below illustrates the typical structure of such post-training (process illustration only; it does not represent any specific implementation):

for iteration in range(num_rounds):
    # 1. Sample by ratio from the multi-domain task pool
    batch = sample_tasks(pool, ratios=domain_mix)
    # 2. Generate multiple trajectories with the current policy
    trajectories = policy.rollout(batch, n=group_size)
    # 3. Automatically score with verifiable environments
    rewards = [evaluator.score(t, task) for t, task in zip(trajectories, batch)]
    rewards = normalize_rewards(rewards, by_domain=True)
    # 4. Estimate group-relative advantage (simplified critic-free approach)
    advantages = group_relative_advantage(rewards)
    # 5. Policy update + KL regularization to prevent drifting too far from the base
    loss = policy_gradient_loss(trajectories, advantages) \
           + beta * kl_divergence(policy, ref_policy)
    optimizer.step(loss)
    # 6. Periodically run regression tests on held-out sets to monitor capability forgetting
    if iteration % eval_interval == 0:
        run_regression_suite()

The key to this loop is the quality of the evaluator: if the reward signal can be easily “gamed,” the model will learn speculative strategies rather than real capability. Mature teams therefore invest heavily in environment construction and anti-cheating measures.

---

4. Capability Testing: Two Observation Angles—Visual Aesthetics and Coding Benchmarks

4.1 Visual Aesthetics: Why “Looking Good” Is a Harder Capability

In tasks such as 3D scene generation and front-end interface reproduction, the evaluation criteria are not only “correct” but also “coordinated.” A correctly laid-out page may still be ugly: inconsistent spacing, clashing colors, chaotic hierarchy. Such problems are hard to enumerate with rules, yet they are the most direct source of user perception.

From public blind-test feedback, the model performs noticeably better than same-generation competitors in this dimension. The reasons can be inferred from the training side:

• Supporting visual annotation tools: The visual annotation capability built into the desktop tool enables structured collection of “human intent for local modifications to generated results,” forming high-quality preference data;
• Scale of preference data: Interface reproduction tasks are naturally suited to A/B preference comparison, allowing the RL phase to obtain large volumes of pairwise signals at low cost;
• Rendering closed loop: Generate code → actually render → compare screenshots, forming an automatable visual-consistency reward.

A minimal verification workflow for self-testing:

Input: a design mockup (or a 3D scene description)
Step 1: The model generates front-end code (HTML/CSS/components)
Step 2: A headless browser renders and screenshots
Step 3: Compare with the design mockup on structural similarity + color distribution + layout alignment
Step 4: Manual review of only the three largest discrepancies
Output: a quantifiable visual reproduction score

The value of this workflow: it partially transforms “aesthetics”—a subjective judgment—into repeatable objective metrics, facilitating regression comparison across versions.

4.2 Coding Benchmarks: From “Can Write” to “Can Run Through”

The first-generation base performed poorly on real command-line fundamentals benchmarks (the original text mentions only 13% on a certain terminal-type benchmark), exposing a typical problem: the model can write commands that look right but fail to execute in real environments. The cause is often not syntax but misjudgment of environment state—nonexistent paths, insufficient permissions, missing dependencies, incorrect output parsing.

The improvement from post-training comes mainly from three directions:

1. Environment-feedback-driven learning: Every failed command execution produces error output, and this output itself is the strongest error-correction signal;
2. Credit assignment in long-horizon tasks: Agent tasks are often sequences of dozens of steps, and final success or failure must be attributed to some intermediate step. Trajectory-level rewards combined with process rewards in RL can alleviate this problem;
3. Stability of tool schemas: The desktop toolchain standardizes common operations, reducing environment incompatibilities caused by the model “improvising.”

It should be objectively noted: a jump in benchmark scores does not equal production readiness. Developers should pay attention to the following boundaries when evaluating:

• Whether the benchmark task distribution is close to their own business (Web front-end vs. embedded vs. data pipelines differ greatly);
• Whether failure modes are acceptable (is it “error reporting” or “silently producing wrong results”—the latter is more harmful);
• Stability of long tasks (success rate over 50 consecutive steps, not single-step success rate).

---

5. Cost Structure: The Engineering Meaning Behind a One-Third Price Cut

An API price reduction of roughly one-third typically comes from a combination of the following:

Optimization Direction	Specific Measures	Impact on Developers
Inference efficiency	Operator fusion, KV cache optimization, batch scheduling	Lower cost per token, with more benefit in long-context scenarios
Model structure	Sparsification, attention optimization	Improved first-token latency and throughput
Service scale	Higher cluster utilization, mixed deployment scheduling	Greater price elasticity across peak and off-peak
Post-training instead of parameter stacking	Use RL to improve capability rather than expanding parameters	Lower inference cost at equivalent capability

The practical significance for enterprises: capability-to-cost ratio is the core selection metric. A model with slightly higher capability but three times the cost is often uneconomical in batch scenarios; conversely, a model with extremely low cost but requiring extensive manual rework has higher hidden costs. Teams are advised to build a simple evaluation matrix as follows:

Dimension          Weight    Measurement Method
Task pass rate     40%       Business test set, manual or automatic judgment
Cost per task      25%       (input + output tokens) × unit price
Manual rework rate 20%       Proportion of tasks requiring manual modification
Latency satisfaction 15%     P95 first-token and total duration

---

6. Productivity Boundaries: Flagship Capability and Real Constraints

Every model has capability boundaries. The rational approach is to clearly define “what should be handed to the model and what must remain manual.”

Scenarios suitable for handing to the model:

• Code generation with clear acceptance criteria (tests, type checking, lint);
• Initial reproduction from design mockup to interface (followed by manual fine-tuning);
• Repetitive script writing and data conversion;
• Exploratory tasks requiring multiple rounds of trial and error (low failure cost).

Scenarios requiring caution or retained manual involvement:

• Operations involving production environment changes (requiring approval and rollback plans);
• Correctness judgments without automated verification (such as logic-dense business rules);
• Security-sensitive code (authentication, encryption, payments);
• Long-horizon unattended tasks (requiring checkpoints and circuit breakers).

A practical implementation principle: first establish “verifiable narrow scenarios,” then gradually expand the scope of authorization. The strength of RL post-trained models lies in “becoming stronger through feedback,” so the clearer the feedback a scenario can provide, the more pronounced the benefit.

---

7. Summary and Selection Recommendations

Reviewing this iteration, three methodologies of general value to developers can be distilled:

1. The center of gravity of capability improvement is shifting from pre-training to post-training. The base determines the ceiling; RL determines “how much of the ceiling can be cashed in.” When evaluating a model, focus on its performance on verifiable tasks rather than parameter scale alone.
2. Toolchains and model capability have a multiplicative relationship. Sandboxes, terminals, browsers, and visual annotation—these “peripheral” capabilities—determine whether model capability can be stably invoked. Toolchain maturity should be included in selection considerations.
3. Cost and capability must be calculated together. A one-third price cut combined with a capability leap changes the cost-effectiveness curve, not merely “being cheaper.” Enterprises should build their own evaluation matrix and use business test sets rather than public leaderboards for decisions.

For teams currently making technology selections, proceed in the following order: first run small-scale blind tests with 20–50 real business samples, then analyze failure modes on failed samples, and finally decide whether to “use directly,” “use with manual review,” or “not introduce for now.” This process is more reliable than any leaderboard ranking.