Beyond Pretraining: The Post-Training Race and Long-Horizon Agent Deployment

Introduction: What Is This Model Upgrade Cycle Really Competing On?

Recent flagship model iterations point to a clear signal: as the marginal returns of scaling parameters during pretraining diminish, the main battleground is shifting toward post-training and agent engineering. Parameter counts reaching the trillion level and context windows entering the million-token range are moving from “highlights” to “standard specs.” What truly separates the leaders is how post-training compute is invested, the engineering and cost design of long contexts, and whether a model can work continuously and reliably in real environments.

At the same time, the parallel release of same-family high-speed variants, the arrival of hosted agent infrastructure, and the subsequent opening of model weights together trace an evolution path from “model as product” to “model plus runtime as infrastructure.” This article analyzes these technical themes and offers practical guidance for developers.

1. The Post-Training Race: RL Moves from Alignment Tool to Capability Engine

1.1 From Preference Alignment to Domain-Specialized Reinforcement Learning

In earlier post-training, reinforcement learning primarily served to align models with human preferences. Today the mainstream approach extends RL across a large number of verifiable downstream domains: code generation rewarded by unit test passes and successful compilation, mathematics rewarded by answer verification, and agent tasks rewarded by end-to-end completion rates. Public information indicates that leading teams have extended RL to hundreds of downstream domains, covering code, 3D tool invocation, financial research, long-horizon task execution, and more.

The key to this “verifiable reward” approach is that reward signals must be objective, automatically judgeable, and difficult to game. This also explains why code and agents are the focus of this upgrade cycle—they naturally provide executable, verifiable environments.

1.2 Environments Are the New Datasets

To support large-scale joint training across hundreds of domains, the bottleneck is often not compute itself but the “environment.” Public technical breakdowns generally point to a set of systemic engineering changes:

• RL training frameworks: rollout throughput, sample reuse rates, and coordinated scheduling between training and inference engines;
• Long-context inference: engineering optimization of KV memory footprint and parallelism strategies at the million-token scale;
• Sandbox infrastructure: secure, isolated runtime environments for code execution and tool invocation;
• Scheduling systems: elastic GPU scheduling when training, sampling, and evaluation are co-located;
• Environment quality inspection platforms: task difficulty distribution, reward function correctness, and anti-cheating validation.

This yields a judgment worth stating plainly: once RL scales up, environment quality determines the ceiling of model capability. The dataset era competed on data cleaning; the environment era competes on task construction and quality inspection—an engineering moat that is easy to underestimate.

2. The Economics of Long Context: Cache Hits Determine the Bill

2.1 The Value and Cost of a Million-Token Context

Million-token contexts make “whole-repository code understanding,” “long-document research,” and “very long sessions” possible, but the direct cost is input expense and first-token latency. The industry-standard solution is prefix caching: KV cache for identical prefixes is reused, and the input price for the hit portion is typically an order of magnitude lower than for misses. This is why mainstream API pricing generally follows the structure “cached input < uncached input < output,” with output usually the most expensive.

2.2 Why Long-Horizon Tasks Burn Through Quota So Fast

Once the pricing structure is clear, the three sources of high agent consumption become explainable:

1. Multi-turn tool calls cause input tokens to accumulate roughly linearly with each turn;
2. Verbose output directly amplifies the most expensive component;
3. Context expansion makes the uncached portion grow ever larger.

2.3 An Illustrative Calculation

(The unit prices below are illustrative only, intended to show order-of-magnitude relationships: cached input at 1 yuan per million tokens, uncached input at 10 yuan per million tokens, output at 65 yuan per million tokens.)

Consider an agent task looping 100 turns, each carrying 50,000 tokens of context, of which 45,000 hit the cache, with 1,000 output tokens per turn:

• Cached input: 100 × 45,000 ÷ 1,000,000 × 1 yuan ≈ 4.5 yuan
• Uncached input: 100 × 5,000 ÷ 1,000,000 × 10 yuan = 5 yuan
• Output: 100 × 1,000 ÷ 1,000,000 × 65 yuan = 6.5 yuan
• Total: approximately 16 yuan.

With no cache hits at all, the input portion alone becomes 100 × 50,000 ÷ 1,000,000 × 10 yuan = 50 yuan, for a total of about 56.5 yuan. Cache hit rate alone can produce a 3–4x difference in the bill; combined with output length control, the cost gap widens further.

2.4 Engineering Practice Highlights

# Pseudocode: agent main loop for long-horizon tasks (independent of any vendor SDK)
SYSTEM = build_system_prompt()            # Stable prefix: role, rules, tool descriptions
prefix = [SYSTEM, knowledge_digest]       # Low-frequency content goes in the prefix to improve hit rate
state = load_checkpoint(task_id)          # Resume from checkpoint: essential for long-horizon tasks
for step in range(state.step, MAX_STEPS):
    obs = poll_environment(state)
    state.messages.append(obs)
    resp = llm.chat(
        messages=prefix + compact(state.messages),  # Compress history to curb context bloat
        tools=TOOL_SCHEMA,
        temperature=0.2,
        use_prefix_cache=True,          # Hit the prefix cache; input cost drops by an order of magnitude
    )
    result = execute_in_sandbox(parse_action(resp))  # Execute tools/code inside the sandbox
    state.messages.append(result)
    if step % N == 0:
        save_checkpoint(task_id, state) # Persist state (e.g., to object storage) to support recovery

