Open-Source LLM Selection Criteria: Lessons from a Mainstream Coding Tool's Choice

1. A Controversial Selection: The Real Question Is the Criteria, Not the Model

The AI coding tool market recently saw a noteworthy development: a coding assistant product from an international tech giant added a Chinese open-source LLM to its list of selectable models. Once the news spread, discussion in developer communities quickly focused on a single question: why this model rather than several other, more popular Chinese alternatives?

Framing this as a popularity contest between brands easily descends into tribalism and flame wars. But from another angle, a commercial coding tool integrating a third-party open-source model is fundamentally a serious technical procurement decision. Candidate models must pass capability evaluation, engineering fit, legal review, cost estimation, and several other checkpoints. Once you understand this screening mechanism, the answer to “why this one” becomes clear: it is not luck. Under the specific filtering conditions involved, qualified candidates were simply scarce to begin with.

The sections below break this screening mechanism into four gates and then discuss what it implies for open-source vendors and for enterprises making their own model selections.

2. Gate One: Native Multimodality Has Become a Prerequisite, Not a Bonus

2.1 Frontier Models Are Fully Multimodal

An industry fact that is often overlooked: the current international frontier models have generally achieved native multimodality—unified text, image, and audio input, with relatively balanced capabilities across modalities. This means that for any open-source candidate hoping to enter mainstream international products as a “frontier-model alternative,” multimodality is no longer a nice-to-have bonus. It is the qualification line that determines whether a model gets in the door at all.

2.2 Why Coding Scenarios Genuinely Require Multimodality

“Writing code is just a text task, isn’t it?”—this is the most common objection in these discussions. But observe a real development workflow and multimodality turns out to be close to a hard requirement:

• UI reproduction: Hand a design mockup or webpage screenshot directly to the coding assistant and let the model “see” it to generate front-end code—far more efficient than describing the layout in words;
• Error diagnosis: Pop-up error dialogs, log screenshots, and monitoring dashboard captures are the most frequent information carriers in a developer’s daily work;
• Architecture collaboration: Whiteboard photos, flowcharts, and sequence diagrams often carry the entire context of a technical discussion;
• Voice interaction: In mobile work and accessibility scenarios, voice commands continue to grow in importance.

A typical multimodal request structure in the industry looks roughly like this (illustrative):

{
  "model": "<candidate model>",
  "messages": [
    {
      "role": "user",
      "content": [
        { "type": "text", "text": "Please reproduce this UI design mockup as a front-end page" },
        { "type": "image_url", "image_url": { "url": "<screenshot URL>" } }
      ]
    }
  ]
}

A text-only model, no matter how strong its code generation, cannot plug into any of the workflows above. That is why “native multimodality or not” becomes the first cut in the screening process.

2.3 The Current State of China’s Open-Source Camp: a Scant “Three and a Half”

Based on public information, among China’s open-source camp, models that natively support all three input types—text, image, and audio—can be counted on one hand, roughly describable as “three and a half”:

• Three fully support text, image, and audio input;
• The remaining “half” is only partially open source and does not support audio input, greatly reducing its practical usability.

Most other models in the domestic open-source camp remain text-only and never even qualify for the evaluation list. In model selection, elimination often happens not because capability falls short, but because the model is not even in the race.

3. Gate Two: Parameter Scale Sets the Capability Ceiling

3.1 The Scarcity of Trillion-Parameter Models

Among the few multimodal open-source options, parameter scale is clearly stratified: only one model currently reaches the 1T (trillion) level, while the rest cluster in the 300B–400B range. This gap directly determines how high the capability ceiling can go.

3.2 A Notable Mismatch: Large Parameters Do Not Equal Multimodality

More interesting still is the internal mismatch at some vendors: the largest flagship closed-source model does not support multimodality, while the smaller open-source version is the one with multimodal capability. This creates a selection constraint—

If a coding tool wants to bring in an open-source alternative that is “as close as possible to frontier closed-source model level,” it must simultaneously satisfy two conditions: sufficiently large parameter scale and native multimodality.

Filter by this intersection, and the candidates that currently satisfy “trillion-level parameters + full multimodality + verifiable capability” are vanishingly few. The selection outcome is hardly a surprise.

3.3 Why an Alternative Must Match Parameter Scale

