From Code to 3D Creation: How Post-Training Is Driving the Next Leap in LLM Capabilities

1. Industry Background: The Main Battleground Shifts to Post-Training

Over the past two years, progress in large models has depended mainly on pre-training: more data, more compute, larger parameter counts. But with high-quality public corpora approaching exhaustion and pre-training returns diminishing, leading teams have broadly shifted focus to post-training—taking the same base model and using supervised fine-tuning (SFT), reinforcement learning from human feedback (RLHF), and reinforcement learning with verifiable rewards (RLVR) to turn “general knowledge” into “usable capability.”

This explains a recent industry pattern: many model releases do not swap out the base model at all, but iterate on post-training over the previous version, producing sharp short-term gains in hard skills such as coding, reasoning, and tool use. For enterprises, understanding this technical path is more valuable than memorizing any single benchmark score—it determines how we should evaluate and predict a model’s iteration cadence.

2. How Post-Training Turns “Can Answer” into “Can Do”

1. High-quality trajectory data. Getting a model to run commands continuously in a terminal, read logs, and modify configurations cannot be achieved with Q&A corpora alone. Post-training requires large volumes of “expert operation trajectories”: complete records of task goals, each command issued, the observed output, and the error-correction process. What the model learns is not an “answer” but a “process policy.”

2. Reinforcement learning with verifiable rewards. Code is a natural RL environment: whether a piece of code is correct can be verified simply by running the tests. Using “test pass rate” or “task completion status” as reward signals bypasses the noise introduced by human preference labeling, letting the model repeatedly self-correct against real execution feedback. This is the fundamental reason coding capability has advanced fastest over the past year.

3. Multi-turn self-correction. Real engineering is not a single generation; it is a loop of “write—run—read the error—revise.” Post-training internalizes this loop as a model habit, so that after a failure the model tends to verify proactively rather than force an output.

3. Evaluating Coding Capability: Why Terminal Tasks Are the Touchstone

Traditional code evaluation is mostly “function-level”: given a function signature, check whether unit tests pass. This struggles to reflect real engineering performance. Terminal-style task evaluation instead requires the model to complete multi-step, stateful operations in an isolated container—install dependencies, change configurations, run builds, inspect logs—with success determined by the actual final state of the environment. Such evaluation is closer to real development and is therefore regarded as the touchstone for agentic coding capability.

A simplified evaluation framework looks roughly like this:

# Simplified framework for automated terminal-task evaluation
for task in load_tasks("terminal_suite"):
    env = boot_sandbox(task.setup)      # Start isolated container, inject initial environment
    trace = agent.run(env, task.goal)   # Model executes commands over multiple turns, full trace recorded
    passed = task.verify(env)           # Judged by final environment state, not text matching
    report.add(task.id, passed,
               steps=trace.steps,       # Step efficiency: fewer steps means stronger planning
               cost=trace.tokens * unit_price)

Three things matter when reading such leaderboards: first, the judging method—environment-state verification is worth more than text matching; second, step count and latency—at equal pass rates, fewer steps indicate stronger planning; third, the cost column—pass rate and cost per task must be weighed together, otherwise value for money is easily overstated.

4. Cost: The Second Front in Frontier Model Competition

Many teams fixate on the price per million tokens, which is a mistake. For agentic tasks, the real cost formula is:

cost per task ≈ Σ(input tokens × unit price + output tokens × unit price) + tool-call and environment overhead

If a model plans well and gets things right in one pass, its output is shorter and retries fewer—so even at a higher unit price, total cost can be lower. Conversely, a cheap model that loves to take detours can drag a task into a dozen round trips. On the engineering side there are four common cost-reduction levers: prompt caching (reusing long system prompts and code context), batch inference (routing offline tasks to lower-priced channels), small-model routing (handing simple sub-tasks to lightweight models), and distillation (using a strong model to generate data for training a smaller one). When selecting a model, estimate “the total expense of completing a batch of real tasks” rather than comparing price sheets.

5. 3D Creation and Spatial Reasoning: The Underestimated Hard Problem

Beyond code, 3D creation is another touchstone for a model’s spatial understanding. The difficulty is that 3D objects are simultaneously constrained by geometry, topology, units, and coordinate systems—a single wrong dimension annotation can cause an assembly to fail. Evaluations for CAD and 3D modeling therefore typically give the model an executable tool environment and score on “whether a usable model file can be produced,” which is far stricter than pure text Q&A.

The currently more effective workflow is “script-driven modeling”: the model does not output meshes directly but generates a parametric script executable by the modeling software, which handles precise geometric computation, then iterates based on errors or rendering results:

prompt = """Generate a script: create an L-shaped bracket with filleted corners,
hole spacing 50mm, tolerance ±0.1mm, export to a common interchange format."""
script = llm.generate(prompt)                # Model produces a parametric modeling script
result = cad_runtime.execute(script)         # Executed by the interpreter built into the modeling software
if result.errors:
    script = llm.revise(script, result.errors)  # Automatically revise based on errors

The point of this division of labor: geometric precision goes to a professional engine, while the model focuses on “understanding requirements—decomposing structure—writing scripts.” Models that perform better on tool-dependent evaluations are also more feasible to deploy in industrial design, architectural drafting, and game asset generation.

6. The Evolution of Tool-Calling Paradigms: From Protocol Adaptation to Writing Scripts Directly

In the early days, getting a model to operate professional software usually required integrating a standardized tool-calling protocol that wrapped each operation as an interface. This approach is stable and controllable but costly to maintain: whenever the software is upgraded, the interface layer must change with it. As model coding capability has improved, a lighter paradigm has emerged—the model reads the software’s scripting documentation directly and generates executable scripts. Its advantages are extreme flexibility and no need for an extra adaptation layer; the cost is a higher demand on the model’s code and documentation comprehension, plus mandatory sandboxed execution, permission isolation, and human review to avoid security risks introduced by scripts. The two paradigms are not substitutes; enterprises can mix them by risk level: whitelisted interfaces for high-risk operations, script generation for low-risk exploration.

7. Selection Advice for Enterprises and Developers

1. Build your own evaluation set. Public leaderboards are only a first screen; the credible basis should be fifty to two hundred tasks drawn from your own business, covering typical difficulty levels and boundary scenarios.
2. Account by “total cost / number of successful tasks.” Fold retry failures and manual rework into the cost so you are not misled by a low unit price.
3. Route in tiers. Strong models tackle planning and complex generation; lightweight models handle formatting and simple rewrites—this can significantly reduce overall spend.
4. Watch the iteration cadence. Post-training-led iteration means the same base generation keeps getting stronger, so confirm upgrade and billing policies before signing. Whether you build your own inference environment or use managed model services from platforms such as Baidu AI Cloud, it is advisable to incorporate evaluation scripts and cost monitoring into your MLOps process, so every model upgrade rests on quantifiable evidence.

Conclusion

From terminal tasks to 3D modeling, the bar for evaluating model capability is shifting from “how well does it chat” to “does it actually get things done.” Post-training lets models sediment knowledge into executable process policies, while hard metrics such as cost efficiency and spatial reasoning are becoming the divide between frontier models and mediocre ones. For developers, rather than chasing leaderboard rankings, it is better to build your own evaluation and cost-measurement system early—that is the most reusable asset in any technology wave.