CloudRouter 文档

English

简体中文

English

简体中文

Appearance

Migration & Transition Notes ​

Applies to: Organization (top-level user), Subuser Updated: 2026-07-02

If you already have an account in the legacy console, this article helps you understand: what your account has become, whether your balance is still there, whether your old Keys still work, and whether you need to change how you make calls.

1. The Three Things You Care About Most ​

Your questionConclusion
What did my account become?The legacy "tenant/account" is promoted to an Organization (top-level user), with stronger capabilities and no need to re-register
Is my balance still there?Yes. The balance is kept intact at the Organization (former account) tier
Do my old API Keys still work?Yes. Old Keys remain valid, and calls are uninterrupted

In one sentence: this is a smooth semantic upgrade, not a data migration — your account, balance, and Keys all stay in place.

2. Changes to the Account Hierarchy ​

The new version introduces a three-tier account hierarchy, similar to AWS's Account → IAM User → Access Key hierarchy:

LegacyNewAWS analogyDescription
Tenant / accountOrganization (top-level user)AWS AccountThe name changed, the account entity is unchanged, and the balance is kept
Tenant adminThe Organization itselfAccount OwnerWhat you log into is the organization account
Regular memberSubuserIAM UserAn independent identity under the organization, with an account name, email, and other business info
API KeyAPI Key under a subuser / organizationAccess KeyA Key belongs to a specific subuser (or the organization itself) and is used for API call authentication

In simple terms: each of your legacy Keys now clearly belongs to one subuser (or the organization itself), just as an AWS Access Key belongs to an IAM User. The Key itself hasn't changed (its format, usage, and bound group all stay the same); at the management level there's just an extra layer of "whose Key this is" — the organization can see which Keys each subuser has and how much quota they've used.

Old Keys are automatically attributed to the organization; you don't need to do anything. If you previously created different Keys for different members, those Keys can still be viewed by person in Subuser Management.

For the detailed three-tier relationship, see Three-Tier Account Hierarchy.

3. Calling Method: Old Keys Need No Changes ​

The new version introduces "fingerprinted call names" (such as 5MHXZWKA/gpt-4o), but the old calling method remains compatible:

Your call nameRouting behavior
Bare model name (such as gpt-4o)Routes through the routing group bound to your Key — same as the legacy version
With fingerprint (such as 5MHXZWKA/gpt-4o)Routes to a named group by fingerprint — the new method, more flexible
  • Zero changes for old clients and old scripts: Keep using bare model names, and behavior is unchanged.
  • Want to use the new method: Go to the "Call Guide" and copy the fingerprinted call name. Both methods can coexist; use whichever you need.

For a detailed explanation of calling methods, see Developer Guide · Call Guide & Dual Routing.

4. A Few Experience Points That Change ​

4.1 Creating a Key Still Means "Binding One Group" ​

In the new version, each Key is bound to one routing group, and bare-model-name calls route through that group — the same experience as the legacy "one group per Key." Existing old Keys still work under their originally bound group and are unaffected. There is also an advanced "dispatch group allowlist" (configurable by the organization only) used to constrain fingerprinted/named calls. See API Keys & Routing Groups.

4.2 Members Are Automatically Promoted to "Subusers" ​

Legacy members are automatically promoted to subusers in the new version, with no manual rebuild needed:

  • Old members' login method is unchanged (still log in with their original email + password), with no re-activation needed
  • The new version adds business identity information (account name, email, notes) for subusers, which the organization can edit and fill in on the "Subuser Management" page
  • Keys under old members are automatically attributed to the corresponding subusers, with no re-distribution needed

Only newly created subusers need to register via an activation code. Existing old members are promoted smoothly.

4.3 "Model Group" Is Uniformly Renamed to "Group" ​

The legacy "model group" is uniformly called a group in the new version:

  • Legacy model groups' names and configurations stay unchanged — only the term changes from "model group" to "group"
  • The group bound to a Key automatically corresponds, and old Keys still work under their originally bound group (i.e., the legacy model group)
  • Management and maintenance of new-version groups are handled centrally by the platform

4.4 Subusers Can Self-Serve Create Keys ​

Subusers can self-serve create Keys on the "API Keys" page, with routing groups selectable only within the organization's authorized scope; the organization can also create and distribute them on their behalf. All Keys under a subuser share the same quota limit and deduct from the organization balance. See Subuser Management.

4.5 Available Model Scope Is Configured Per Organization by the Platform ​

Which groups/models are available is set per organization by the platform. If you find that certain models are unusable, it's most likely they're not within your organization's available scope — contact CloudRouter to adjust, see Region & Model Scope.

5. Notes During the Migration Period ​

  • Smooth phased rollout: The new hierarchy supports phased rollout — during migration, old data follows native logic while new capabilities open up gradually, and calls are uninterrupted.
  • Don't panic over anomalies: If, after logging in, you find the menus and account names differ from before, you've most likely been switched to the new version — just understand it per this handbook. Contact support for balance or call anomalies.
  • Keep your orders and receipts: Historical orders and payment receipts can be viewed and downloaded in "My Orders," see Invoices & Receipts.

6. FAQ ​

Q: Do I need to re-register my account? A: No. Your old account is automatically promoted to an organization — just log in directly.

Q: Will my balance be lost during migration? A: No. The balance is kept at the Organization (former account) tier; the migration involves no funds transfer.

Q: My scripts still use model names like gpt-4o — do I need to change them? A: No. Bare model names still route through the routing group bound to your Key, with behavior identical to the legacy version.

Q: How do I choose a group when creating a Key in the new version? A: Same as the legacy version — just bind one routing group to the Key. Old Keys are unaffected; for configuring new Keys, see API Keys & Routing Groups.

Q: Where did my original team members go? A: They become "subusers" under your organization, viewable and manageable in "Subuser Management."

Contact Us ​