I. Shifting Focus: From Pre-training Races to Post-Training Mastery

Recent flagship LLMs share clear common characteristics: parameter scales entering the trillion-level and context windows expanding to accommodate millions of tokens. However, the true differentiator in model capability is the intensity of investment in the post-training phase. As high-quality pre-training data approaches its extraction limits, the marginal returns of simply piling on pre-training compute are diminishing. Post-training—especially large-scale reinforcement learning (RL)—has become the primary source of capability leaps.

The latest flagship models exhibit two significant trends in post-training:

1. Scaling post-training compute, shifting from general alignment to domain-specific reinforcement. Early post-training primarily aimed to make models “follow instructions and align with safety guidelines.” The new approach expands RL to hundreds of downstream domains—such as coding, financial research, and 3D tool manipulation. Models repeatedly trial-and-error on real task distributions, driven by verifiable result signals (e.g., whether tests pass, calculations are correct, or tasks are completed) to foster capability growth.
2. Systematic restructuring of training infrastructure. Supporting joint RL training across hundreds of domains requires overhauling RL frameworks, long-context inference, training efficiency, sandboxing infrastructure, scheduling systems, and environment quality assurance platforms. In other words, the post-training bottleneck has shifted from “algorithms” to “environments and engineering.” The upper limit of a model is now determined by the ability to automatically generate high-quality tasks, strictly verify result correctness, and maintain stable training across multiple domains.

The takeaway for engineering teams is that when evaluating model capabilities, looking at the parameter sheet is insufficient. The industrialization degree of a model’s “environment factory” is a better predictor of its performance in real-world business scenarios than benchmark scores.

II. Long-Horizon Agents: From “Answering Questions” to “Continuous Working”

The most representative direction of this upgrade cycle is investing post-training compute into “environments for agents that can work continuously.” This is fundamentally different from traditional single-turn Q&A. Long-horizon tasks impose four new requirements on models:

• State Maintenance: Tasks span dozens or even hundreds of steps. The model must continuously maintain goals, progress, and intermediate conclusions.
• Tool Orchestration: Managing the sequence and dependencies of terminal commands, code execution, and external API calls.
• Error Recovery: The ability to self-correct after command failures or environment drift.
• Budget Management: Completing end-to-end tasks within limited step and token budgets.

The value of a million-token context is allowing the agent to “remember” longer operational trajectories and larger codebases. However, long context is not free—as length grows, so do the computational overheads of attention mechanisms and KV caches. Engineering solutions typically combine retrieval, context compression, and cache reuse to control costs.

The core of supporting long-running agents is the runtime framework, responsible for tool gateways, sandbox isolation, memory management, trajectory replay, and observability. A representative agent main loop looks like this:

# Main loop for a long-horizon agent (illustrative)
while not task.done and step < budget:
    obs = env.observe(task)
    prompt = build_prompt(STABLE_PREFIX, memory, obs)  # Stable prefix to maximize cache hits
    action = llm.generate(prompt, tools=toolset)
    result = sandbox.execute(action)                   # Execute in sandbox to isolate risks
    memory.append(result)                              # Record trajectory for replay and audit
    if result.failed:
        memory.append(recovery_hint(result))           # Inject error recovery hints
    step += 1

III. Evaluating Coding Capabilities: Beware of “Score Inflation” and Understand Evaluation Design

Evaluation is the most easily misunderstood part of a model release. Some public evaluations of real terminal tasks show that top models have reached pass rates in the 60% range, with the gap between them narrowing to single-digit percentages. This indicates both capability convergence and the limited value of “only looking at total scores.” The key is to examine whether the evaluation design is resistant to data contamination and whether it reflects real-world scenarios.

Two evaluation paradigms deserve attention:

1. Real Terminal Environment Evaluation: Agents are placed in resource-constrained containers to complete complex tasks. Each task features dedicated validators that check the final environment state rather than just the output text. This effectively exposes models that are “all talk and no action.”
2. Long-Horizon Code Evaluation: Covering multiple engineering domains, this focuses on multi-step execution, tool calling, and end-to-end problem-solving. Score changes across different versions of the same evaluation set better reflect true progress than a one-off horizontal comparison.

Simultaneously, beware of two common pitfalls: inflated scores caused by evaluation set leakage, and sacrificing output conciseness for higher pass rates, which generates verbose responses and indirectly inflates actual usage costs. Enterprises should build their own business-specific evaluation sets using real traffic replays for horizontal comparisons:

