From RL Post-Training to Long-Horizon Agents: What's Behind the Capability Leap in New Flagship LLMs

1. Background: The Shared Profile of a New Generation of Flagship Models

Several leading teams have recently shipped updated flagship models. Despite the different names, their capability profiles converge on four keywords:

• Trillion-scale parameters: model size has reached a new level, giving knowledge and reasoning a thicker foundation;
• Million-token context: a single pass can now cover up to a million tokens—entire code repositories, long reports, or multi-turn agent trajectories can be processed in one read;
• Dual-version strategy: alongside the standard model, vendors ship a high-speed version that delivers roughly 2–3× the output speed at the same intelligence level;
• Weight release cadence: vendors typically commit to releasing the full model weights within weeks of launch, balancing commercial services with the open-source ecosystem.

For developers, the evaluation question is shifting from “can it do X?” to “is it stable, fast, and cost-effective?” This article uses this generation of flagship models as a sample, unpacking the key technical points along three main threads—large-scale reinforcement learning (RL) post-training, long-horizon agent capabilities, and code and 3D creation—and offering a practical evaluation methodology.

2. Large-Scale RL Post-Training: The Core Engine of the Capability Leap

2.1 Why Post-Training Became the Main Battleground

Pre-training determines what a model knows; post-training determines what it can actually get done. As marginal returns from additional pre-training compute flatten, a large increase in RL post-training compute has become the primary source of capability gains. Unlike supervised fine-tuning, RL post-training uses task success and result correctness directly as reward signals—a natural fit for automatically verifiable objectives such as code runnability or agent task completion rates.

2.2 The Stack That Supports Joint Training Across Hundreds of Downstream Domains

Turning RL compute into real returns is less about the algorithm and more about infrastructure. Jointly training across hundreds of downstream domains at once requires re-engineering every layer of the stack:

1. RL framework layer: sampling, reward computation, and policy updates must form a high-throughput closed loop, typically via asynchronous pipelines and partial trajectory reuse so that compute never sits idle;
2. Long-context inference layer: both training and inference need sequence parallelism and careful KV cache management—otherwise the rollout cost of million-token contexts becomes unbearable;
3. Training efficiency layer: a combination of mixed precision, multi-dimensional parallelism (data/tensor/pipeline/expert), and memory optimization;
4. Sandbox infrastructure layer: code execution environments demand strong isolation, second-level snapshots, and high concurrency—the environment foundation for agent-style RL;
5. Scheduling layer: heterogeneous compute pooling, task prioritization, and elastic scaling to keep long-running RL jobs stable;
6. Environment quality-check platform layer: unified correctness validation of reward functions and task environments, preventing “reward hacking” from polluting the training signal.

One-sentence summary: when RL compute is scaled up severalfold, what converts every unit of that compute into stable returns is infrastructure engineering, not isolated algorithmic tricks.

3. Evaluation Methodology: How to Read “Agent Capability” Scores

3.1 Terminal-Environment Benchmarks: Grading Delivery, Not Just Answers

The new generation of models is commonly evaluated as a coding agent in real terminal environments: every task runs in a resource-constrained environment and is verified item by item against strict, task-specific tests. What makes these benchmarks valuable:

• Realism: tasks aren’t isolated algorithm puzzles but diagnostics, fixes, configuration, and deployment work close to day-to-day engineering;
• Verifiability: pass/fail grading against tests naturally suppresses “armchair” answers;
• Contamination resistance: closed environments and rotating tasks reduce the impact of data contamination.

3.2 Long-Horizon Engineering Benchmarks: Multi-Step Execution and End-to-End Problem Solving

Beyond public benchmarks, leading teams typically maintain internal long-horizon engineering benchmarks spanning multiple engineering domains, with an emphasis on multi-step execution, tool use, and end-to-end problem solving. For everyday developers, the value of these scores is that they reflect a model’s ability to “keep working without drifting off course”—exactly the scarcest quality in real agent scenarios.

3.3 Building Your Own Evaluation Pipeline: Sample Code

Rather than relying only on public leaderboards, build your own evaluation set. Here is a minimal working skeleton:

