How workflows use credits

Workflow billing applies the same job pricing used outside workflows. The difference is when child jobs are charged and how workflow-level spending controls coordinate them.

Estimate first, charge per job

The workflow editor shows an estimated cost before a run starts. This estimate is a planning value, not an upfront charge or reservation.

The estimate can change when you edit inputs, settings, connections, or spending limits. Inputs that depend on an earlier node may not have an exact cost until that node's output resolves.

When you start a workflow, ProteinIQ does not deduct the whole estimate. Each child job uses credits only when it becomes ready to run:

• Fixed-price child job: Charges its full configured cost at dispatch
• Time-based child job: Takes its initial rolling authorization at dispatch, then requests later authorizations while it runs
• Free child job: Uses 0 credits

The workflow run records its estimate and actual credits spent as child jobs settle.

Time-based nodes

BindCraft, BoltzGen, mBER, and other time-based tools use the same rolling authorization model inside a workflow as they do when run individually.

When a time-based child job starts, ProteinIQ authorizes up to its first 5 minutes, subject to the tool minimum and any configured maximum. It requests further increments only as it continues running.

See How jobs use credits for the authorization calculation, per-second final charge, and settlement rules.

Per-node maximum spend

A time-based workflow node can have an optional maximum spend. This value is a ceiling for each job created by that node.

If a node fans out and creates three jobs, each job can spend up to the node maximum. A 500-credit node maximum can therefore permit up to 1,500 credits across those three jobs, unless the total workflow limit stops spending earlier.

The node maximum is not deducted upfront. Each child job still authorizes credits in rolling windows and returns unused authorization when it completes.

Without a node maximum, a job can continue until its scientific work finishes, the workspace cannot fund another authorization, the workflow reaches its total limit, or the tool reaches its runtime limit.

Total workflow spending limit

The optional total spending limit is a ceiling across all child jobs in one workflow run attempt. It includes fixed-price charges and time-based authorizations from every branch.

The total limit can be lower than the workflow estimate or the sum of the node maximums. This is intentional because branches may not all run, nodes can create a variable number of jobs, and you may prefer a strict total budget. ProteinIQ warns when the total is below the estimate because the workflow may pause before it finishes.

The total limit and node maximums answer different questions:

• Node maximum: How much may each job from this time-based node spend?
• Total workflow limit: How much may this workflow attempt spend across all child jobs?

The stricter applicable limit controls each new charge or authorization.

Admission, deferral, and pause behavior

ProteinIQ checks the workspace balance and total workflow limit before each child job spends credits.

• A fixed-price child must fit its full cost.
• A time-based child must fit its initial authorization.
• Every later time-based authorization must also fit.

If another child job is still running, ProteinIQ can defer a waiting child until the active job settles and releases any unused authorization. If no active child can change the available amount and the next child still cannot fit, the workflow pauses.

A workflow can also pause when the workspace balance is too low, even when its configured total limit is higher. The spending limit gives permission to spend; it does not add or reserve workspace credits.

What can continue after a limit changes

Increasing the total limit or adding credits can continue child jobs that have not started. ProteinIQ reevaluates waiting work against the updated balance and limits.

A running time-based child stops when it cannot obtain its next authorization. Raising a limit does not resume compute that has already stopped. The job retains any partial outputs and diagnostics returned by the scientific tool.

Retries and attempts

The total spending limit applies to one workflow run attempt. Retrying creates another attempt with the same configured limit, while attempt history records spending separately.

Each retried child job is a new job and follows the same fixed-price or time-based billing rules. Review the new attempt's estimate and available workspace balance before retrying a compute-intensive workflow.

Example

Consider a workflow with a fixed-price preparation job, a BindCraft node, and a BoltzGen node.

• The preparation job charges only when it is ready to dispatch.
• BindCraft and BoltzGen each take their own initial authorization when their child jobs start.
• A node maximum limits each child job produced by that node.
• The total workflow limit applies across preparation, BindCraft, BoltzGen, and any fan-out jobs.
• Unused time-based authorization returns to the workspace when each completed child settles.

The workflow estimate helps you choose the limits, but the final spend is the sum of settled child-job charges.