Post-Training in Practice: Leveling Up Code Agents and 3D Modeling

1. From “Peak at Launch” to Continuous Post-Training Evolution

Over the past two years, the competitive focus in the large model industry has been quietly shifting. The pre-training phase competes on data scale, compute, and base architecture, while the post-training phase determines how the same base model ultimately performs in real business scenarios. Post-training refers to techniques applied after pre-training—supervised fine-tuning (SFT), reinforcement learning from human feedback (RLHF), reinforcement learning from verifiable rewards (RLVR), and domain adaptation training—that give a model the “final push” it needs for specific task domains.

The recent collective progress of several industry models on code agent and 3D modeling tasks is a clear demonstration of post-training value being released: the same class of base model, after targeted optimization for terminal environment interaction, multi-step tool invocation, and spatial reasoning scenarios, shows step-function improvements in both leaderboard scores and real-world experience. For developers, understanding the technical logic behind this is more valuable than chasing any single product launch.

2. Code Agents: From Code Completion to Terminal Operation

2.1 Evolution of Task Form

Traditional code capability evaluation centers on function-level generation: given a comment or function signature, can the model produce an implementation that passes unit tests? This type of task tests local code generation ability and is far removed from real engineering scenarios.

Current frontier terminal-based code evaluation, by contrast, tests a complete agent loop: the model must, within an isolated real operating system environment, read task descriptions, plan steps, execute commands, edit files, run builds and tests, and iteratively fix issues based on error messages until the task passes acceptance criteria. It simultaneously tests four categories of capability:

• Environment understanding: perceiving the file system, dependency versions, and runtime state;
• Task decomposition: breaking vague requirements into executable command sequences;
• Tool use: appropriately invoking command-line, editor, version control, and other tools;
• Error recovery: self-correcting when facing compilation failures, test failures, or dependency conflicts.

2.2 A Typical Evaluation Loop

# Pseudocode: terminal agent evaluation main loop
env = TerminalEnv(image="linux-sandbox")   # isolated container environment
agent = CodeAgent(model="llm", tools=["shell", "editor"])
for task in task_suite:
    obs = env.reset(task)                  # inject task and initial environment state
    while not env.is_done():
        action = agent.decide(obs)         # model decides next action
        obs = env.execute(action)          # execute and return observation
    report = env.grade(task)               # score according to acceptance criteria

The key to this loop is “real feedback”: the environment honestly tells the model whether each step is right or wrong, so scores have far less noise than static evaluations and more closely resemble how human engineers actually work.

2.3 How to Interpret Scores Correctly

• Focus on variance, not single points: the same model’s scores fluctuate across runs; if the gap between two models is smaller than the variance range, strong conclusions are not warranted;
• Look at pass@k: single-attempt pass rate and multi-sample pass rate reflect different capabilities—the former tests stability, the latter tests capability ceiling;
• Trajectory quality matters equally: beyond scores, review behavioral trajectories—did the model install dependencies recklessly, perform destructive operations, or stop in time when making no progress?

3. The Cost Dimension: The Second Axis of Model Selection

3.1 Why Agent Tasks Burn Money

The cost structure of agent tasks is completely different from single-turn Q&A. A single terminal task may require dozens of interaction rounds, each carrying the full context, plus paying for failed retries. Total cost can be approximated as:

Cost ≈ unit price × tokens per round × interaction rounds × retry count

Therefore, a model with a slightly higher unit price that gets it right the first time may have a lower total cost than a cheaper model that frequently reworks.

3.2 The Cost-Performance Pareto Frontier

When selecting models, plot a “score vs. cost” scatter chart and look for models on the Pareto frontier: at equal scores, pick the cheaper one; at equal budget, pick the stronger one. Notably, some lightweight models marketed for low cost, despite very low unit prices, show pass-rate gaps on complex tasks that cause interaction rounds to explode, making their total cost uncompetitive. Conversely, flagship models’ high pass rates on hard problems amortize the cost per success.

3.3 Engineering-Side Cost Reduction Methods

