Post-Training in Large Models: Frontend Vision, Coding Capability, and the Cost Ledger

1. From “Stacking Parameters” to “Stacking Post-Training”: A Shift in Narrative

For the past two years, the dominant theme in large models has been an arms race over base model scale: parameters climbing from hundreds of billions toward trillions, static benchmark scores refreshed round after round. But the returns from scale eventually diminish—once a base is large enough, what determines whether a model can actually get work done is often no longer parameter count, but post-training intensity and the maturity of the engineering pipeline.

One telling industry example: after releasing a trillion-parameter open-source base, a team did not rush to build the next larger model. Instead, it spent an entire quarter on two things—continuously refining external toolchains such as sandboxes, terminals, and browsers, and internally running month-long continuous post-training on the base with reinforcement learning. The result: the same “skeleton” achieved an order-of-magnitude leap in real productivity tasks across versions.

The lesson for anyone choosing a model is straightforward: evaluating a model means looking not just at parameter scale, but at its post-training recipe and toolchain ecosystem.

2. A Typical Evolution Path from Base to Productivity

Placed on a timeline, the rhythm of such upgrades looks roughly like this:

Stage	Key Action	Capability Significance
Base release	Open-source large-scale parameter base, publish weights and inference code	Validate architecture ceiling, enter top tier on static benchmarks
Toolchain completion	Desktop coding tools pack command line, browser, and visual annotation into a GUI, offering dual “plan/goal” execution modes	Lay groundwork for long-horizon Agent tasks
Expectation management	Official teaser of a minor version via an easter egg	Warm up community attention
Anonymous blind test	New version enters a blind-test arena under an anonymous codename, later identified by the community through output-style fingerprints	Capability validation free of brand bias
Post-trained version launch	Released with joint reinforcement learning results, with a promise to open full weights	Shift from “can score” to “can deliver”

The most instructive detail in this path: toolchain completion happened before the new model release. Sandboxes, terminals, and browsers are not just product features for users—they are the “training environment” during post-training. What the model practices repeatedly in reinforcement learning is exactly the toolset it will operate in production. When the training environment matches the production environment, capabilities transfer smoothly.

3. Post-Training: Reforging a Base with Reinforcement Learning

The essence of such upgrades can be summarized in one formula:

Production-grade model ≈ full-power base skeleton × multi-domain joint reinforcement learning × engineered toolchain

1. Joint rewards, not single-point optimization.
The post-training phase places reward signals from hundreds of domains—coding, mathematical reasoning, tool calling, long-context retrieval, visual understanding—into the same joint training round: code tasks use “do tests pass, does it compile cleanly” as verifiable rewards; tool tasks use “is the final environment state achieved” as feedback; aesthetic and expression tasks align via human preference data. The point of joint training is to avoid fixing one thing while breaking another—optimizing only code benchmarks sacrifices dialogue and reasoning, and only joint signals lift capabilities as a whole.

2. Bring real execution environments into the training loop.
Verifiable rewards require executability. Running unit tests in a sandbox, executing commands in a terminal, rendering pages in a browser and making assertions—these environments are both evaluation infrastructure and reinforcement learning feedback sources. The model gets a success/failure signal immediately after each output, with errors explicitly returned. This is precisely the key to improving real command-line task capability rather than function-level completion.

3. Patience measured in months.
Post-training is not a one-off fine-tune. Continuous iteration across dozens of days and hundreds of domains, with rolling adjustments to data mixes and reward weights, is what cashes in a base’s “potential” as “stable output.” A common industry observation: the same base, after intensive post-training, can move from “barely usable” to “engineering-grade” on realistic terminal task benchmarks.

4. Three Evaluation Tools: Don’t Let a Single Leaderboard Set the Pace

For model selection, cross-check at least three types of evidence:

1. Anonymous blind-test leaderboards. Anonymity removes brand priors and is good for reading the overall water level. But watch for two pitfalls: first, leaderboard questions can saturate and be targeted for optimization; second, a “composite index” has limited discrimination for specific scenarios—a top composite ranking does not mean a top ranking in your scenario.

2. Real terminal and engineering task benchmarks. This is where the gap between benchmark scores and productivity concentrates. No matter how high a model scores on function-level completion or single-file rewriting benchmarks, that does not mean it can complete the full loop in a real repository—“read docs, locate, modify, run tests, fix regressions.” Prefer dynamic benchmarks with execution environments and multi-turn interaction, and build private evaluation sets from your own desensitized real repositories.

3. Structured subjective evaluation. For dimensions that cannot be auto-scored, such as frontend aesthetics, replace gut feeling with a multi-rater, multi-dimension scorecard: layout hierarchy, spacing rhythm, color consistency, motion restraint, and accessibility each get a slot, averaged across raters. Subjective but structured is far more reliable than a vague “looks good.”

