From Post-Training RL to Long-Horizon Agents: Understanding the Latest Leap in LLM Capabilities
This article analyzes the key shifts behind the latest generation of flagship large language models—from scaling parameters to scaling post-training compute. It covers how reinforcement learning has expanded from alignment tasks to hundreds of downstream domains, the infrastructure required to support large-scale RL (sandboxing, scheduling, environment quality checks), the significance of million-token context windows for agents, long-horizon evaluation methods, high-speed model variants, three-tier API pricing structures, practical cost control strategies for agent workloads, and the emergence of managed agent harnesses as cloud infrastructure. Developers will gain a structured understanding of both the capability gains and the cost governance challenges that define the agent era.
1. From Scaling Parameters to Scaling Post-Training: The Logic Behind This Upgrade Cycle
The latest generation of flagship models shares three characteristics: parameter counts reaching into the trillions, context windows expanding to one million tokens, and multiple inference tiers targeting different latency requirements. One recent model release with 3 trillion parameters, for example, concentrated its capability gains in four areas—coding, 3D creation, financial research, and long-horizon agents—while simultaneously launching a high-speed variant that maintains equivalent intelligence with roughly 2–3x faster output.
Parameter scale is impressive, but the real lever in this upgrade cycle is post-training. Compared with the previous generation, the most notable change is a further increase in post-training compute, with reinforcement learning (RL) expanded from a handful of alignment tasks to hundreds of downstream domains. The logic is straightforward: pre-training returns are diminishing, while RL can continuously extract performance gains on tasks with verifiable outcomes—whether code passes tests, whether tool calls succeed, whether financial analysis conclusions can be audited. When RL environments are numerous and realistic enough, the model learns transferable task-execution capabilities rather than mere “test-taking tricks.”
2. Behind Large-Scale RL: A Rebuilt Training Infrastructure
Scaling RL across hundreds of domains is often less a bottleneck of algorithms than of engineering. Supporting large-scale joint training typically requires systematic changes to the following infrastructure:
- RL frameworks: Separating training from inference, high-throughput rollout sampling, and asynchronous environment interaction to ensure efficient generation of massive trial-and-error data;
- Long-context inference: Million-token contexts place extreme demands on KV cache management, parallelism strategies, and memory scheduling—this is both a training problem and a serving problem;
- Sandbox infrastructure: Code execution, command-line operations, and tool calls must occur in isolated environments that are both secure and fast enough—otherwise RL sampling speed gets dragged down by the environment;
- Scheduling systems: GPU resources need to be dynamically allocated between “training” and “environment interaction” to maximize cluster utilization;
- Environment quality-check platforms: The credibility of reward signals directly determines the RL ceiling. Flawed environments cause models to learn exploitative strategies (reward hacking), which is why leading teams commonly build environment QA into a standalone platform.
These environments can be understood as the “datasets” of the RL era: data quality determines the ceiling of supervised learning, and environment quality determines the ceiling of reinforcement learning.
3. Long Context and Long-Horizon Agents: Capability Targets and Evaluation Methods
3.1 What a Million-Token Context Means for Agents
The value of a million-token context is not just “reading more.” For an agent, it means an entire mid-sized codebase, a complete IPO prospectus, or hours of task state can be fully loaded into context—reducing distortion from information compression and enabling cross-file, cross-chapter reasoning.
3.2 How to Evaluate Long-Horizon Capabilities: From Single-Step Q&A to Multi-Step Execution
Evaluation methods are following capability development. For coding agents, there are two representative evaluation categories:
- Terminal environment evaluation: Models complete complex tasks in realistic, resource-constrained terminal environments, with each task accompanied by specific tests to determine success or failure. Published results show that the new generation of models can score above 65% on this type of evaluation, clearly surpassing most closed-source models and narrowing the gap with the strongest to within 1 percentage point;
- Long-horizon code evaluation: Covering multiple engineering domains, this focuses on multi-step execution, tool use, and end-to-end problem solving. The new generation scores approximately 61%, an improvement of about 5 percentage points over the previous generation’s roughly 56%.
These evaluations differ fundamentally from single-turn Q&A benchmarks: long-horizon task failure modes are often not “can’t do it” but rather drifting off course midway, being unable to recover after a tool call error, or falling into unproductive loops. Evaluation must therefore include process checkpoints rather than only looking at final results.
4. High-Speed Variants: Same Intelligence, Two Latency Tiers
The high-speed variant delivers roughly 2–3x faster output while maintaining the same intelligence level. Common industry techniques for achieving comparable acceleration include speculative decoding, KV cache optimization, and more aggressive server-side batch scheduling. For developers, the selection logic can be simplified as:
- For latency-sensitive scenarios like interactive coding and high-frequency tool calls, prioritize the high-speed variant—speed gains translate directly into shorter task completion times;
- For offline tasks like deep research and batch analysis, the standard variant is often more cost-effective, trading waiting time for cost savings.
5. Three-Tier Pricing and “Quota Anxiety”: Getting the Agent Cost Equation Right
5.1 Pricing Structure
Current mainstream model APIs generally adopt three-tier pricing: cached input, uncached input, and output. Taking one publicly available pricing example, cached input is approximately one-tenth the price of uncached input, while output is the most expensive at roughly 5x the uncached input price. This structure sends a clear signal: maximizing cache hits and minimizing output are the two primary levers for cost optimization.
5.2 Why Agent Tasks Burn Through Quotas So Fast
Long-horizon agents are heavy token consumers for four reasons: context accumulates with each round, requiring repeated reads of large amounts of history; tool calls introduce high-frequency multi-turn interactions; failure retries amplify consumption; and multi-agent collaboration multiplies the factor further. A simple estimation function illustrates the problem:
def estimate_agent_cost(rounds, ctx_tokens, out_tokens,cache_hit_ratio=0.8,p_uncached_in=13.0, # per million tokens, example valuep_cached_in=1.3, # per million tokens, example valuep_out=68.0): # per million tokens, example valuetotal_in = rounds * ctx_tokenscached = total_in * cache_hit_ratiototal_out = rounds * out_tokensreturn (cached / 1e6 * p_cached_in+ (total_in - cached) / 1e6 * p_uncached_in+ total_out / 1e6 * p_out)# 50 rounds of tool calls, 80K context tokens per round, 2K output tokensprint(round(estimate_agent_cost(50, 80_000, 2_000), 2)) # ~21.36
A moderately complex agent task can cost tens of units of currency; if used against a subscription quota, exhausting it within minutes is not exaggerated—this is the technical explanation behind the “quota burned in 10 minutes” phenomenon.
5.3 Cost Control Best Practices Checklist
- Cache-friendly design: Keep system prompts, tool definitions, and other prefixes stable to improve cache hit rates;
- Context governance: Summarize and compress historical rounds, and promptly trim irrelevant tool return results;
- Task decomposition: Route subtasks to smaller models, reserving flagship models only for critical decision points;
- Budget circuit breakers: Set token limits and round limits per task; abort and persist state when exceeded;
- Constrain output: Suppress verbosity in prompts and post-processing—notably, verbosity remains a frequently discussed issue in current evaluations, as RL-trained models sometimes “compensate for quality with quantity.”
6. Managed Agents: Harness Moving from Framework to Cloud Infrastructure
Agent harness refers to the execution framework surrounding a model, responsible for tool calling, sandbox management, context maintenance, and exception retries. Vendors are now beginning to offer the harness that supports long-running agents directly as cloud infrastructure: supporting 24/7 long-horizon tasks and multi-agent collaboration, so enterprises and developers no longer need to build their own sandbox and scheduling systems.
This direction aligns with the evolution of cloud platforms—vendors represented by Baidu AI Cloud are similarly layering agent orchestration and managed runtime capabilities on top of model services. The common trend is clear: shifting the engineering-intensive work of “keeping models working reliably over time” from application developers down to the platform.
7. Four Recommendations for Developers
- Evaluation-driven selection: Leaderboard scores are only a reference—re-test with your own real task sets, focusing on multi-step task completion rates and stability;
- Treat cost as an architecture problem: Caching strategy, context management, and tiered model routing should be determined during system design, not patched after launch;
- Balance the speed-intelligence-price triangle: The same model often has multiple tiers—match to the scenario rather than defaulting to the most expensive;
- Watch the weight release cadence: Leading vendors have committed to releasing full model weights in the near future, which is a substantive benefit for private deployment, compliance-sensitive scenarios, and fine-tuning needs.
8. Conclusion
The main thread of this model upgrade cycle is clear: post-training compute is being heavily invested in real, usable agent environments, with coding, financial research, 3D tool use, and long-duration task execution as the primary battlegrounds. For developers, opportunity and cost arrive together—long-horizon agents are genuinely usable for the first time, but token bills also need to be taken seriously for the first time. Capability leaps and cost governance will be two parallel required courses in the agent era.
