Skip to main content
Set spending limits for individual users in your account on serverless (per-token) inference. You can change the account-wide default cap, cap everyone in a group at a shared amount with a group limit, and override the limit for specific users.
Per-user usage limits are available on request. Reach out to your Fireworks contact to enable them for your account. Group limits additionally require groups to be enabled and your directory connected through SCIM group sync.

Concepts

  • Account default cap — the per-user limit applied to anyone with no override and no group cap. Nexus accounts start at $100.
  • Group limit — a named, reusable cap you define once and assign to one or more groups. The User Limits page calls these limit options.
  • Per-user override — a cap set on one specific user.
  • Effective limit — the limit actually applied to a user, resolved by the precedence below.
  • Current-period usage — how much a user (and the account overall) has spent in the current billing period.
All amounts are in USD, and usage resets at the start of each billing period.

Limit precedence

A user’s effective limit is resolved in this order:
  1. Their per-user override, if they have one.
  2. Otherwise, the highest cap among the group limits assigned to their groups. A group limit below the account default still wins: a group cap replaces the default rather than competing with it.
  3. Otherwise, the account default cap.
A user with no override, no group limit, and no account default has no cap. Use a per-user override when someone needs a cap their group membership won’t produce.

How to

These tasks are done by account admins on the User Limits page under Settings.

Set a group’s limit

Assign a limit option to a group, creating one first if you need it.
  1. Open the Groups tab.
  2. Click the limit dropdown on the group’s row.
  3. Pick an existing limit option, or choose + New limit to create one.
The limit applies to each member individually — it is not a shared budget for the group.

Edit a limit option

Change the amount on a limit option.
  1. Open the Groups tab.
  2. Edit the limit option’s amount.
Every group assigned to that option moves to the new amount.

Delete a limit option

Remove a limit option you no longer need.
  1. Open the Groups tab.
  2. Delete the limit option.
Groups assigned to it fall back to the org default automatically. Only the User Limits page does this — firectl and the REST API reject the delete instead. User overrides are unaffected.

Override a specific user’s limit

Give one user a cap of their own.
  1. Open the Usage tab and select the user.
  2. Set a custom limit.
The override takes precedence over the user’s group limit and the account default.

Group limits

A group limit is a reusable spending cap. Create a few amounts, assign one to each group. It caps every member individually, not the group as a whole, so on a $500 limit, each member can spend up to $500, not $500 shared. (firectl and the REST API call this resource a group usage limit tier.)

Where groups come from

Groups come from your identity provider through SCIM group sync — that is the only way to create one. Groups and their membership are read-only in Fireworks; add, rename, delete, and populate them in your directory. The limit assignment is the one part you set in Fireworks.

Rules and limits

  • An account may define at most 9 group limits. The User Limits page counts these against a total of 10, because the org default occupies one of the slots.
  • Each group limit must hold a distinct amount. Creating or updating one to an amount another already holds is rejected. A group limit may equal the account default.
  • Amounts are USD and non-negative. A $0 group limit is a real cap — its members are blocked from serverless spend immediately.
  • A group limit sets an amount only. Reaching any cap blocks the user, so someone in several groups has one unambiguous outcome.
  • An unassigned group contributes no cap; its members fall back to another of their groups or to the account default.
  • Deleting a group limit that groups are still assigned to is rejected by firectl and the REST API — clear those assignments first. On the User Limits page, deleting a limit option reassigns its groups to the org default for you.

Supported models

Per-user metering applies to all serverless models except MiniMax M2.7. Usage on MiniMax M2.7 does not count toward a user’s limit and won’t trigger blocking.

Who can do what

  • Account admins — view and manage everything: update the default cap, define and assign group limits, set/clear per-user overrides, and view every user’s usage.
  • Members (non-admin) — view the account-level limits, every group’s limit assignment and the group limits themselves, and their own usage and limit. Members cannot view other users’ limits, list all users, or change any limits.
Each command below is annotated with who can run it.

On the User Limits page

