Jiaxing Brings Over 100 Models Under One Access Point

Jiaxing Launches a “Unified Gateway for Large Models”

On July 30, the Yangtze River Delta (Jiaxing) Token Operations Center officially launched in Jiaxing, Zhejiang, along with its market-facing portal website. According to official disclosures, enterprises need to integrate only once to access more than 100 mainstream large models, including DeepSeek and Qwen, on demand. The platform also automatically matches tasks with more cost-effective models, aiming to let “enterprises choose the task and the platform choose the model.”

This is not simply another platform selling API keys.

Judging by the features announced so far, Jiaxing has greater ambitions: to build a regional AI resource operations layer. It aggregates model, computing power, and application service providers upstream, addresses the real needs of manufacturing enterprises downstream, and centrally handles access, Token metering, billing and settlement, policy-based deductions, and security auditing.

If this mechanism can truly work, it will solve more than the developer inconvenience of “integrating with fewer interfaces.” It will address the more troublesome aspects of enterprise AI procurement—vendor onboarding, cost allocation, budget control, data compliance, call traceability, and the application of local subsidies to bills.

Five Unified Capabilities Matter More Than “Aggregating Hundreds of Models”

The operations center has proposed five core capabilities:

• Unified API access
• Unified Token metering
• Unified billing and settlement
• Unified policy-based deductions
• Unified security auditing

Aggregating more than 100 models may sound the most eye-catching, but that capability is no longer scarce today. Large-model platforms from cloud providers, third-party API aggregation services, and internal enterprise AI gateways already allow developers to switch among multiple models through a single access point. What enterprises truly struggle with are the contracts, invoices, permissions, and boundaries of responsibility behind different vendors.

For example, a manufacturing enterprise may use a vision model to inspect products for defects, a language model to parse equipment manuals, and a code model to assist in writing production-line scripts. The model source, pricing unit, and data sensitivity level differ across all three scenarios. A development team may be able to integrate the APIs within days, but the procurement department may not be able to onboard three vendors in the same timeframe. The finance department will also find it difficult to consolidate differently measured Tokens, images, video duration, and computing costs into a single cost sheet.

The Jiaxing platform’s value lies in its attempt to compress these nontechnical frictions into a single public gateway. “Unified policy-based deductions” are particularly significant because they may allow local industrial policies to shift from project applications and after-the-fact subsidies to direct deductions from usage bills. For small and medium-sized enterprises, this is more practical than receiving a list of models and makes it easier to calculate exactly how much an AI project has saved.

However, “unified Token metering” is not simple in itself. Different models use different tokenizers, so the same sentence may correspond to different Token counts across models. Image, audio, and video models cannot be directly compared using text Tokens alone. If the platform merely aggregates bills from different vendors, only the access point is unified. True unification requires standardized metering and price-conversion rules across modalities and models.

Automatic Model Selection Is the Right Direction, but Unit Price Cannot Be the Only Factor

The platform proposes automatically matching enterprise tasks with the most cost-effective models, effectively adding a model router on top of the API gateway.

In theory, the router can first identify the task and then decide which model to invoke: simple classification and information extraction can go to smaller models, while complex reasoning can go to more capable models; Chinese long-form text processing can be assigned to models with more reliable Chinese-language capabilities, while coding tasks can be routed to models that perform better on code. If high-frequency, low-complexity requests no longer default to the most expensive model, Token costs could indeed fall significantly.

However, “cost-optimal” cannot simply mean the lowest price per input or output Token. What enterprises truly care about is the total cost of completing one successful task, which includes at least:

• The first-response success rate and the number of retries after failures;
• Latency, concurrency limits, and availability during peak periods;
• Tool use, structured output, and long-context capabilities;
• Whether data flows across regions and where logs are stored;
• Whether existing prompts and evaluation results become invalid after a model upgrade;
• The cost of human review when incorrect answers enter business workflows.

A small model priced at only one-third the cost of a flagship model may not ultimately be cheaper if it must be called three times and requires an additional round of manual review. Model routing therefore cannot merely rank models by price. It must establish scenario-specific evaluation sets and continuously measure accuracy, latency, stability, and cost per task.