# A minimal self-built evaluation pipeline for agent coding tasks
TASKS = load_tasks([
    "repo_bugfix",        # bug fixes in a real code repository
    "project_scaffold",   # building a small project from scratch
    "terminal_ops",       # ops tasks in a resource-constrained terminal
])
for model in [baseline, candidate]:
    for task in TASKS:
        env = Sandbox(limits=task.resource_limits)   # real, constrained execution environment
        traj = agent.run(model, env, max_steps=task.max_steps)
        score = grader.run(task.unit_checks, traj)    # item-by-item grading against specialized tests
        report.log(model.name, task.id, score)
print(report.summary(dimensions=["code", "agent", "long_horizon"]))

Whether you’re reading benchmarks or running your own evaluations, hold on to three principles: check whether the task distribution matches your own scenarios, whether the grading method is verifiable, and how the same model’s score decays as context length grows.

4. Code and 3D Creation: From Fixing a Bug to Building a World

4.1 Full-Scale Coding Tasks

The code capabilities of the new models span the full scale: from locating and fixing a single defect in a real repository to building a complete project from scratch—frontend, backend, build scripts, and tests included. Two changes worth noting:

• Maturity of visual style: generated front-end pages are noticeably more polished in composition, typography, animation, and detail, with less of the “template” feel;
• Compositional use of external tools: models know when a job belongs to a specialized tool—invoking image processing, format conversion, and similar external capabilities instead of hand-coding everything.

4.2 Games and 3D: Engine Collaboration Is the New Normal

In creative scenarios, models can work fluently with mainstream commercial and open-source game engines, and—combined with web search and 3D generation capabilities—produce complete, runnable experiences. A typical web-based 3D workflow:

1. Use web search to confirm the current APIs and best practices of the engine or rendering library, avoiding outdated usage written from memory;
2. Generate the scene structure and interaction logic, building an interactive scene on a web 3D rendering stack;
3. Generate or invoke 3D assets, then refine composition, lighting, and animation;
4. Run, self-test, and iterate inside a sandbox until every acceptance criterion passes.

This pipeline tests the compound capability of “long-horizon agent + tool use + domain knowledge,” and it serves as a litmus test for whether a model can actually get work done.

5. The Dual-Version Strategy: The Engineering Meaning of Same Intelligence, Higher Speed

Shipping a standard and a high-speed version in parallel has become the default flagship release strategy: the fast version delivers roughly 2–3× the output speed while keeping the same intelligence level. The general techniques behind it include:

• Speculative decoding: a small model drafts, the large model verifies—multiple tokens per forward pass;
• Quantization and compression: reducing memory-access overhead with controllable precision loss;
• KV cache and scheduling optimization: tighter cache management and continuous batching to raise throughput;
• Decoding parallelism: parallel output techniques such as multi-token prediction.

How to choose: prefer the high-speed version for interactive scenarios (online chat, pair programming, real-time agent loops) to cut waiting time; use the standard version for offline batch jobs (large-scale code review, data extraction) where unit cost matters most. Since both versions share the same intelligence level, switching between them carries almost zero mental cost.

6. After the Weights Are Released: Getting Private Deployment Right

As is now customary, full model weights are released within weeks of launch—a critical milestone for enterprises with data-compliance, network-isolation, or deep-customization requirements. A general checklist for private deployment:

• Compute and scheduling: host inference services on a container platform, with GPU resource pooling and elastic scaling;
• Model serving: tiered deployment of standard inference APIs and high-speed inference instances;
• Supporting capabilities: object storage for weights and assets; logging services and monitoring/alerting covering latency, throughput, and error rates;
• Continuous iteration: when fine-tuning the open weights on domain data, you still need sandboxes and an evaluation pipeline to close the “train–evaluate–release” loop.

Managed cloud platforms that offer container services, GPU scheduling, monitoring, and logging—Baidu AI Cloud among them—can also help teams stand up such private inference and evaluation environments quickly, keeping the focus on business adaptation rather than infrastructure buildout.

7. Conclusion: The Capability Leap Is a Systems-Engineering Effort

Back to the opening question: how should we think about the capability leap of this generation of flagship models? The answer fits in one equation:

Capability leap = large-scale RL post-training × full-stack infrastructure × a trustworthy evaluation system

Algorithms set the ceiling. Infrastructure determines whether that ceiling can be delivered reliably. The evaluation system determines whether we can measure it honestly. For developers, the better move is to stop chasing single leaderboard scores and instead build your own evaluation sets and canary comparison mechanisms early, validating the three core long-horizon agent qualities—multi-step execution, tool use, and end-to-end delivery—in real business workflows. That is the most certain investment worth making in the new technology cycle.