• Tiered routing: route simple tasks to lightweight models, escalate hard problems to flagship models;
• Context trimming: keep only observations and history relevant to the current decision, compressing useless tokens;
• Result caching: reuse caches for deterministic subtasks (e.g., environment initialization, dependency installation);
• Early termination: set a progress metric per round; if there is no progress for consecutive rounds, cut off to avoid infinite loops burning money.

4. 3D Modeling Automation: A New Battleground for Spatial Reasoning

4.1 Why 3D Modeling Is a Hard Nut to Crack

Compared to text and 2D images, 3D modeling demands a leap in model capability: it requires understanding geometric relationships in 3D space (position, orientation, scale), topological structure (connections between points, edges, and faces), physical properties of materials and lighting, and the dependency order between multi-step operations. Translating something like “make a table leg with beveled metal texture” from natural language into a precise sequence of parametric operations tests exactly this spatial reasoning ability.

4.2 Comparing Two Technical Routes

There are currently two main routes for involving large models in 3D creation:

Route A: Standardized tool invocation. The model uses a general tool-calling protocol to invoke pre-built modeling tool interfaces, completing one atomic operation at a time. Advantages: strong controllability, easy error localization. Disadvantages: limited interface coverage; complex shapes require many rounds.

Route B: Direct script generation. The model writes scripts directly for professional modeling software (via its built-in scripting API), generating complete procedural modeling code in one pass, executed by the script engine. Advantages: strong expressiveness, batch reusability, easy version management. Disadvantages: higher demands on the model’s spatial understanding and code ability.

# Pseudocode: script-driven procedural modeling
import modeling_api as m
scene = m.new_scene()
frame = m.add_primitive("cube", size=(0.4, 0.4, 0.75))
m.bevel(frame, width=0.02)                            # edge bevel
m.set_material(frame, name="brushed_metal")
m.array_modifier(frame, count=4, offset=(0, 0.5, 0))  # array into four table legs
m.export(scene, "table_frame.asset")

4.3 Evaluation Perspective: Score Gaps Between Tool-Assisted and Bare Script Modes Are Informative

In 3D evaluations, “tool-assisted” and “pure script” modes are typically tested separately, and the gap itself is a diagnostic signal: a large gap indicates the model knows “how to use tools” but has insufficient spatial understanding; a small gap indicates the model has internalized strong spatial reasoning ability. For users, if the business centers on batch, programmatic asset production, the script route often offers higher overall efficiency; if it centers on interactive, high-frequency tweaking, the tool-invocation route is more stable.

Also worth noting is that the gap between the open-source camp and the closed-source frontier on such tasks is rapidly narrowing, and “the best score achievable by open-source models” is becoming an important window for observing ecosystem maturity.

5. Enterprise Adoption: A Reusable Evaluation and Selection Framework

Based on the above analysis, enterprises introducing model capabilities are advised to follow this process:

1. Build a private evaluation set: extract 50–200 representative tasks from real business scenarios, covering easy/medium/hard tiers, rather than only looking at public leaderboards;
2. Score on dual metrics: record both pass rate and total cost (including retries), plot the Pareto frontier before deciding;
3. Tiered routing and canary rollout: route tasks by difficulty to different model tiers; validate new models first in low-risk scenarios;
4. Establish a regression mechanism: automatically run the evaluation set after model version updates to prevent capability regressions from affecting production;
5. Leverage cloud infrastructure: use model services and fine-tuning capabilities provided by platforms such as Baidu AI Cloud, combined with general components like containers, object storage, logging services, and monitoring alerts, to build an integrated “evaluate–deploy–observe” pipeline, turning model capability iterations into reusable engineering assets.

6. Conclusion

Post-training is widening the “last mile” gap between models: advances in code agents are moving models from “writing code” to “getting work done,” while enhanced 3D modeling capability pushes spatial reasoning from the lab into production. For developers, rather than memorizing scores from a particular launch event, it is better to master a methodology of “evaluation set construction, cost-performance trade-offs, and scripted workflows”—it won’t depreciate as models change generations.