---
title: "Connecting 500 AI Models Is Not Hard. Keeping Things from Going Wrong Afterward Is."
author: "Unique Research"
sourcePublication: "Unique Research Substack"
originalPublishedAt: "2026-03-19T10:01:22+00:00"
canonical: "https://ffcap.cn/en/research/src-20260319-03html"
source: "https://uniqueresearch.substack.com/p/src-20260319-03html"
language: "en"
---

# Connecting 500 AI Models Is Not Hard. Keeping Things from Going Wrong Afterward Is.

_Original · Unique Research · 2026-03-19 · Shanghai_

_English edition note: This complete translation preserves the source author's first-person assessments, the interview statements and the five closing Q&A pairs. Model coverage, reliability, cost advantages and business prospects below are claims or views expressed in the source, not an independent service audit or performance guarantee. The original introduces its capability list as five words but actually lists six; both the wording and all six items are retained. Jingling is Li Jinglin's nickname, with Elf given only as a literal gloss. Statements about future Agent services reflect this March 2026 interview and should not be conflated with earlier interviews or treated as confirmation of delivered capabilities._

Unique Awards · Guest Interview

He Is Not the Most Visible Gold Prospector—He Is the One Building the Water, Power, Roads, and Warehousing

Li Jinglin: We are not the loudest people out front, but for many AI applications to work, someone first has to build the roads behind the scenes.

Interviewee: Li Jinglin, founder and CEO of DeerAPI

Interview date: March 2026

An interesting phenomenon has emerged in the AI industry over the past two years.

The model companies are always the ones drawing the biggest crowds onstage.

The AI applications that attract the most attention are those with extraordinary growth curves and spectacular Demo presentations.

But when it comes to putting them into actual business use, the first obstacle people encounter is often not a product problem. It is something messy, grueling, and very real:

How do you connect to models? Switch between them? Keep them stable? Save money? Handle concurrency?

None of this looks glamorous.

But it determines whether an AI application is just an attractive demonstration or a business that can survive.

A little while ago, I spoke with Li Jinglin, founder and CEO of DeerAPI.

Many people in the industry call him "Jingling," or "Elf."

If you imagine today's AI industry as a large-scale gold rush, model companies are building the mines, while application companies are selling shovels, maps, and stories about striking gold. People like those at DeerAPI play a different role:

They are not the most visible gold prospectors. They are building the water, power, roads, and warehousing.

They do not stand in the spotlight, but whether many others can actually find gold depends on how reliably they build the underlying infrastructure.

The Real Pain Is Not Having No Models, but Having Too Many

Many outsiders assume the hardest part of building an AI application today is gaining access to model capabilities.

That has not been the case for some time.

The more common problem today is having too many models.

OpenAI, Claude, Azure, Gemini, all kinds of open-source models, various intermediary services, different ways of accessing them in different regions, capability differences across versions, different pricing systems, documentation standards, and reliability levels…

You might think more choice is a good thing. But once you actually start building a product, you discover that choice itself can become a cost.

Li Jinglin encountered this problem when he first started making AI applications himself.

He also began with a wrapper application. To get the product running, he had to integrate with model sites one by one: register accounts, add funds, read documentation, and debug interfaces. After all that, if the model's results were unsatisfactory, he had to switch. The new provider would have different billing methods, calling conventions, and reliability, requiring another round of adaptation.

The problem was not that there were no capabilities available.

The problem was the enormous amount of repetitive work required to find a set of capabilities that worked, worked well, were affordable, and could keep running reliably.

That was the starting point for DeerAPI.

Put simply, it did not create the models themselves. It attempted to reorganize an activity that had been highly scattered and fragmented.

It would travel many of the roads developers previously had to navigate themselves.

Why Do Similar-Looking AI Applications Have Such Different Chances of Survival?

I think this is exactly where many people underestimate platforms such as DeerAPI.

Many reduce an API aggregation platform to a dismissive question:

"

Isn't it just connecting lots of models together?

But anyone who has built a live product knows it is nowhere near that simple.

For an application to move from Demo to a real business, it must clear at least several hurdles:

The first is integration speed. If every model change requires a fresh round of adaptation, product iteration slows dramatically. Many teams ultimately fail not for lack of ideas, but because integration costs are too high and experimentation is too slow.

