AI Gateway Service Architecture Upgrade Announcement
Upgrade Schedule:
- Singapore environment: August 10, 20:00
- Shanghai environment: August 11, 20:00
Upgrade Announcement
Dear Users,
The core of this upgrade is a unified restructuring of the platform's existing model supply channels. After the upgrade, you no longer need to pay attention to specific model providers or channel names. The platform will categorize model services into three tiers based on service quality and use case:
| Tier | Recommended Display Name | Recommended Description |
|---|---|---|
| Economy Tier | Economy Tier | Price First | Uses the platform's most cost-effective supply. Prioritizes low-cost usage. Suitable for model validation, development testing, batch processing, and other scenarios that are price-sensitive and have relatively low service guarantee requirements. |
| Standard Tier | Standard Tier | Balanced Supply | Uses the platform's aggregated multi-channel supply, balancing call cost, availability, and service stability. The platform performs unified scheduling based on channel conditions. Suitable for most everyday business workloads. |
| Premium Tier | Premium Tier | Official and First-Party Channels | Prioritizes the model's original vendor or vendor-authorized cloud service channels. Focuses on model capability consistency, service stability, and call quality. Suitable for production environments, core business, and scenarios with high stability requirements. |
Why This Upgrade
Currently, different models may be provided by multiple providers, requiring customers to understand providers, channels, and routing policies — resulting in high configuration and maintenance overhead. When a provider changes, it may also require simultaneous updates to API keys or call configurations.
After the upgrade, the platform will manage underlying supply channels centrally. You only need to choose a service tier based on your business's cost and service quality requirements, without needing to know which specific provider is serving the request.
This upgrade brings the following key changes:
- Simpler usage: No need to select or maintain specific model providers.
- Clearer cost and quality: Different business workloads can explicitly use different service tiers.
- Smoother underlying channel adjustments: Provider additions, switches, or maintenance typically require no changes on the client side.
- Business isolation: Test, batch processing, and production workloads can use API keys for different tiers, avoiding mixing of different service quality levels.
API Key Usage Changes
Before the upgrade, a single API key might carry traffic across different models, different supply channels, and different quality requirements.
After the upgrade, each API key will be fixed to a single service tier.
For example:
api-key-economy: For testing, internal tools, or cost-sensitive workloads.api-key-standard: For regular online business.api-key-premium: For core production workloads.
An API key is not limited to a single model, but it can only call models currently supported by its assigned tier. You cannot temporarily switch to a different service tier within a single call.
If you need to use multiple service tiers simultaneously, you need to create separate API keys for each tier and use different keys for different workloads.
Models and Pricing
Model call endpoints, request protocols, and model identifiers remain unchanged. This upgrade primarily affects the mapping between API keys and service tiers.
- Models with configured protocol discounts are billed at the protocol price for the corresponding tier.
- Models without configured protocol discounts remain usable and are billed at the model's List Price.
- The Model Market and Model Details Page will display pricing information for each service tier.
- If a tier temporarily cannot serve the target model, the call will fail directly and will not automatically switch to another tier, preventing unexpected charges.
Preparation Required Before the Upgrade
If you currently use a single API key to call all models, we recommend completing the following checks before the upgrade:
- Identify which applications, environments, and models are currently using your API key.
- Determine the service tier required for each business use case.
- Create separate API keys for each service tier.
- Update the new API keys in the environment variables or secret management systems of the corresponding applications.
- Complete call testing before the official switch.
If all your business workloads only require a single service tier, you only need to confirm the tier for your existing API key — no need to split into multiple keys.