For development teams, the ideal arrangement would allow the platform to define explicit policy boundaries. For example, customer-service summaries could be routed automatically, but contract reviews could only use a pool of enterprise-approved models; ordinary requests could prioritize lower-cost models and escalate to stronger models when confidence is insufficient; requests involving sensitive data could only invoke locally or privately deployed models.

If the platform turns automatic routing into an opaque black box, enterprises will instead lose control over model versions and output quality. A truly mature routing system should be able to answer three questions: Why was this model selected for the request? Which evaluation data informed the decision? Where will the request be routed if the selected model is unavailable?

Jiaxing’s Advantage Is That Computing Power and Manufacturing Use Cases Are in the Same City

Jiaxing’s Token operations initiative did not emerge from nowhere. Public information shows that the city already hosts four computing centers—operated by Range Technology, Alibaba, China Telecom, and China Mobile—each with tens of thousands of accelerator cards. It is also home to 6,327 industrial enterprises above the designated size and more than 230 AI technology companies. The simultaneous presence of computing supply and manufacturing demand is what distinguishes this operations center from an ordinary model marketplace.

Manufacturing is also one of the most direct and demanding environments for testing the value of large models.

Apparel companies want to use generative AI to shorten design cycles, electrical equipment companies need quality-inspection systems capable of interpreting circuit diagrams, and equipment manufacturers want models to read technical documentation and generate quotations. These use cases are not seeking the highest scores on chatbot leaderboards. They require models that can integrate with enterprise knowledge bases, MES and ERP systems, and quality-inspection equipment, while operating continuously and reliably.

Among the local cases disclosed by officials, an AI-assisted design platform has already been used to design down jackets, luggage, and children’s clothing. It has reduced parts of the design cycle from weeks to hours, increased development efficiency by as much as 30-fold, and lowered image-generation costs by at least 50%. These figures still need to be assessed in the context of specific workflows and statistical methodologies, but they at least show that Jiaxing does not intend to operate abstract Tokens. It wants to operate effective model calls embedded in production lines and business systems.

The operations center will next focus on Jiaxing’s established industries, including advanced textile materials, smart terminals, and high-end equipment. This is a relatively pragmatic choice. Rather than building a platform that covers every industry but ultimately remains a showcase, it would be better to focus on a small number of industries and develop evaluation sets, knowledge-base templates, data standards, and delivery-partner networks around them.

“Token Production” Is an Industrial Narrative and Should Not Be Confused With the Technical Concept

Local authorities describe computing power as the primary input for Token production and propose building a full-lifecycle Token scheduling system and standardized metering, billing, and settlement framework. This framing makes it easier to place computing power, model usage, and industrial output within a single policy framework. Technically, however, a Token is not a commodity that can be stored and transported independently of a model.

The same GPU can generate vastly different numbers of Tokens per second depending on the model, inference framework, quantization precision, batching strategy, and context length. A Token generated by one model can also differ entirely in quality and business value from a Token generated by another. Directly comparing Tokens to kilowatt-hours of electricity can obscure the differences between model capability and inference efficiency.

A more accurate interpretation is that the operations center is attempting to package fragmented computing resources and model services into measurable, billable, and auditable AI invocation capabilities. Tokens are the most common billing unit involved, but they will not be the only one. As vision, speech, video, and Agent-based tasks increase, the platform may ultimately need to support billing based on the number of images, video duration, tool calls, GPU time, and the aggregate cost of completing an entire task.

Therefore, “making AI available on demand like water and electricity” is a goal, not the current reality. Water and electricity have highly stable quality standards, while large-model outputs are probabilistic. The former can be used as soon as a connection is established; the latter still requires evaluation, prompt engineering, data governance, and human safeguards.

A State-Owned Platform Must Prove Its Operational Efficiency, Not the Quantity of Its Resources

The platform has a state-owned capital background, which brings both advantages and disadvantages.

On the one hand, a state-owned platform can more easily connect local computing centers, industrial policies, and manufacturing enterprises. It is also better positioned to establish unified auditing, trusted metering, and green Token traceability systems. For enterprises with sensitive data and strict procurement procedures, the credibility of a public platform may matter more than low prices alone.

