Migration and Transition Notes
Applicable roles: Organization (top-level user), Sub-user Updated: 2026-07-14
If you already have an account on the legacy console, this document helps you understand: what your account has become, whether your balance is still there, whether your original Keys still work, and whether you need to change how you make calls.
1. The Three Things You Care About Most
| Your question | Answer |
|---|---|
| What has my account become? | The legacy "tenant/account" has been upgraded to an Organization (top-level user), with expanded capabilities and no need to re-register |
| Is my balance still there? | Yes. The balance is preserved as-is at the Organization (original account) level |
| Do my original API Keys still work? | Yes. Legacy Keys remain valid, and calls are not interrupted |
In one sentence: this is a smooth semantic upgrade, not a data migration. Your account, balance, and Keys all remain where they were.
Login page:
2. Changes to the Account Hierarchy
The new version introduces a three-tier account system, similar to AWS's Account → IAM User → Access Key hierarchy:
| Legacy | New | AWS analogy | Description |
|---|---|---|---|
| Tenant / Account | Organization (top-level user) | AWS Account | The name changed, but the account entity is unchanged and the balance is preserved |
| Tenant admin | The Organization itself | Account Owner | What you log in as is the Organization account |
| Regular member | Sub-user | IAM User | An independent identity under the Organization, with business information such as a username and delivery email |
| API Key | API Key under a sub-user / the Organization | Access Key | The Key belongs to a specific sub-user (or the Organization itself) and is used for API call authentication |
The simple way to understand it: each legacy Key now explicitly belongs to a sub-user (or the Organization itself), just as an AWS Access Key belongs to a specific IAM User. The Key itself hasn't changed (its format, usage, and bound group all stay the same); there is just an added management-level "who owns this Key" relationship—the Organization can see which Keys exist under each sub-user and how much quota they've used.
Legacy Keys are automatically assigned to the Organization, and you don't need to do anything. If you previously created different Keys for different members, these Keys can still be viewed per person in sub-user management.
For the detailed account system, see Account System Overview.
3. How to Make Calls: No Changes Needed for Legacy Keys
The new version introduces a "group-identifier call name" (e.g., 5MHXZWKA/gpt-4o), but the legacy way of making calls remains compatible:
| Your call name | Routing behavior |
|---|---|
Model name (e.g., gpt-4o) |
Routes through the group bound to your Key—same as the legacy version |
With a group identifier (e.g., 5MHXZWKA/gpt-4o) |
Routes to the group named by the group identifier—the new, more flexible approach (requires enabling group-identifier routing) |
- Zero changes for legacy clients and scripts: just keep using the model name, and the behavior stays the same.
- Want to use the new approach: if the Organization has enabled group-identifier routing, you can copy the call name with the group identifier on the "Call Guide" page. When it's not enabled, the Call Guide page also shows the model name.
For details on making calls, see Developer Guide · Call Guide and Routing Overview.
4. A Few Experience Points That Change
4.1 Optional Group Binding When Creating a Key
In the new version, each Key can optionally bind to one routing group, and model-name calls route through that group—consistent with the legacy "one group per Key" experience. When no group is bound, model-name calls follow the default routing configuration. Existing legacy Keys still work according to their originally bound group and are unaffected. There is also a default routing configuration (specifying which group a model name routes to) and an advanced "scheduling group allowlist" (configurable once group-identifier routing is enabled). See API Keys and Routing Groups for details.
4.2 Members Are Automatically Upgraded to "Sub-users"
Legacy members are automatically upgraded to sub-users in the new version, with no need to rebuild them manually:
- Legacy members' login method is unchanged (they still log in with their original email + password), with no need to reactivate
- The new version adds business identity information for sub-users (username, delivery email), which the Organization can edit and supplement on the "Sub-user Management" page
- Keys under legacy members are automatically assigned to the corresponding sub-users, with no need to redistribute them
Only newly created sub-users need to register via an activation code. Existing legacy members are upgraded smoothly.
4.3 "Model Groups" Are Renamed to "Groups"
The legacy "model group" is uniformly called a group in the new version:
- The legacy model group's name and configuration remain unchanged; only the term changes from "model group" to "group"
- The group bound to a Key is automatically mapped, and legacy Keys still work according to their originally bound group (i.e., the legacy model group)
- Management and maintenance of groups in the new version are handled uniformly by the platform
4.4 Sub-users Can Create Keys Themselves
Sub-users can create Keys themselves on the "API Keys" page, and routing groups can only be selected within the range authorized by the Organization; the Organization can also create and distribute Keys on their behalf. All Keys under a sub-user share the same quota cap and deduct from the Organization's balance. See Sub-user Management for details.
4.5 The Range of Available Models 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 can't be used, it's most likely because they are not within your Organization's available range; contact the platform to adjust it. See Regions and Model Ranges.
5. Notes for the Migration Period
- Smooth gradual rollout: the new system supports gradual rollout. During migration, legacy data follows the original logic and new capabilities are opened up progressively, with no interruption to calls.
- Don't panic if you encounter anomalies: if you notice that the menus and account names look different after logging in, it's most likely that you've been switched to the new version—just follow this manual to understand it; contact support for balance or call anomalies.
- Keep your orders and receipts: historical orders and payment receipts can be viewed and downloaded in "Balance Management." See Invoices and Receipts.
6. FAQ
Q: Do I need to re-register an account? A: No. Your legacy account is automatically upgraded to an Organization—just log in directly.
Q: Will my balance be lost during migration? A: No. The balance is preserved at the Organization (original account) level, and the migration does not involve moving funds.
Q: My scripts still use model names like gpt-4o—do I need to change them?
A: No changes needed. The model name continues to route through the group bound to your Key, and the behavior is the same as 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 a routing group to the Key. Legacy Keys are unaffected; for the configuration of new Keys, see API Keys and Routing Groups.
Q: Where did my original team members go? A: They become "sub-users" under your Organization, and you can view and manage them in "Sub-user Management."