Domestic LLMs Race Toward AGI: K2 Milestones and the K3 Roadmap

1. From Base Model to Reasoning Model: A Two-Step Approach in 2025

In 2025, a large model team released two categories of models in September and November: the base model K2, and the K2 Thinking series built around a reinforcement learning reasoning path. This “base plus reasoning” dual-track cadence reflects two fundamental directions in large model evolution. The base model acquires general knowledge and representational capability through pretraining scaling, while the reasoning model builds on top of it, using reinforcement learning and other methods to improve reasoning depth and stability on complex tasks.

From an engineering perspective, the division of labor between base and reasoning models is not simply “one large, one specialized.” The base model determines the capability ceiling—its training data scale, parameter count, training compute, and optimization strategy together define the model’s effective FLOPs level. The reasoning model focuses on “how to use that capability well,” converting the base model’s potential into results on math, code, and multi-step planning tasks through chain-of-thought, sampling strategies, verification mechanisms, and reinforcement learning reward design.

In an internal letter, the team lead stated that the release of K2 and K2 Thinking marked an important step on the path to AGI. The technical implication of this judgment is that base capability and reasoning capability are beginning to form a reusable combined paradigm, rather than remaining isolated point breakthroughs.

2. Agent Product Matrix: From Capability to Usability

In parallel with the model releases, the team shipped agent features at high frequency starting in May 2025, successively launching a research agent, a general task agent, presentation generation, and a code agent. The common thread across this product line is packaging model capability into a form that “can complete end-to-end tasks,” rather than stopping at conversational Q&A.

The engineering challenges of agent products typically cluster around three areas:

1. Task decomposition and tool invocation. An agent needs to break a user goal into executable sub-steps and call tools such as retrieval, code execution, and file read/write at the right moments. The reliability of tool invocation directly determines task success rate.
2. Context and state management. Long tasks generate large amounts of intermediate results. How to compress, summarize, and retrieve within a limited context window is key to keeping long-horizon tasks from going off track.
3. Failure recovery and observability. Agent execution chains are long, and any single step’s error can be amplified. Retry, rollback, and human confirmation mechanisms need to be designed, along with complete execution traces for debugging and evaluation.

Taking the code agent as an example, a typical task execution loop can be expressed in pseudocode:

while not task_done:
    plan = model.plan(goal, history)
    action = model.select_action(plan, available_tools)
    result = execute(action)          # call tool or execute code
    history.append((action, result))
    if result.error:
        history.append(recover(result))  # failure recovery strategy
    task_done = model.verify(goal, history)

This loop looks simple, but every link depends on the interplay between model capability and engineering constraints: the quality of plan depends on the model’s reasoning ability, select_action depends on how clearly tools are described, and verify requires reliable judgment criteria. This is the practical backdrop for the phrase “vertical integration of model training and agent product taste.”

3. Commercialization Signals: Dual Growth in Paid Users and API Revenue

Leveraging the K2 series’ performance, the team’s consumer-facing commercialization showed exponential growth from September to November 2025: month-over-month growth in overseas and domestic paid users exceeded 170%. Meanwhile, the release of K2 Thinking significantly boosted API revenue, with overseas API revenue growing 4x over the same period.

These figures are worth interpreting from a technical angle:

• Paid user growth indicates that agent-type features deliver direct productivity value—users are willing to pay for “completing tasks” rather than “chatting.” This requires the product to balance task success rate, response latency, and cost.
• API revenue growth indicates that reasoning models have found traction in developer scenarios. Developers typically embed models into their own workflows and are more sensitive to output stability, structured capability, and invocation cost. Improved performance on complex tasks translates directly into efficiency gains in developer workflows.

It is worth emphasizing that these figures reflect market feedback at a specific stage. Comparability across different product forms and pricing strategies is limited, and they should not be simply extrapolated into a universal industry pattern.

4. Three Technical Paths for K3

Looking to the next stage, the team proposed three priorities centered on K3, which together form a complete technical roadmap.

4.1 Larger-Scale Scaling: An Order-of-Magnitude Increase in Equivalent FLOPs

The first priority is to raise equivalent FLOPs by at least an order of magnitude through technical improvements and further scaling, matching the world’s frontier models at the pretraining level.

“Equivalent FLOPs” is a concept closer to actual capability than “parameter count”: it comprehensively reflects the effective compute a model actually consumes during training, including parameter scale, data scale, training duration, and the compute efficiency differences introduced by architecture and optimization. Raising it by an order of magnitude means advancing simultaneously on compute, data quality, training stability, and parallelism strategy. Common engineering challenges include communication bottlenecks in large-scale distributed training, fault tolerance and checkpoint management for long-cycle training, data mixing and deduplication strategies, and fine-grained tuning of learning rate and regularization in late-stage training.

4.2 Vertically Integrating Model Training with Agent Product Taste

The second priority is to vertically integrate model training with agent product “taste,” making K3 a more “distinctive” model that offers new capabilities other models have not defined.

“Taste” here can be understood as the product-level judgment of “what counts as a useful output.” The traditional approach is to train the model first and then develop the product, with the product only passively adapting to model capability. Vertical integration means systematically feeding product-side feedback signals—task success rate, user correction behavior, tool invocation traces—back into the training loop. Its technical implementation typically involves:

• Building high-quality task trajectory datasets covering real agent usage scenarios;
• Designing reward models or verifiers oriented toward task completion, not just dialogue quality evaluation;
• Introducing structured objectives such as tool invocation and multi-step planning during training, so the model is “natively” suited to the agent form.

The value of this path lies in differentiation: general capabilities are easy to catch up with, while capability combinations deeply coupled to a specific product form are harder to replicate.

4.3 Agent-Focused Commercialization: Aiming at the Intelligence Ceiling

The third priority is to focus products and commercialization on agents, not treating absolute user numbers as the goal, continuously pursuing the intelligence ceiling, creating greater productivity value, and driving revenue growth by an order of magnitude.

The trade-off in this strategy is clear: abandon the scale race centered on DAU and shift to “value per task” as the metric. For developers and enterprise users, this means evaluating models by task completion rate, rework cost, and end-to-end latency rather than invocation price alone. For platform providers, it means building a metering and service system tied to task value.

5. Practical Implications for Developers and Enterprises

Synthesizing the above, several judgments useful to frontline developers can be extracted:

1. Select base versus reasoning models on demand. For general Q&A and lightweight tasks, prioritize base models to control cost; for tasks involving multi-step reasoning, code generation, and planning, the marginal benefit of reasoning models is more pronounced.
2. Solve observability first in agent deployment. Before pursuing task success rate, establish execution trace logging, failure classification, and regression evaluation systems—otherwise optimization has no foundation.
3. Focus on the feedback loop. If an enterprise has stable business scenarios, it should design a “usage data—evaluation—training” feedback chain early. This is the long-term solution for aligning model capability with business needs.
4. Measure investment by task value. When budgets are limited, prioritize directing model capability toward high-frequency, high-value, measurable tasks rather than spreading it evenly.

From K2 to K3, the core logic of this roadmap is clear: use scaled pretraining as the foundation, improve task completion through reasoning capability, carry value through agent products, and feed product feedback back into model training. For developers tracking large model evolution, each step of this path corresponds to concrete, verifiable engineering problems and is worth continued attention.