How jobs use credits

Every paid job uses one of two billing models: fixed-price or time-based. The tool page shows the applicable model before you submit the job.

Billing terms

These terms separate planning from actual credit movement.

• Estimated cost: The expected cost based on current inputs and settings
• Authorization: Credits temporarily removed from the available balance for a time-based job
• Maximum spend: An optional ceiling on a time-based job's total charge
• Final charge: The credits retained after the job reaches a terminal status
• Refund: Credits returned after unused authorization or an eligible job outcome

A maximum spend is not an upfront reservation. It limits how far a job can continue, while authorizations determine how many credits are currently held.

Before a high-cost job starts

ProteinIQ adds a confirmation step when a job could use a large number of credits or its estimate is higher than the current workspace balance.

• A fixed-price job estimated at 5,000 credits or more asks for confirmation before the full charge is taken.
• A fixed-price job cannot start when its configured cost is higher than the available balance.
• A time-based job without a maximum asks for confirmation when its estimate is 5,000 credits or more.
• A time-based job also asks for confirmation when its estimate is higher than the available balance, even if the estimate is below 5,000 credits. If the workspace can fund the initial authorization, you can set a maximum, add credits, or run with the current balance.
• A time-based job cannot start when the workspace cannot fund its initial authorization.

An estimate is a planning value, not a charge or a hidden 5,000-credit ceiling. Confirming a time-based estimate does not reserve the estimated amount upfront. The job continues through rolling authorizations and may stop before completion if the workspace cannot fund a later authorization.

When you set an explicit maximum, ProteinIQ uses that choice instead of showing the estimate-based confirmation again. The maximum can be higher than the current balance because it is not reserved upfront, but the job may still stop if a later authorization cannot be funded.

Fixed-price jobs

Fixed-price jobs have a known cost before they start. The cost can be flat or calculated from the submitted inputs and settings.

ProteinIQ validates the configured cost against the active workspace balance and charges the full amount when the job is created. A free job with a displayed cost of 0 does not use credits.

If an eligible fixed-price job fails or times out, ProteinIQ restores the charged credits automatically. A cancelled fixed-price job is eligible for a refund when cancellation occurs before compute launches.

Time-based jobs

Time-based jobs charge for actual billable runtime. The tool page shows a rate in credits per minute, an estimated duration, and an optional maximum spend.

A time-based job normally stops when its scientific work finishes. It can stop earlier if it reaches its maximum spend, the workspace cannot fund another authorization, or the tool reaches its runtime limit.

Initial authorization

ProteinIQ authorizes up to the first 5 minutes when the job starts. Every time-based tool also defines a minimum authorization.

The initial authorization follows this calculation:

min(maximum spend, max(tool minimum, 5-minute cost))

Current time-based configurations produce these initial authorizations when you do not select a lower maximum:

This is why OpenMM initially authorizes 200 credits and GROMACS on CPU initially authorizes 100, even though both use the same rolling-window model. BoltzGen starts at 500 because its tool minimum is higher than its five-minute cost.

The displayed tool configuration is the source of truth for the rate, estimate, and permitted maximum for the job you are about to submit.

Rolling authorizations

ProteinIQ requests another increment of up to 5 minutes before the current authorized runtime runs out. A renewal succeeds only when all of these conditions remain true:

• The workspace has enough available credits for the increment
• The job stays within its maximum spend
• A workflow child job stays within any applicable workflow limit
• The tool has not reached its runtime limit

Only the credits authorized so far are removed from the available balance. Selecting a 221-credit maximum does not remove 221 credits at submission if the initial authorization is 100.

Other jobs can spend from the same workspace balance. A maximum spend limits this job, but it does not guarantee that the workspace will be able to fund every later renewal.

Final charge

Completed time-based jobs are billed per second, then rounded up to the next whole credit:

final charge = ceil(rate per minute × billable seconds ÷ 60)

This provides finer billing than rounding runtime up to whole minutes. For example, an RFantibody A10 job with 11 minutes 50 seconds of billable runtime costs:

ceil(25 × 710 ÷ 60) = ceil(295.83) = 296 credits

The final charge does not have to be a multiple of the per-minute rate. Any authorized credits above the final charge return to the workspace balance.

Settlement by outcome

The final job status determines how ProteinIQ settles an authorization or fixed charge.

Refund entries appear in the workspace usage ledger so you can trace the original charge and the returned credits.

Reading usage while a job runs

Usage and administration views distinguish current authorization from the maximum spend.

• Processing job: Shows the credits authorized so far and, when set, the job's maximum
• Settled job: Shows the final charged amount after refunds or runtime settlement

If a processing job shows 100 authorized and 221 maximum, then 100 credits are currently held. The job can request later authorizations up to the 221-credit ceiling.

Plans and job billing

Your plan determines the workspace's included credits, access rights, and job limits. It does not change the meaning of authorization, maximum spend, or final charge.

The same billing model applies when a job runs by itself, through the API, or as a workflow child. See How workflows use credits for workflow estimates and spending controls.