Three takeaways: put stable content in the prefix, summarize and compress history, and impose hard limits on output length (for example, require a conclusion first, then supporting argument).

3. Same-Family High-Speed Variants: A General Path to Inference Acceleration

To multiply output speed without sacrificing intelligence, common industry techniques include:

• Speculative decoding: a small model drafts and a large model verifies, validating multiple tokens per pass;
• Quantization and operator optimization: reducing memory footprint and memory access overhead;
• Paged KV cache management: improving memory utilization and concurrent throughput;
• Continuous batching and scheduling optimization: reducing queueing latency.

High-speed variants typically trade a price premium (for example, roughly 2x) for 2–3x output speed—essentially pricing latency-sensitive and cost-sensitive traffic separately. The takeaway for developers: prioritize high-speed variants for interactive scenarios (pair programming, real-time chat) and use standard variants for offline batch processing (evaluation, data extraction); combining the two can significantly optimize cost per unit of output.

4. Reading Coding and Agent Benchmarks: From Scores to Productivity

4.1 Two Benchmark Types Worth Watching

• Terminal-environment benchmarks: programming agents complete complex tasks in realistic, resource-constrained terminal environments, with dedicated tests per task—assessing whether the agent “gets the job done” rather than “answers a question correctly.”
• Long-horizon code benchmarks: covering multiple engineering domains and evaluating multi-step execution, tool invocation, and end-to-end problem solving, closer to real development workflows.

4.2 Four Principles for Interpreting Scores

1. Mind the statistical significance of gaps: differences within 1 percentage point on a leaderboard often fall within evaluation variance and prompt sensitivity; do not over-interpret them.
2. Task distribution fit: if benchmark tasks do not match your stack (language, framework, codebase size), scores have limited reference value.
3. Beware of uneven profiles: strong coding does not imply equally strong long-form writing or instruction following; evaluate separately by capability dimension before selecting a model.
4. Count verbosity as cost: longer output tokens mean higher bills and lower review efficiency; the quality-cost curve is closer to the truth for decisions than a single score.

4.3 Build Your Own Evaluation

# Pseudocode: minimal framework for a business-specific evaluation set
for case in eval_set:
    traj = run_agent(case)               # Record the full trajectory: steps, tokens, latency
    score = grade(case, traj)            # Unit tests / rule checks / human spot checks
    record(case.id, score, traj.tokens, traj.latency)
report(cost_quality_curve(records))      # Output a quality-cost curve rather than a single score

5. Long-Horizon Agents and Hosted Infrastructure: Turning the Runtime into a Service

5.1 Why a Harness Is Needed

Keeping an agent working for hours or even 24/7 is difficult not because of single-shot inference but because of runtime governance:

• State management: persistence and recovery of task progress and intermediate artifacts;
• Failure recovery: retries and rollbacks after tool timeouts or environment anomalies;
• Context governance: memory compression and external memory retrieval for long tasks;
• Observability and auditing: full trajectory records for replay and attribution;
• Multi-agent collaboration: task decomposition, result aggregation, and conflict resolution.

The so-called harness (agent runtime framework) standardizes these capabilities. When leading teams open it as a hosted service, it means agent infrastructure is becoming “cloudified”: developers no longer need to build their own sandboxes, scheduling, and checkpoint systems, but consume them on demand.

5.2 Assembling General Cloud Capabilities

Even without hosted services, general cloud capabilities are enough to assemble an agent runtime: container platforms host sandboxes and tool services, message queues decouple task distribution, object storage holds checkpoints and artifacts, and logging plus monitoring and alerting provide observability. On cloud platforms such as Baidu AI Cloud, these capabilities fall under general product categories and can be combined as needed; the key is to decouple “model invocation” from “runtime governance” architecturally, avoiding tight coupling to a single model or vendor.

6. Practical Guidance for Developers

1. Evaluate first: build a business-matched evaluation set before looking at public leaderboards; decide using pass@k and the quality-cost curve.
2. Model costs: estimate bills from three variables—input volume, output volume, and cache hit rate—and always design prefix and compression strategies for long-horizon tasks.
3. Design abstraction layers: isolate model interfaces in the application architecture and retain multi-model switching and canary release capabilities to avoid lock-in.
4. Watch the open-weight cadence: some teams will release full model weights after launch, at which point private deployment and fine-tuning options can be evaluated—especially worth waiting for in sensitive-data scenarios.
5. Secure by default: route all tool calls through sandboxes with least privilege, and retain artifacts and trajectories for auditing.

Conclusion

The throughline of this flagship model iteration cycle is clear: post-training compute is flowing at scale toward agents that can work continuously, long context is moving from capability demo to cost engineering, and runtime infrastructure is becoming productized. For developers, more important than chasing a single benchmark score is understanding the engineering logic behind these changes: environment quality sets the ceiling on model capability, cache hit rate sets the floor on the bill, and runtime governance determines whether an agent can truly deliver value.