The value of an open-source model as a replacement for a frontier closed-source model lies in capability alignment, private deployment, and controllable cost. Capability alignment, in turn, presupposes that parameter scale does not differ by orders of magnitude. Models in the 300B–400B range perform usably on most routine tasks, but in complex reasoning, long-context consistency, and highly complex code generation, a perceptible gap with trillion-level models remains. For commercial products that treat the model as their productivity foundation, this gap cannot be ignored.

4. Gate Three: Open-Source Completeness and Licensing—Legal Review Comes Before Technical Review

“Open source” is not a black-and-white concept. It contains at least three layers:

1. Degree of weight openness: Are training weights fully published, or only partial intermediate artifacts?
2. License terms: Is commercial use permitted? Are specific usage scenarios restricted? Are derivative works required to be open-sourced as well?
3. Accompanying assets: Are the tokenizer, inference code, technical report, fine-tuning scripts, and so on all available?

Before a commercial product integrates an open-source model, its legal team reviews the license clause by clause. A model may be ever so capable, but if its agreement contains terms restricting commercial use or specific scenarios, it may be eliminated in the first round of review. This also explains the predicament of the “half” mentioned earlier: incomplete open source is roughly equivalent to hard to commercialize.

5. Gate Four: Proven Capability and Engineering’s Risk Aversion

Commercial product selection is highly risk-averse. For a model to enter the selectable list, it must not only “be able to do it” but “have been proven able to do it.” Proof here typically comes from three kinds of evidence:

• Public benchmarks: rankings and scores on authoritative benchmarks for code generation, multi-turn tool calling, long-context understanding, and similar tasks;
• Real-world usage scale: call volume after launch, user retention, and community reputation;
• Engineering maturity: inference stability, long-context performance, and the reliability of function calling and structured output.

From this angle, another phenomenon becomes clear: why do several multimodal models at the next parameter tier down also enjoy considerable positive reception in international communities? The logic is similar—within the set of “available alternatives,” they are the only remaining candidates. Models outside that set do not even meet the basic multimodality condition and are naturally outside the evaluator’s field of view. The distribution of reputation is largely determined by the scarcity of available options, not by marketing volume alone.

6. Practical Selection Guidance for Enterprises and Developers

With the screening logic above understood, enterprises and developers can apply the same checklist to their own model selection.

6.1 Start with Modality Matching

Clarify which input modalities your business scenarios require (text, image, audio), then filter the candidate pool accordingly. Do not be misled by high scores on text-only benchmark leaderboards—however high the score, a model that cannot plug into your image workflow scores zero for you.

6.2 Balance Parameter Scale Against Deployment Cost

Trillion-level models have a high capability ceiling but also high inference costs, typically relying on multi-GPU clusters; 300B–400B models can be deployed on more economical hardware with quantization. A layered approach by scenario is recommended:

Assess task complexity → Is frontier-level capability required?
    ├── Yes → Trillion-level open-source model or flagship commercial API (cloud inference)
    └── No  → Mid-size model + quantization + private deployment

6.3 License and Compliance First

Complete license review before investing in technical validation, so you do not discover after committing R&D resources that commercial use is prohibited or restricted.

6.4 Validate with Your Own Tasks, Not Just Leaderboards

Design an evaluation set close to your own business—for example, completion, bug fixing, and refactoring tasks on your real codebase—and let candidate models “run the numbers” on internal data. Drive decisions with your own evidence.

6.5 Leverage Mature Cloud Infrastructure

For enterprises seeking to balance performance and cost, general-purpose capabilities such as model inference services, container platforms, and logging and monitoring alerts available on Baidu AI Cloud can help teams focus on business integration and building their evaluation systems rather than building underlying compute operations from scratch. The end point of selection is not “which model to pick” but “whether it can run in production stably, compliantly, and at low cost.”

7. Conclusion

Back to the original question: why was “it” the one selected? The answer is not mysterious. When the filtering conditions are “thoroughly open source + full multimodality + trillion-level parameters + proven capability,” very few candidates satisfy all of them, and the outcome settles itself.

This selection event is more like a mirror, reflecting a signal that open-source model competition has entered a new stage: the race on pure text capability is nearing its end, and multimodal capability, parameter scale, and open-source completeness are forming a new three-dimensional threshold. For domestic open-source vendors, whoever is first to complete the combination of “large parameters + full multimodality + thorough open source” in the next window will earn a place on the next selection list. For enterprises and developers, understanding this selection logic is the first step toward making sound technical decisions amid the noise.