Workflow credit usage

A workflow uses the same job billing models as an individual analysis. Starting a workflow does not charge or reserve its full estimate. Each job uses credits when it is ready to run.

Workflow estimates

The editor estimates the cost from the current inputs, settings, connections, and spending limits. A step that depends on an earlier result may not have an exact cost until that result is available.

The estimate is a planning value. Actual spending comes from the jobs created during the run:

• A fixed-price job charges its configured cost when it starts.
• A time-based job takes an initial authorization and requests further credits while running.
• A free job uses zero credits.

The run records its estimate and the credits used as jobs settle. Refunds for jobs that fail or never launch are subtracted from the run's total.

Set spending limits

Two optional limits control different scopes:

• The node maximum caps each job created by one time-based tool node.
• The total spending limit caps spending across all jobs in one workflow run attempt.

Open the workflow cost estimate. Under Time-based jobs, set the maximum for each time-based node you want to limit. In the same panel, enable Total spending limit and enter Maximum spend in credits. Review both before starting the run.

The total can be lower than the estimate or the combined node maximums. The editor warns when it is below the estimate because the run may pause before completion.

A limit does not reserve or add workspace credits. Both the applicable limit and the available balance must cover each new charge or authorization.

Nodes that create multiple jobs

A node maximum applies to each job, not the combined cost of the node.

For example, a node that creates three jobs with a maximum of 500 credits per job could use up to 1,500 credits. If the total workflow limit is 1,000 credits, that lower total still applies across those jobs and every other step in the run.

Use the total limit when you need to cap the whole run.

Credit checks and pauses

Before a job starts, ProteinIQ checks whether the available balance and remaining workflow limit cover its full fixed-price cost or initial time-based authorization. Later time-based authorizations must also fit.

When a job cannot be funded:

• If other jobs are still running, the waiting job can stay deferred until they settle and release any unused authorization.
• If no active jobs can release credits, the workflow pauses.
• If a running time-based job cannot renew its authorization, that job stops and keeps any available partial outputs.

A workspace can run out of credits before reaching the workflow limit, especially when other analyses are using the same balance.

A run can also pause for other reasons, such as a manual curation step. Jobs that already started on other branches keep running and keep renewing their time-based authorization while the run is paused.

Free plan daily job limit

On the Free plan, every workflow step that runs a job counts toward the daily job limit, the same as a job you submit directly. A step that splits into several jobs counts each of them.

ProteinIQ checks the remaining allowance when you start the run and again before each job launches. If the limit is reached partway through, the job that would exceed it fails with a daily limit message, so the run can stop midway and steps that depend on it do not run. Steps that already finished keep their results and charges. Upgrade to a paid plan to remove the daily limit.

Continue a paused run

Check the pause message to identify the constraint:

• For insufficient credits, restore enough workspace balance for the waiting work.
• For a reached spending limit, increase the run's total limit if you want to authorize more spending.

Then use the run's Try again action to reevaluate waiting work in the same attempt. Updating the limit or balance can allow jobs that have not started to proceed. It does not resume compute in a job that has already stopped.

Cancel a run

Cancelling stops the run from launching any more jobs. What happens to credits depends on each job's state:

• Jobs that have not launched yet are cancelled and their credits are refunded in full.
• Jobs that already launched keep running until they finish, and you are charged for them.
• A fixed-price job that already launched is not refunded.
• A time-based job that already launched is charged for the runtime it uses, and any unused authorization is returned.

The run shows its final total once every launched job has settled.

Retries and reruns

Retrying a failed step reruns only the jobs in that step that failed. Jobs in the same step that already succeeded keep their results and are not charged again.

Using a Rerun from… action creates a new run attempt. By default it keeps the spending limit from the previous attempt, and you can set a new limit when you start the rerun. Each new job in that attempt follows the same billing rules. The previous attempt's history and spending remain recorded separately.

A 1,000-credit limit applies to each attempt, not to the combined lifetime cost of every retry. Review the estimate, retry scope, and workspace balance before starting another attempt.