How many groups can one key use?

Up to 5, in priority order, the first one highest. On the API keys page of the console, create or edit a key and set its group mode to "Several groups · auto switch".

How is a request priced when it moves to a later group?

Every request is billed at the group that actually served it, that is the model's standard price times that group's multiplier. If a later group costs more, requests that land there are charged at its price, so give the key a spending cap.

Do several groups help without cross-group retry?

Yes, in one case only. When an earlier group does not offer the model, the request goes straight to the next group that does. When an earlier group offers the model but the request fails, it does not move to another group and you get the error.

How do I see which group served a request?

Open Logs in the console. The Group column of each usage record is the group that actually served the request, and you can filter by group to see how much traffic each one carried.

Can a request choose its group?

No. Only the key's settings decide the group. If you need a different combination of groups, create another key.

LLM API high availability: one key, several groups, automatic failover

The same model is usually offered in several groups, and each group is a separate line. High availability means giving one key several groups: in the console, set the key's group mode to "Several groups · auto switch", put up to 5 groups in priority order, and turn on cross-group retry. From then on, each request uses the first group in the order that offers the model; if that group fails and its retry fails too, the platform moves the same request to the next group. Every request is billed at the group that served it, and Logs show which group that was.

How switching works

Each request goes through three steps:

Pick a group: walk the key's groups in order and use the first one that offers the model. Groups that do not offer it are skipped.
Price it: the request is billed at the group that serves it — the model's standard price × that group's multiplier.
Retry on errors: for a retryable error, the platform first retries once in the same group. With cross-group retry on, if the retry fails as well, the request moves to the next group, which also gets up to two attempts, until the list runs out. Without it, the error is returned to you.

What happens in each case:

Situation	Cross-group retry off	Cross-group retry on
An earlier group does not offer the model	The next group that offers it is used	Same
The line returns 429, most 5xx errors, or the connection fails	One retry in the same group, then the error is returned	One retry in the same group, then the next group
A request error such as 400, or a 504 gateway timeout from the line	No retry; returned as is	Same
Account or key refusals: insufficient balance, expired key, IP or model not allowed	Returned directly; another group would not help	Same
None of the groups offers the model	503 with the code `model_not_found`	Same

A retry inside a group uses that group's line again, which absorbs the occasional hiccup. When a line keeps failing, cross-group retry is what moves the traffic elsewhere.

Ordering the groups

The first group carries almost all of the traffic, so pick it for what matters most to you; the others are backups, and requests that land on them are billed at their prices. Check how much the same model costs in each group first:

Group	Input ¥/1M	Output ¥/1M	Cache read ¥/1M
Standard	¥4	¥20	¥0.4
Official · Enterprise	¥21.9	¥109.5	¥2.19
Claude Direct	¥15	¥75	¥1.5
Claude List Price	¥24	¥120	¥2.4
Claude Plus	¥8	¥40	¥0.8
Claude LiteLowest	¥3.2	¥16	¥0.32

Claude Sonnet 5.5 · Prices in CNY, cheapest group for each model; updated Nov 13, 2026, 1:33 AM.

Three common orders:

Goal	Order	Keep in mind
Stability and sourcing first	Groups labeled Official or Cloud first; a cheap group with broad model coverage last as the fallback	Normal traffic is billed at the first group's price; fallback requests at the fallback group's price
Cost first	Groups labeled Lowest price first; an official group after them as the backup	Requests only move to the pricier backup when the cheap group fails, and those are billed at the backup's price
One key for several vendors' models	Add the official group of each vendor	Each request lands on the first group that offers its model, so each vendor's models go to their own group

Group labels and descriptions are in Choosing a group; the groups that offer a model are listed on its page in Models and pricing.

Setting it up in the console

Open API keys in the console and choose Add key, or edit an existing key.
Under Key group, set the group mode to "Several groups · auto switch".
In Auto group order, add groups and move them up or down; the first has the highest priority, up to 5 in total. The ×1, ×0.8 next to a group is its price multiplier — lower is cheaper.
Turn on Cross-group retry.
Give the key a spending cap, and model limits or an IP allowlist if you need them.
Save. The change takes effect immediately; your code does not change.

If you add no groups, the key follows the site's default order. The default order currently has a single group, so it cannot fail over. Add your own groups and order them.

In the key list, such a key shows as Auto followed by its numbered groups; hover over it to see whether cross-group retry is on.

Checking which group served a request

Logs: the Group column of each usage record is the group that actually served the request, never "Auto". Filter by API key name and group to see how many requests and how much spend each group took.
Dashboard: the Keys and groups card sums spend by key, group and model, so you can see the share of the main and backup groups at a glance.
The models endpoint: GET /v1/models with this key returns every model offered by any of its groups; with model limits on, only the allowed ones.

Before going live

Call the models endpoint with the key and confirm every model you need is listed.
Open Status to see the 24-hour success rate and latency of popular models on each group's line, and use it to order your groups; for other models, see the Availability tab on the model's page.
Send a batch of real requests and confirm the groups and charges in Logs.

What your client still needs

Platform failover deals with a failing line; your client still needs its own timeouts and retries:

Do not set timeouts too short. Moving between groups takes time, and a client that gives up first wastes the failover.
Retry 429 and 5xx errors with backoff, as shown in Errors and retries.
If a streaming response breaks after output has started, your client has to detect it and resend; see the section on streaming errors in Errors and retries.

When to use separate keys instead

A multi-group key switches by fixed rules. In these cases, two keys in different groups with the switch in your own code fit better — and you can combine both approaches:

Need	Why separate keys
Separate spending caps and separate bills for primary and backup	Caps are per key; the groups of one key share a single cap
Switch models too, for example fall back to a cheaper model	Platform failover changes the group, not the model
Fail over on 504 gateway timeouts or client timeouts	The platform does not change groups for those errors
Different model limits or IP allowlists for primary and backup	Those settings belong to the key; one key has one set

Example code for failover with two keys is in How to choose a group. How to split keys by project and environment across a team is covered in Teams and multiple projects on one account.