Usage Limits, Budgets, and Unavailable Features

Builders evaluates usage against the owner of the project that performs the action. A personal project uses the current user's limits and runtime budget. A team project uses the applicable team owner context. Moving a pipeline or changing project ownership can therefore change which budget, storage quota, project limit, pipeline limit, and concurrent-run capacity apply.

An unavailable action is not automatically a billing problem. Check ownership, role permissions, resource availability, and usage limits separately.

Understand the usage resources

Limits are plan- and owner-dependent. Use the values displayed for the selected user or team instead of copying a limit from another workspace or from a screenshot.

Read the Budget summary

Open Budget from the Builders navigation. The upper cards show the current user's budget and any separate team budgets available to the account.

Read each value as follows:

The Dashboard presents renewable and non-renewable balances on separate lines. A warning such as 0 ct renewable compute tokens left describes the renewable line only. Check the non-renewable balance and the aggregated Remaining value before concluding that all workflow runtime is exhausted.

Use Usage scope to switch between the personal budget and an accessible team budget. The Budget chart shows compute-token usage for the selected scope over the last 14 days. The Dashboard chart covers the last 30 days, so the two charts can legitimately show different time windows.

Inspect allocation records

Select a budget card to open its records.

Builders distinguishes these record types:

Each record shows the amount allocated, the amount remaining, and its period end. Do not treat non-renewable as meaning that a package can never end. It means that Builders does not replenish that record automatically; the record still has its own displayed end date.

When investigating a balance change, compare the record list with the usage chart and run costs. The summary is aggregated, while the records explain which allocations currently fund it.

Add or extend usage

Select Unlock more usage from the Dashboard or Budget page.

Choose the capacity that matches the failing operation:

The Builders dialog routes to the corresponding purchase area on boilerplate.com; it does not complete a purchase inside the dialog. Before confirming an order, verify the signed-in account, product, amount, renewal terms, price, and intended billing owner on the purchase page. Return to Budget after completion and confirm that the expected record or balance is visible before retrying production work.

Do not buy AI tokens to solve an ordinary workflow-runtime shortage. Every executed block consumes compute tokens, including AI Agent blocks. AI tokens are an additional balance used only when the selected AI source requires them.

Separate compute and AI charging

A Pro AI request can therefore have enough compute budget but still be unavailable because its AI-token balance is empty. A private provider can have available Builders compute tokens but still reject a request because of provider credit, rate, model, or credential limits.

See Choose a Model Source and Control Usage for source-specific behavior.

Transfer compute budget to a team member

The transfer action appears on the user budget when there is transferable balance and an eligible shared team. It moves compute tokens from the current user to another user in that team.

1. Open Budget and select the transfer action on the user budget card.
2. Select the shared Team that contains the intended recipient.
3. Select a Recipient other than the current account.
4. Enter a positive whole number in Compute tokens (ct).
5. Compare the amount with Available to transfer.
6. Recheck the team, recipient, and amount, then select Transfer.
7. Confirm the reduced sender balance and ask the recipient to confirm the new add-on record.

The transfer dialog applies an important conversion rule: the sender's monthly budget is transferred first, and the recipient receives the transferred amount as non-renewable add-on budget. The action can therefore reduce the sender's renewable balance even though the button is labelled Transfer add-on budget to team.

Budget transfer is not the same as funding a team-owned project:

Treat a confirmed transfer as a balance-changing operation. Builders does not present it as an automatic or reversible sharing rule, so verify the recipient and amount before submission.

Recognize owner-specific creation limits

Project and pipeline limits are checked for the selected owner context.

• When a user or team has reached its project limit, Builders disables creation and reports Project limit reached (usage/limit).
• If every owner available in the creation dialog is at its project limit, Builders reports that the project limit has been reached for every available owner.
• When the selected project owner has reached its pipeline limit, Builders disables creation and reports Pipeline limit reached (usage/limit).
• An unlimited value means the corresponding count is not capped by a numeric limit in the current feature response.

Reaching a creation limit does not itself move, delete, or change ownership of existing projects or pipelines. Remove an unneeded item only after its published triggers, runs, resources, and recovery requirements have been reviewed. Alternatively, change the applicable plan or choose another legitimate owner scope; do not move a workflow merely to bypass governance.

Respond to runtime and storage limits

Do not assume that every trigger event waits in an internal queue when concurrent-run capacity is full. Inspect the trigger response, alert, and Logs for the actual execution result. Provider-managed queues such as SQS or RabbitMQ have their own delivery and retry behavior, which is separate from Builders runtime concurrency.

Before deleting Static Drive files to free capacity, find every workflow that reads those paths. Storage cleanup can restore write capacity while breaking existing reads. Prefer archiving to an approved external store when retention is required.

Distinguish unavailable blocks from exhausted limits

The Designer can display a block as unavailable because its prerequisite is missing in the current project scope. Common prerequisites include:

• a compatible integration and provider capability;
• a database connection;
• a private or team AI agent;
• a target pipeline for Subflow;
• a storage destination;
• an account feature or eligible AI source.

Disable Hide unavailable blocks to inspect the catalog entry and its reason. Showing the item does not grant the missing capability. Configure the prerequisite under the same personal or team owner as the project, then reopen the Designer.

A permission failure can look similar. A Viewer may be able to inspect a project but not edit or run it; a Designer or Team Leader may still lack an ownership-transfer action reserved for Team Owner. Check Team Roles and Permissions before purchasing capacity for a disabled administrative action.

Diagnose an unavailable action

Use the following order so that one problem is not hidden by another:

1. Confirm the project's Owner type and Owner.
2. For a team project, confirm team membership, Builders access, and the member's role.
3. Confirm that the requested action is allowed for that role.
4. For creation, compare project or pipeline usage with the limit shown for that owner.
5. For execution, check aggregated compute balance, budget records, and active runs.
6. For persistent file operations, check the correct user or team Static Drive quota.
7. For Pro AI, check AI tokens and the displayed billing owner; for private AI, check provider billing and credentials.
8. For a block, disable Hide unavailable blocks and configure its required resource in the project scope.
9. Inspect Alerts, Logs, block logs, and the external provider response before retrying.

Retry only after the limiting state has changed. Repeated run attempts can consume more compute tokens and can repeat external effects when an earlier attempt progressed farther than expected.

Next steps

• Workspace and Access
• Project and Pipeline Ownership
• Move Pipelines and Change Project Ownership
• Dashboard Overview
• Static Drive
• Choose a Model Source and Control Usage
• Test Runs in the Designer
• Run Published Workflows
• Public Workflows