# Account, billing, and administration

Workspace plans govern storage, features, and operational allowances. Account administration and plan entitlement are separate: being an administrator does not automatically make every workspace unlimited.

Plans apply to each workspace. On a deployment licensed to create Starter, Team, or Enterprise workspaces, a new workspace uses that licensed default independently of any existing Free workspace. Ordinary additional Free workspaces require billing activation; they do not inherit another workspace's paid plan. Changing a plan does not remove an existing administrative billing lock.

Ordinary Free admission allows one workspace at a time and up to two Free activations in a rolling 30-day window. Deleting a workspace does not undo an activation. Deletion in progress or failed cleanup continues to hold capacity until cleanup finishes. Additional workspaces can still be created in a locked state and activated on a paid plan. Explicit administrator overrides are recorded separately.

New workspaces stay locked until admission and billing setup finish. If creation reports that setup is pending, retry with the same handle to resume it. A retry does not allocate another Free activation or reset existing credits.

## Check the current workspace

Use this page to answer three different questions: Which features can this workspace use? How much of its allowance has it used? Is anything preventing new work? A plan, a usage observation, and an individual run's status each describe part of that picture.

1. Open [Settings](/settings) and select the intended workspace.
2. Review its plan, usage, and billing status.
3. Check storage and compute information before submitting a large batch.
4. Resolve a billing lock through the available account controls or your administrator.

Do not infer available capacity from the plan name alone. Administrators can configure plan values, and different limits can apply to uploads, exports, indexing, pending jobs, and concurrent compute.

## Understand worker compute and platform CPU

| Item | What to review |
| --- | --- |
| Dataset and artifact storage | Stored data, retained files, and the observation's freshness |
| Dataset processing | The operation's displayed charge or allowance before submission |
| Registered-worker jobs | Active and pending capacity, even when compute costs zero credits |
| Hosted CPU inference | Its separate included-time allowance and runtime limits |

Compute on registered workers costs zero platform credits under the current worker-compute policy. Storage still counts, and dataset processing or other billable platform operations remain subject to their own policy.

DataHub-hosted CPU inference uses a separate included-time allowance. It has admission and runtime limits and is not an unlimited fallback for worker jobs.

Enterprise can have uncapped commercial limits, represented as no commercial cap. Hardware fit, permissions, supported recipes, runtime safeguards, and available storage still apply. An uncapped allowance does not create resources.

## Read usage accurately

Queued and paused jobs can count toward pending-job limits. Concurrency limits may hold an admitted job in the queue even when its worker is online.

Storage observations can lag or be incomplete. Read the observation time and any partial or unavailable status. An unknown archive count is not zero, and a failed refresh does not prove that storage was deleted. Very large workspaces may require additional observation work before a complete breakdown is available.

### Follow a storage scan

Storage is measured in the background so checking a large workspace does not hold up its credits and plan information. **Scanning storage** shows the current phase and available counts while the last successful measurement stays visible. These counts show work completed; they are not a percentage or a forecast of the final size.

1. Select the workspace in Settings and review **Observed storage**.
2. Check the last successful observation time, or the start-to-finish interval when shown.
3. Use **Refresh storage** or **Refresh scan** to request another observation. Refreshing while one is active checks that scan rather than starting a duplicate.
4. If a scan fails, keep the failure message separate from the last confirmed values. An explicit refresh can resume its retained progress.

The observation covers an interval during which files may change; it is not an atomic snapshot. **Stored files** reports observed object bytes. **Search index (estimate)** is the estimated raw vector payload, not the search server's complete disk footprint. The combined observed total includes that estimate and is separate from plan admission accounting.

If no scan has completed, physical storage is unknown rather than zero. Cancelling a scan leaves the last successful measurement intact and does not delete files, change credits, or refund allowances. SDK callers can pass the exact returned `storage_scan.id` to `workspace.cancel_storage_scan(scan_id)`; a normal status read does not restart a failed or cancelled scan. See the [SDK guide](/sdk-docs) for the storage observation methods.

Compute duration excludes queue time and may be incomplete when an attempt could not be measured. Keep measured portions distinct from a verified total.

## Administer plans

### Review a plan change

1. Open the platform administration plan controls with an authorized admin account.
2. Select the plan and inspect its current feature and limit values.
3. Change the intended values and save.
4. Reopen the plan to confirm the saved result.

Use an uncapped value only for a limit that supports it. Zero and disabled values have a different meaning from unlimited capacity. Workspace membership and hardware safety remain in effect regardless of plan size.

Platform administrators can use the admin plan controls to manage supported limits and features. Preserve the distinction between zero, disabled, and uncapped values. Save deliberately and inspect the resulting plan.

Resetting a plan is an explicit administrative operation. Do not use plan changes or account-wide cleanup as a workaround for an individual failed job. Review scoped recovery or deletion messages instead.

## Manage credentials

Keep API keys and worker credentials private. Use the intended account and workspace scope, and revoke credentials that are no longer needed. Revocation can prevent future operations; already accepted work may still require a safe completion or cancellation path.