Balance Management & Quota Allocation
Applies to: Organization (top-level user) Updated: 2026-07-02
This article is the "master guide" to the funds system of the new CloudRouter console, making two things clear: how to manage the organization balance pool, and how to set quota limits for subusers.
⚠️ Important conceptual change: the new version no longer has a "member personal wallet." The organization balance pool is the single source of funds; what you set for a subuser is a quota limit (allowance), not a handout of money. Once you grasp this, all the operations below fall into place.
For top-ups (adding money to the balance pool), see Top-up & Redemption Codes; for usage and billing, see Billing & Usage Monitoring.
1. Core Concept: One Pool, Multiple Quota Limits
The new console uses a two-part funds model of "organization balance pool + subuser quota limits":
- Funds from top-ups (online / redemption code) enter the organization balance pool, which is the single source of funds for the entire organization
- The organization can set a quota limit for each subuser under it, capping that subuser's consumption (e.g., subuser A has a limit of 200, subuser B has a limit of 500)
- When a subuser calls a model, what is actually deducted is always the balance of the organization balance pool, not the subuser's own wallet — the quota limit is only a cap valve for "how much it can spend at most"
| Concept | What it is | What it is not |
|---|---|---|
| Organization balance pool | The single source of funds for the entire organization; both the organization's own and all subusers' consumption are deducted from here | Not a collection of multiple wallets |
| Subuser quota limit | A consumption cap (allowance) set for a subuser, controlling "how much it can spend at most" | Not an independent wallet, not "handing money over to it" |
| Actual deduction | When a subuser calls a model, what is deducted is always the balance of the organization balance pool | Not deducting the subuser wallet first, then the organization pool |
One sentence to remember: quota is the "cap valve," and the balance pool is the "single fuel tank." Setting a quota for a subuser means specifying how much fuel it can draw from the tank at most, rather than splitting fuel into its own little tank.
Differences from the Legacy Console (Important)
The legacy console (v1) talks about allocating credits from the organization balance pool to a member's personal balance, from which the member's consumption is deducted. The new version (v2) no longer does this:
| Dimension | Legacy v1 (member personal balance) | New v2 (subuser quota limit) |
|---|---|---|
| What a member/subuser gets | A sum of money transferred over (personal wallet) | A consumption cap (allowance) |
| Whose balance is deducted on consumption | The member's personal balance | The organization balance pool |
| Organization pool change when setting quota | Immediately deducted from the organization pool | Not deducted, only a cap is set |
| Multiple Keys | — | Multiple Keys under a subuser share the same quota limit |
If you migrated from the legacy console, do not keep thinking in terms of "splitting money to members." The new version is "cap quota + actual deduction from the organization balance."
2. Who Can Do What
✅ Can operate ｜ ❌ No permission ｜ 🔸 Limited to this organization's scope
| Capability | Organization | Subuser |
|---|---|---|
| Top up the organization balance pool (online / redemption code) | ✅ 🔸 | ❌ |
| Set / adjust subuser quota limits | ✅ 🔸 | ❌ |
| Reclaim / reset subuser quotas | ✅ 🔸 | ❌ |
| View organization balance and transactions | ✅ 🔸 | ❌ |
| View own quota (read-only) | — | ✅ 🔸 |
On the "API Keys" page, a subuser has a read-only quota card at the top, which shows its own quota usage but cannot modify it. For the full role boundaries, see Roles & Permissions Matrix.
3. Viewing Organization Balance and Transactions
Go to the Balance Management page (left navigation bar after the organization logs in) to view:
- The current organization balance, along with entries for top-up, refresh, and other operations
- The full record of balance changes
Balance Transaction Type Reference
| Type | Direction | Description |
|---|---|---|
| Purchase | + organization pool | Credited via online payment on the "Purchase" page |
| Redemption code | + organization pool | Credited via redemption on the "Redemption Code" page |
| Top-up | + organization pool | The platform tops up the organization directly |
| Promo code | + organization pool | Credited via a promo code (e.g., a registration bonus) |
| Consumption | - organization pool | Deduction from the organization's own or a subuser's model calls |
| Refund | - organization pool | Deduction from a refund operation |
Each transaction typically includes: time, type, amount, description, related user, operator, balance before change, and balance after change, which can serve as an audit basis.
Note: In the new version, subuser consumption deducts the organization balance pool directly, so a "consumption" transaction reflects a decrease in the organization pool. The legacy version's "allocation (organization pool → member) / reclamation (member → organization pool)" fund-transfer transactions are no longer generated in the new version — setting a quota for a subuser does not generate a fund-transfer record.
4. Setting / Adjusting a Subuser's Quota Limit
Setting a subuser's quota is done on the Subuser Management page (it does not transfer money away, but sets a cap value).
Steps
- Left navigation bar → Subuser Management
- Find the target subuser and go to its edit / quota-setting entry
- Set the quota limit: enter the maximum amount that subuser can consume
- Takes effect immediately after saving
The specific field names (such as "quota limit" or "allowance") and whether periodic quotas are supported follow the actual console interface. For the full operations of creating, disabling, and setting the business identity of subusers, see Subuser Management.
Key Rules
- Setting a quota does not deduct the organization pool: setting a quota merely specifies the subuser's consumption cap; the organization balance pool is not reduced as a result
- Sharing the same quota limit: multiple Keys under the same subuser share its quota limit, rather than each Key having its own quota
- Actual deduction from the organization balance: every subuser call actually deducts the organization balance pool; the quota limit only determines "how much it can still spend cumulatively"
- Quota can be adjusted anytime: raising or lowering it takes effect immediately; if lowered below the already-consumed value, that subuser will be unable to continue calling
- The organization's own consumption is not constrained by quota: quota is for subusers; the Organization's (top-level user's) own calls go directly through the organization balance pool
5. What Happens When a Subuser's Quota Is Exhausted / Balance Is Insufficient
These are two different "ran out" scenarios, with different manifestations:
| Scenario | Trigger condition | Manifestation |
|---|---|---|
| Subuser quota exhausted | A subuser's cumulative consumption reaches its quota limit | All Keys under that subuser are rejected together; other subusers in the organization are unaffected |
| Organization balance pool insufficient | The organization balance pool has insufficient balance to pay for this call | Calls across the whole organization are affected; the API returns HTTP 403 (balance-related; the exact error code follows what the API actually returns) |
⚠️ Subuser quota exhaustion takes effect per subuser, not per single Key — because multiple Keys share the same quota limit, once the quota is used up, all of that subuser's Keys are rejected. To recover, simply raise its quota limit (provided the organization pool still has balance).
To restrict a specific subuser's calls, there are two ways:
- Lower / exhaust its quota limit: all Keys under it are rejected together
- Disable the subuser account: see Subuser Management
6. Reclaiming / Adjusting Quotas
The new version does not have the legacy "reclaim money from the member wallet back to the organization pool" fund-reclamation action — because the money was in the organization pool all along. In the new version, "reclamation" is essentially adjusting the subuser's quota limit:
| Your goal | New-version approach |
|---|---|
| Stop a subuser from spending more | Lower or reset its quota limit (all Keys under it are immediately rejected) |
| Subuser departure / disabling | Disable the subuser account; its historical usage is aggregated to its organization |
| Temporarily tighten the budget | Lower the quota limits of the relevant subusers uniformly |
- Adjusting the quota limit takes effect immediately and involves no organization-pool fund transfer
- After a subuser is deleted, its historical usage is aggregated to its organization and is no longer retained separately at the user level
7. Typical Funds Operations Flows
New team startup
Top up the organization balance pool → Create subusers → Set quota limits individually (e.g., 200 each) → Create Keys → Subusers start callingControlling a subuser's spending
Subuser Management → Lower its quota limit → All Keys under it are rejected at the quota-exhaustion pointSubuser departure
Subuser Management → Disable / delete the subuser → Its historical usage is aggregated to the organization → The organization pool balance is unaffectedMonthly reconciliation / invoicing
Check transactions in Balance Management → Download receipts in My Orders → Apply for an invoice via the Feishu form (see "Invoices & Receipts")8. FAQ
Q: Does setting a quota for a subuser deduct money from the organization balance pool?
A: No. Setting a quota merely sets a consumption cap; the organization pool balance is unchanged. Only when the subuser actually calls a model is it deducted from the organization pool.
Q: Do subusers have their own wallet/balance?
A: No. In the new version, a subuser has no independent wallet, only a "quota limit." It can see its own quota usage (a read-only card), but all consumption deducts the organization balance pool.
Q: For multiple Keys under a subuser, is the quota counted per Key or combined?
A: Combined. Multiple Keys of the same subuser share the same quota limit, and their cumulative consumption is counted together against its quota limit.
Q: Can the sum of all subusers' quota limits exceed the organization balance?
A: Yes. A quota limit is a "cap valve," not pre-deducted funds, so the sum of subusers' quotas is allowed to exceed the organization balance (like "credit without pre-holding"). But actual deduction comes from the organization pool — once the organization pool is exhausted, it returns HTTP 403 (balance-related) and everyone is affected. Set quotas reasonably according to your actual budget.
Q: A subuser's quota is exhausted — how do I restore its calls?
A: On the Subuser Management page, simply raise its quota limit, provided the organization balance pool still has balance.
Q: I want to "reclaim" the quota allocated to a subuser — how do I do that?
A: The new version has no concept of fund reclamation. You just lower or reset its quota limit on the Subuser Management page — the money has been in the organization pool all along and never left.
Q: When the organization itself calls a model, is it constrained by the quota limit?
A: No. Quota limits are set for subusers; the Organization's (top-level user's) own calls go directly through the organization balance pool.
Q: Can the platform top up my organization directly?
A: Yes. The platform can top up the organization balance pool directly (shown as a "Top-up" type in the transactions); contact CloudRouter if needed. But setting quotas for subusers is usually done by you as the organization.
9. Notes
- The organization balance pool is the single source of funds; subusers have no independent wallet
- Setting a quota for a subuser sets a consumption cap; it does not deduct the organization pool or transfer funds
- Multiple Keys of a subuser share the same quota limit; when the quota is exhausted, all Keys under it are rejected together
- Actual deduction is always from the organization balance pool; when the organization pool is insufficient, calls return HTTP
403(balance-related; the exact error code follows what the API actually returns) - Raising the organization-level concurrency limit, adjusting the available model scope, etc. require contacting CloudRouter — see Roles & Permissions Matrix
- All balance changes are traced in the transactions and can serve as an audit basis
Contact Us
- Email: support_cloudrouter@clouditera.com
- QQ community: 712273971
- Website: cloudrouter.online