# Terminal task evaluation skeleton (illustrative)
for task in taskset:                    # Keep tasks independent to prevent mutual leakage
    env = TerminalEnv(task.setup, limits=task.resource)
    traj = agent.run(env, timeout=task.timeout)
    score = verifier.check(env.state, task.expected)  # Verify the final state, not the text
    report.record(task.id, score, tokens=traj.tokens, steps=traj.steps)

IV. Inference Acceleration: Same Intelligence, Different Latency

New-generation models generally offer a dual-track supply: a “high-speed version with equivalent capability.” While maintaining the same intelligence level, the output speed is increased by several times, with a corresponding premium on unit price. Common technical paths behind this include speculative decoding, KV cache reuse, continuous batching, low-bit quantization deployment, and more aggressive scheduling strategies on the server side.

For selection, a simple principle can be followed:

• Interactive coding, high-frequency short-output agent loops: Latency directly dictates user experience and task throughput, making it worthwhile to pay for speed.
• Offline batch processing, long document analysis: Latency-insensitive tasks are more economical with the standard version.

V. Token Economics: Why Agents “Burn Through Quotas” So Fast

Mainstream APIs generally adopt a three-tier pricing model: “cached input / uncached input / output.” The cached price is typically about an order of magnitude lower than the uncached price, and the output unit price is the highest. Agent scenarios happen to trigger all cost amplifiers simultaneously:

1. Each step requires carrying the complete history, causing input tokens to accumulate almost quadratically with the number of steps.
2. Logs, code, and web content returned by tools flood the context.
3. Long outputs and multi-turn retries compound each other.

A magnitude illustration (actual pricing depends on the specific platform):

def cost(hit_m, miss_m, out_m, p_hit, p_miss, p_out):
    """hit_m/miss_m/out_m: number of tokens in millions; p_*: corresponding unit prices"""
    return hit_m * p_hit + miss_m * p_miss + out_m * p_out
# For the same task, with a stable prefix and a cache hit rate of 90%,
# input costs can drop by about an order of magnitude—this is the value of "system prompt prefixing + stable prefixes".

A checklist of practices for governing quota consumption:

• Stable Prefix: Place system prompts and tool definitions at the very front of the context without modification to maximize prefix cache hits.
• Context Pruning: Summarize and retire historical tool outputs, retaining only key states.
• Hard Circuit Breakers: Set token and step limits for each task.
• Tiered Routing: Route simple sub-tasks to smaller models; escalate to flagship models only for difficult problems.
• Full-Link Tagging: Log token consumption by business dimension to precisely identify the “money-burning” segments.

VI. Managed Agents: From “Calling Models” to “Buying Runtimes”

Another notable trend is the cloudification of the runtime framework itself. Platforms now directly offer managed agent environments capable of running 24/7 long-horizon tasks and supporting multi-agent collaboration, eliminating the need for enterprises to build their own sandboxes, schedulers, and monitoring systems. The benefits are significant maintenance-free operations and elastic concurrency. However, this introduces new governance challenges—data boundaries, trajectory auditing, cost circuit breaking, and failure replay—requiring clear SLAs and log retention policies before integration.

VII. Enterprise Deployment Recommendations

Based on the trends above, here are four actionable recommendations:

1. Evaluation First: Build a custom set of 20 to 50 tasks covering real business scenarios for regular horizontal evaluation. Terminal state pass rates and unit costs are more valuable references than benchmark scores.
2. Gradual Rollout: Roll out new models gradually by traffic percentage, retaining a quick rollback path to the previous version.
3. Cost Observability: Establish a Trace for every agent run, metering input, output, and cache hits separately, and configure budget alerts.
4. Infrastructure Selection: Utilize general capabilities from platforms like Baidu AI Cloud—such as LLM services, container services, function compute, object storage, log services, and monitoring—to compose your evaluation pipeline and agent runtime environment, avoiding vendor lock-in with a single proprietary interface.

Conclusion

The next phase of competition for flagship models is no longer on the parameter sheet. It lies in the industrialization degree of post-training environments, the maturity of agent runtimes, and the refinement of token economics. For developers, understanding “the evaluation design behind the scores, the engineering trade-offs behind high-speed versions, and the caching mechanisms behind the bill” is far more critical to project success than chasing single-point benchmark scores.