On the other hand, the large-model market changes extremely quickly. Model versions may be updated weekly, prices are adjusted continuously, and API capabilities change frequently. If a public platform follows the development and procurement pace of traditional IT projects, it can easily end up with a live portal but a model catalog that remains outdated for long periods. Alternatively, it may integrate 100 models while only a handful provide stable SLAs and comprehensive technical support.

The first group of 20 ecosystem partners has already signed agreements to join, covering computing power, models, applications, services, and other parts of the value chain. What matters next is not how much further the partner count grows, but whether the platform can publish several verifiable metrics:

1. How many of the more than 100 models provide production-grade SLAs rather than trial access only;
2. Whether the API is compatible with mainstream protocols and how much application code must be changed when switching models;
3. How much automatic routing actually reduces per-task costs compared with enterprises selecting fixed models;
4. Who stores request logs, prompts, and enterprise data, and how long they are retained;
5. Who bears responsibility for model failures, content-safety incidents, and billing disputes;
6. Whether policy-based deductions can be applied directly to bills and produce auditable records.

Developers will also care whether streaming output, structured responses, function calling, batch processing, caching, rate limiting, retries, and observability follow consistent standards. If the platform only standardizes the domain name and API key, but not error codes, capability fields, and version management, the integration burden will remain on the application side.

Numerous unified API aggregation services already exist on the market, including platforms that use OpenAI-compatible formats and allow multiple providers’ models to be called through a single key. Services such as OpenAI Hub address cross-model access and connectivity within China. The Jiaxing operations center adds another layer as regional public infrastructure by incorporating local computing resources, industrial policies, security auditing, and enterprise settlement into the same system. Both aggregate models on the surface, but their core objectives are not entirely the same.

The Real Test Begins After the Portal Goes Live

The most commendable aspect of Jiaxing’s launch is that it does not view the AI industry simply as building more computing centers. Instead, it begins to address how computing power reaches enterprises, how model calls are metered, how subsidies are deducted, and how security responsibilities are audited. This is much closer to the actual problems enterprises face when deploying AI than merely announcing the addition of more GPUs.

However, the platform still has a long way to go before it can become a “computing power circulation hub for the Yangtze River Delta.” More than 100 models are merely products on a shelf, and automatic routing is merely a shopping assistant. Whether enterprises are willing to procure services over the long term will ultimately depend on whether those services are stable, prices are transparent, data is secure, and responsibility can be clearly assigned when problems occur.

For Jiaxing, the best outcome is not to direct every enterprise toward the same model, but to enable manufacturing enterprises of different sizes to find suitable model and computing solutions at a lower cost of experimentation. If unified metering, policy-based deductions, and security auditing are truly implemented, the operations center will become a valuable experiment in regional AI infrastructure. If all that remains is a model showcase portal, the “Token economy” will still be little more than a fashionable industrial label.

As of August 2, the platform has not published its complete model catalog, API protocols, detailed pricing, routing evaluation methodology, or SLA standards. This is the information developers and enterprises need most to determine whether it is suitable for production environments.

References

In accordance with the specified domain-retention rules, the domains hosting the original reports are not eligible for inclusion. The following list therefore provides only source names and content descriptions, without hyperlinks.

• Xinhua Net Zhejiang: “Yangtze River Delta (Jiaxing) Token Operations Center Launches to Seize Opportunities in the Token Economy,” disclosing the launch date, five unified capabilities, industrial positioning, computing infrastructure, and initial ecosystem partners.
• People’s Daily Online Zhejiang: “Yangtze River Delta (Jiaxing) Token Operations Center Officially Launches,” introducing access to more than 100 models, automatic model selection, service packages, and Jiaxing’s computing resources.
• 36Kr News Flash: “Yangtze River Delta (Jiaxing) Token Operations Center Officially Launches,” summarizing the portal launch, one-time integration for access to more than 100 models, and other key information.
• Related reports from Zhejiang Release: providing information on the platform’s service model, task routing, and the local industrial landscape.