5. Frontend and 3D Vision: Translating “Aesthetics” into Verifiable Constraints

When a model’s visual output is unstable, it is usually not that the model “has no taste,” but that the prompt did not make aesthetic constraints explicit. In practice, a “design tokens + acceptance criteria” formulation is recommended:

Role: senior frontend engineer
Task: generate a single-file landing page (inline styles, no external resources)
Design tokens:
- Primary color #0F172A; accent #3B82F6; background #F8FAFC
- Border radius 8px; 12-column grid; spacing system in multiples of 4
- Three-level type hierarchy, body line height 1.6
Interaction:
- Card hover lifts 2px and deepens shadow, 150ms transition
- Button press has 80ms scale feedback
Acceptance criteria:
- No horizontal scroll at 375 / 768 / 1440 widths
- No more than 9 information elements above the fold
- All interactions completable via keyboard

Write colors, spacing, and motion durations as “tokens,” and break “looks good” into assertable conditions like “no horizontal scroll at three widths”—output stability improves markedly. After generation, pair with screenshot comparison and visual regression assertions to bring frontend generation into an automated pipeline.

3D scenes need an additional “performance budget” constraint: triangle count, draw call count, target frame rate (e.g., 30fps on mid-range mobile devices). Stunning visuals and stuttering failures are one line apart—if constraints are not written clearly, the model may well deliver a “gallery exhibit” with exploding polygon counts.

6. The Boundary of Coding Productivity: Agentification and Human Intervention Points

New-generation tools generally offer two execution modes, and understanding their boundaries matters more than chasing benchmark scores:

• Plan mode: output a plan, file list, and risk points first, wait for confirmation before acting. Suited to tasks with large blast radius and irreversible operations.
• Goal mode: given an objective, autonomously loop “execute—observe—correct.” Suited to small tasks with clear boundaries and verifiable results.

Failure modes in real engineering basically fall into three categories: context drift in long tasks (you forget the initial constraints while editing), environment differences (runs locally, not in the sandbox), and error accumulation (a small error not caught rolls into a big one). The corresponding engineering approach is to embed human review into the pipeline:

agent_pipeline:
  mode: goal
  checkpoints:
    - after: plan        # plan approval
      require: human_review
    - after: edit        # diff review
      require: diff_review
    - after: test        # test gate
      require: all_pass
  rollback: snapshot

Checkpoint approval, diff review, test gates, and rollback at any time—these four things determine whether a “stunning demo” becomes “production reliable.”

7. The Cost Ledger: Calculate Unit Task Cost, Not Unit Price

Faced with claims of “flagship-level capability at a fraction of the price,” the rigorous validation method is to compute unit task cost rather than looking only at unit price:

def unit_task_cost(in_tokens, out_tokens,
                   price_in, price_out,
                   retries, agents=1):
    """Estimate the comprehensive cost of a single task"""
    io = in_tokens / 1e6 * price_in + out_tokens / 1e6 * price_out
    return io * (1 + retries) * agents

Three easily overlooked variables:

• Retry count: failed reruns linearly amplify cost; a weaker model with a “cheap unit price” is not necessarily “cheap per task”;
• Context injection: in long-repository tasks, input tokens are often several times the output, giving input price higher weight;
• Hidden costs of self-deployment: open weights plus a self-built inference cluster commonly yields a unit cost significantly below flagship closed-source APIs, but inference compute, operator optimization, and operations labor must be counted. Small teams are often better off validating the business with a managed API first, then switching to self-deployment to amortize costs.

8. A Practical Model Selection Checklist

1. Scenario first: frontend generation, backend refactoring, and Agent operations weigh model capabilities very differently—don’t let a composite score decide everything;
2. Private evaluation set: build 50–100 tasks from desensitized repositories and real tickets, testing both static and dynamic scores;
3. Dual-track validation: anonymous blind tests for overall water level, private evaluation sets for scenario fit;
4. Structured aesthetics: multi-rater, multi-dimension scorecards, not personal preference;
5. Total cost accounting: unit task cost weighted by retry rate, not per-million-token price;
6. Reuse infrastructure: general engineering capabilities like sandbox execution, logging services, and monitoring/alerting can use standard services offered by cloud platforms (such as the relevant product categories on Baidu AI Cloud), leaving energy for evaluation and the business itself.

9. Conclusion

The real signal in this round of evolution is not a ranking on some leaderboard, but a clear industry path: once base scale is in place, the variables determining productivity have shifted to the post-training recipe, the toolchain ecosystem, and the cost structure. For developers, the rational posture is—tame the model’s aesthetics with verifiable constraints, bound the Agent with a gated pipeline, and measure the true price of “flagship experience” by unit task cost. Benchmark scores may lie; delivery does not.