Account admins manage limits on the User Limits page under Settings. Members see their own usage and limit there, and can request an increase. The page has three tabs — Groups appears once group limits are enabled for your account:
  • Usage — every user’s current-period spend against their effective limit, with the source of that limit and, for a group-derived cap, which group it came from.
  • Groups — each group with its assigned limit option and member count. Choose Org default on a group’s row to clear its assignment and fall back to the account default.
  • Increase Request — pending per-user increase requests to approve or reject.
Group rows show a SCIM-synced source and the time of the last directory sync. Membership changes belong in your identity provider; only the limit assignment is editable here.

Using firectl

Account-level

Defining group limits

Group assignments

Every command takes either a bare ID or a full resource name, so firectl usage-limits group set accounts/my-account/groups/platform-team --group-usage-limit-tier=accounts/my-account/groupUsageLimitTiers/contractors is equivalent to the short form above.

Per-user

A user record shows:
  • used — current-period spend
  • effective_limit — the limit applied to them, per the precedence rules
  • limit_source — which rule produced it: USER_OVERRIDE, GROUP_ASSIGNMENT, or ACCOUNT_DEFAULT
  • limit_groups — for a group-derived cap, the groups sitting at that amount (several groups can share one cap)
  • override — their per-user override, if any
  • exceeded_until — set only when the user is currently blocked; shows when the block lifts (the end of the current billing period)
An override wins outright, so it is also how you lower a single user below their group’s limit. Unsetting it resolves the user to their group cap if they have one and the account default otherwise; the account-wide default itself cannot be cleared.

Using the REST API

Writes are PATCH (or POST to create a group limit). The examples below pass updateMask explicitly, using the proto field names; if you omit it, the mask is derived from the fields present in your request body.

Read

Define a group limit (admin only)

Amounts use google.type.Money: currencyCode must be USD, and units is whole dollars.

Assign a group limit to a group (admin only)

Assigning and clearing are both updates of the group’s usage-limits singleton — there is no create or delete.

Other updates (admin only)

  • PATCH /v1/accounts/<ACCOUNT_ID>/usageLimits — update default_user_limit (cannot be cleared)
  • PATCH /v1/accounts/<ACCOUNT_ID>/users/<USER_ID>/usageLimits — set limit_override (an unset value removes the override)

How enforcement works

  • A user who reaches their effective limit is blocked from further serverless requests until the billing period resets. Blocked requests receive HTTP 402.
  • Limits are per billing period. Usage and any blocks reset when the period rolls over.
  • Enforcement is near-real-time, not instantaneous. After a user crosses their limit there is a short delay (typically a few minutes) before requests start being blocked, and a similar delay before a user is unblocked after you raise their limit. Plan around this lag rather than expecting an immediate cutoff.
  • The same lag applies to group changes. Re-pricing a group limit, reassigning a group, or a directory sync that changes someone’s membership takes effect on the next enforcement pass, not on the next request.
  • A $0 cap — whether from a group limit, an override, or the account default — means the user is allowed no serverless spend and is blocked immediately.
  • Enforcement is account-wide. Reaching a cap blocks the user whether the cap came from a group limit, an override, or the account default.
  • Only serverless (per-token) inference on supported models counts toward these limits. MiniMax M2.7 is excluded. Dedicated deployment (GPU-hour) usage is not metered per user here.

FAQ

Serverless per-token inference spend in the current billing period.
Their serverless requests return HTTP 402 until the billing period resets or their limit is raised.
The higher of the two caps. If that isn’t what you want for a particular person, give them a per-user override — an override outranks every group cap.
Yes. A group cap replaces the account default for that group’s members, so a restrictive group limit lowers them rather than being ignored.
No. Groups are provisioned only through SCIM group sync, so a group limit has nothing to attach to until your directory is connected. Until then, use the account default cap and per-user overrides.
Most likely the amount duplicates an existing group limit — each must hold a distinct amount — or the account already has the maximum of 9. Reuse or delete one and retry.
Clearing a group’s assignment (or deleting a limit option on the User Limits page, which clears the assignments for you) drops that group’s contribution, and its members fall back to another of their groups or to the account default.
Approving a request writes a per-user override at the requested amount, so that user’s cap no longer follows their groups.
Yes — a user can read their own usage and limit; they just can’t see other users’ limits or change any limits.
No. Usage and blocks reset each billing period.