The second is whether the economics add up. Many small teams begin building products without a strong sense of calling costs. Then, as users increase, token consumption, model bills, and different providers' billing methods all hit at once, immediately distorting the gross-margin structure.

The third is reliability. During early testing, a dropped connection or a delay of a few seconds may seem tolerable. But once a product enters production—especially in online applications, enterprise settings, or games—reliability stops being merely a user-experience issue. It becomes a revenue issue, a customer-churn issue, and even a brand-reputation issue.

The fourth is whether concurrency can be handled. Many services seem usable under normal conditions but begin failing at peak times. AI applications have a particular characteristic: when they take off, growth is often not gradual. Traffic, requests, and task volumes surge together. That is when the underlying support capabilities face their real test.

So when DeerAPI describes the problems it addresses, it uses five words:

Easy, economical, current, fast, stable, comprehensive

It sounds like a typical company slogan.

But unpack it, and each word corresponds to a very real make-or-break issue for AI applications.

Easy means one-stop integration.

Economical means cost optimization and bill management.

Current means model updates and flexibility of choice.

Fast means fast integration, fast launches, and fast responses.

Stable is the minimum requirement for a production-grade service.

Comprehensive means model coverage and breadth of capabilities.

These are not merely nice extras.

Often, they are what determine whether a team can avoid a few fatal mistakes.

The Hard Part of API Aggregation Is Not Connecting Many Models, but Keeping Things from Going Wrong Afterward

Li Jinglin said DeerAPI aggregates 500+ models.

Of course, that is an easy number to put in promotional copy.

But what interests me more is not the number 500+ itself, but what it means.

As the number of models grows, the headaches do not rise linearly; they multiply.

You have to keep up with version updates.

Monitor pricing systems.

Assess each model's capability boundaries.

Handle availability across regions.

Support users when problems arise.

Schedule resources when concurrency rises.

Maintain cost competitiveness.

And keep service reliability from slipping.

At that point, you realize the real barrier to building an API aggregation platform is not just technical.

It is a technology problem, a supply-chain problem, an operations problem, and even a classic exercise in meticulous systems management.

Li Jinglin mentioned that it draws on supply-chain experience he accumulated during his earlier work in e-commerce.

That struck me as especially true to life.

When people hear about AI entrepreneurship, they often want to hear only about the frontier, disruption, and paradigm shifts.

But when an industry truly matures, the final contest is often not about who tells the newest story best. It is about who can do the painstaking, unglamorous systems work that others cannot do well.

Putting more than 500 models behind one entry point is only the surface.

Absorbing the complexity behind those 500-plus models so customers feel that using them is not so complicated—that is the real skill.

What is it like?

Building a highway.

Drawing the map is not enough. You must actually build a smooth road, install toll stations, clear bottlenecks, provide service areas, and ensure that different types of vehicles can use it.

What users see is: "I got there faster."

What they do not see is how much foundational engineering you did behind the scenes.

Why Will This Business Continue to Exist?

Many people ask a pointed question:

"

If major companies such as OpenAI and Anthropic keep improving global access, service reliability, and pricing, will the value of aggregators such as DeerAPI be diluted?

It is a very good question.

But I think the answer is already clear in today's division of labor.

The major companies aim to build the strongest models and the best native capabilities.

Aggregation platforms aim to help users make more efficient use of those capabilities in a complicated real world.

The relationship is not one of simple substitution. It is more like collaboration.

Official APIs will always have their authority, native capabilities, and brand trust.

But for many developers and enterprises, real-world needs are never limited to calling one company's strongest model.

The actual needs are:

Can I launch faster?

Can I switch flexibly between multiple models?

Can I bring costs down to a more reasonable level?

Can I build disaster recovery and choice across different providers?

Can I manage an increasingly complex AI capability stack in a more unified way?

As long as those needs exist, aggregation platforms will not disappear.

In a sense, the more models there are and the faster they change, the greater an aggregation platform's value becomes.

The more the industry flourishes, the more complex it becomes.

And the more complex it becomes, the more it needs specialists in abstraction, organization, packaging, and delivery.

That is why what looks like a business of connecting things ultimately competes on the combined capabilities of technology + supply chain + operations + service.

Today's DeerAPI Sells More Than Interfaces

At this point in the conversation, what most interested me was where DeerAPI would go over the next 12 months.

Li Jinglin highlighted an important direction: the Agent wave brought by OpenClaw.

This deserves a closer look.

In the AI application era, if the contest is about who can build a particular capability,

then in the Agent era, it is about who can coordinate multiple models, tasks, and stages more reliably.

In the past, a product might have needed to call only one primary model.

In the future, an Agent system may need to call multiple models, tools, and workflow nodes at once, while also accounting for task decomposition, response speed, success rates, cost control, and fault tolerance.

This means the importance of underlying infrastructure will only increase.

Of course, simply remaining a provider would not be enough for DeerAPI.

But if it can follow the Agent wave further, understand new calling structures, service approaches, and production-grade requirements, it will be doing more than API aggregation. It will be moving toward a more upstream AI orchestration and service layer.

This change is crucial.

It means that what companies like this really sell in the future will not just be interfaces themselves, but:

Reliability, choice, cost efficiency, production capabilities, and the underlying support that helps customers turn AI into a working business.

In other words,

what they sold in the past was integration capability;

what they may increasingly sell in the future is the certainty that a business can run.

That is the larger business.

I Liked the Way He Refused to Overstate Things at the End

There is a strong impulse in the industry today:

Everyone likes to define next year, make judgments about the year after, and draw roadmaps for the industry.

But Li Jinglin's final answer made a particularly strong impression on me.

"

AI is changing enormously. Something new appears every day; even the "lobster" has arrived. It is hard to say exactly what kind of company DeerAPI will become by the end of 2026. Rather than describing a beautiful future in advance, what matters more is doing each day's work well, serving every customer with care, and genuinely creating value for users.

I thought that was a good answer.

It was unlike the kind of response you normally hear in a standard founder interview.

There was no grand vision packaged around it, and none of the terminology that immediately sounds prepared for fundraising.

That was precisely what made it more credible.

One of the industry's biggest risks today is that too many people are rushing to define the future.

But the companies that truly make it are often not those that shout slogans most effectively. They are the ones that know which layer they occupy, what problem they solve, and why customers are willing to keep paying.

That is also the impression DeerAPI gives me.

It may not be the company that shines most brightly at the center of the stage today.

But it may well be one whose value becomes increasingly apparent as the industry grows more complex.

When everyone is charging forward, the truly scarce people are not only those who move fast.

They are also those who enable more people to keep moving reliably.

Selected Q&A

Q1: Why did DeerAPI begin with API aggregation?

Li Jinglin initially built AI applications himself. In the process, he found model integration extremely time- and energy-consuming: registering with providers one by one, adding funds, reading documentation, debugging, and continually testing model performance. If the results were unsatisfactory, he had to switch again. Having encountered these problems himself, he realized the market did not really need one more model. It needed a single entry point that could unify these complex processes.

Q2: How does DeerAPI differ from directly integrating with the official OpenAI or Claude API?

Official APIs address the availability of native capabilities. Aggregation platforms such as DeerAPI are more concerned with integrating those capabilities faster, switching more flexibly, reducing costs, and keeping them running reliably online. They are not simply substitutes for one another, but different layers in the division of labor.

Q3: What is the greatest challenge in aggregating 500+ models?

The greatest challenge is not listing the models, but actually managing them: model updates, price fluctuations, service availability, technical support, operational scheduling, and concurrency handling. The more models there are, the greater the complexity. But customers will not pay for your complexity. They care about only one thing: whether the service works well and reliably.

Q4: What growth opportunity does DeerAPI see as most promising over the next 12 months?

Li Jinglin pointed to the Agent wave brought by OpenClaw. In his view, this shift may mean more than selling a little more API usage. It may prompt the platform to rethink whether it can provide more valuable services in the Agent ecosystem beyond being a provider. That shows DeerAPI is also looking for a higher-value position in its next stage.

Q5: What kind of company will DeerAPI become by the end of 2026?

His answer was restrained. Rather than trying to define a grand future, he acknowledged that AI changes extremely quickly, with new variables emerging every day. More important than saying what the company will become is doing each day's work well, serving every customer, and continuously creating value for users. In a sense, that restraint is itself a form of judgment.

---

Original publication: https://uniqueresearch.substack.com/p/src-20260319-03html
On-site reading page: https://ffcap.cn/en/research/src-20260319-03html