Minimum Charges
Most of what you spend on VolatiCloud is metered: a bot or a backtest consumes CPU, memory, network, and storage, and those quantities are priced and deducted from your credit balance. A minimum charge sits underneath that meter. It is the smallest amount a single job costs, no matter how little compute it ended up using.
This page covers what the minimums are on VolatiCloud's cloud runner, when they apply, when a run is free, and what you see if your balance can't cover one.
The AI assistant is metered but has no minimum charge. It spends credits on the tokens a turn actually uses — see Credits — and no floor is applied to it, so nothing on this page affects what a conversation costs.
One credit equals one US dollar. Every number on this page is in credits.
Why a minimum exists
Metering charges you for the seconds a container actually burns. But running a job is more than those seconds: the platform has to schedule a container, start it, hand it your strategy and market data, watch it, and tear it down afterwards. That fixed work happens whether your backtest covers ten years or ten minutes.
Without a floor, a two-minute backtest meters out to a fraction of a cent — small enough that it rounds away entirely and costs nothing. The minimum charge replaces "nothing" with a small, predictable number, so the cost of a run is something you can reason about before you click Run.
That is also why the numbers are round. They aren't a measurement of your job; they're a floor.
What the cloud runner charges
VolatiCloud's shared cloud runner — the one named System, selected by default when you run a backtest or start a bot — applies these minimums:
| Job | How it applies | Amount |
|---|---|---|
| Backtest | Floor — the run pays the larger of its metered cost and this | 0.05 credits |
| Hyperopt | Floor — as for a backtest | 0.10 credits |
| Bot start | Charge per start — added to the bot's metered runtime | 0.05 credits |
Alongside the minimums, the same runner meters usage at these rates:
| Resource | Rate |
|---|---|
| CPU | $0.0206 per core-hour |
| Memory | $0.0103 per GB-hour |
| Network | $0 — egress is not charged |
| Storage | $0 — disk I/O is not charged |
A runner's own page is always the authoritative source for what it charges right now. Open Runners → the runner → Overview, and look at Billing Rates and Minimum Charges. If a number there differs from this page, the runner page wins.
A runner you host yourself is not billed by VolatiCloud at all. If you connect your own Docker or Kubernetes runner, no rates and no minimums apply — you pay for your own infrastructure, directly, to whoever provides it.
Floors and start charges are different things
The distinction matters because it decides whether the minimum adds to your bill or merely props it up.
Backtests and hyperopts pay a floor
A backtest or hyperopt has a beginning and an end, so it can be settled once, when it finishes. A run that completed pays max(metered, minimum):
| Run | Metered cost | Floor | You pay |
|---|---|---|---|
| Short backtest, 30 seconds | 0.004 | 0.05 | 0.05 |
| Long backtest, several hours over many pairs | 0.31 | 0.05 | 0.31 |
| Median hyperopt, a few minutes | 0.002 | 0.10 | 0.10 |
| Backtest that failed after 18 seconds | 0.002 | — | 0.002 |
A run that failed is the exception: it pays what it metered and no floor. See when a run is free.
The floor never charges you twice. Metered usage is deducted the normal hourly way; at settlement the run pays only the part of the floor the meter didn't reach.
Bot starts pay a fee
A bot has no end — it runs until you stop it, and it's metered continuously for as long as it's up. There is nothing to settle it against, so its minimum is a charge per start, added on top of metered runtime.
Concretely: a bot you start once and leave running for a month pays 0.05 once. A bot you start and stop ten times in a day pays 0.05 ten times — 0.50 — on top of what its runtime metered. If you're tuning a live bot, batch your changes rather than restarting after each one.
When a run is free
Three cases cost you nothing at all:
- The job never started. If a run is refused before dispatch — a validation failure, a plan limit, an insufficient balance — no container ever existed, so there's no metered cost and no floor. Nothing appears in your credit history.
- A bot start that fails. The start charge lands only on a start the platform actually accepted. A start that errors out costs nothing.
- A stopped bot. Stopped bots consume zero. This hasn't changed.
And two cases that are partly free — both pay only what they actually metered, with no floor:
- A backtest or hyperopt that failed. If your run errors out — a
TypeErrorin your strategy, a bad date range, a container that died — you pay for the seconds it burned before it stopped, and nothing more. The floor exists to stop very short successful runs costing effectively nothing; a failed run gave you no results, so charging a floor on top of it would be a penalty for an error. A run that fails after 18 seconds costs a fraction of a cent. A run that fails after 20 minutes still pays for those 20 minutes. - A run the platform cancels. If your credits run out while a backtest or hyperopt is in flight, VolatiCloud cancels it. That run pays only what it metered too. The floor must not price the platform stopping your work for you.
If you cancel a run that was already dispatched, the floor does apply. The container was started on your behalf, and cancelling is exactly the "started work and walked away from it" case the floor is there to price. A run that completed pays the floor for the same reason.
Seeing the cost before you run
You should never be surprised by a floor. Every place that starts a job shows a cost line for the selected runner before the job is dispatched, and the line updates when you change the runner:
- Backtest and hyperopt drawers: "Cost: 0.05 credits" when the runner charges a floor and no metered rates, or "Estimated cost: at least 0.05 credits, more if usage exceeds it" when usage is also metered.
- Create bot drawer (Create and run) and the bot's Start button: "Cost to start: 0.05 credits", with "plus metered usage while running" when the runner also meters.
- The runner's detail page: the full Minimum Charges panel, next to the billing rates.
On a runner that does not bill (your own self-hosted runner, for instance) the line reads "Cost: no credits charged on this runner".
The figure comes from the same calculation that checks your balance at dispatch and settles the job when it ends, so the number you see before you start is the number those steps use.
When your balance is below the minimum
A run whose minimum you cannot afford is refused before it starts, rather than dispatched and then abandoned halfway. You'll see:
This backtest needs 0.05 credits on the selected runner, but this organization only has 0.02. Add credits to continue.
with an Add Credits action beside it. The same message appears for a hyperopt or a bot start, with that job's own minimum.
This is deliberately a different message from the zero-balance one. An organization that has run out entirely is suspended and told it has no credits. An organization that sees this message still has credits — just not enough for this job on this runner — and the message names the number to reach.
Nothing is charged for a refused run.
If you hit this on a hyperopt, check whether a backtest would answer the same question. A hyperopt's floor is twice a backtest's, because it does substantially more work.
Finding the charge in your history
Minimum charges appear in Organization → Billing → Transaction History as ordinary usage_deduction rows. What tells them apart is the description:
| What you ran | Description in the ledger |
|---|---|
| Backtest settled at its floor | Backtest "My Strategy": minimum charge 0.0500 (metered 0.0040) |
| Hyperopt settled at its floor | Hyperopt "My Strategy": minimum charge 0.1000 (metered 0.0021) |
| Bot start | Bot start charge — My Bot |
The backtest and hyperopt lines show both numbers, so you can see exactly how much of the charge was the floor and how much the meter had already covered. A run whose metered cost was above the floor produces no settlement row at all — the hourly deductions already charged it in full. Neither does a run that failed, or one the platform cancelled: both pay through the meter only.
Each row is written once per run. Retries and restarts of the platform's own machinery cannot charge the same run twice.
Frequently asked questions
Why did a two-minute backtest cost more than an hour of bot runtime? Because the backtest paid its floor and the bot paid its meter. A bot at rest uses very little CPU and memory; a floor doesn't apply to it per hour, only per start.
Does the floor apply per backtest, or per batch? Per backtest. Running the same strategy over five date ranges is five runs and five floors.
Do minimums come out of subscription credits or manual credits? Same as every other deduction — subscription credits first, manual credits last (FIFO).
Is a failed backtest charged? It pays only what it metered — no floor. Compute was consumed, so it isn't free, but a run that produced no results doesn't pay the minimum on top. In practice a backtest that fails in the first few seconds costs a fraction of a cent. If it never dispatched at all, nothing is charged.
My run failed and I still see a charge. Why?
The meter. Failure waives the floor, not the metered cost — a job that runs for twenty minutes and then errors on its last step used twenty minutes of a machine. You'll see it as an ordinary hourly usage_deduction, not as a minimum charge line.
I run on my own Kubernetes cluster. Does any of this affect me? No. Minimums and rates belong to the runner, and a runner you host carries neither.
Related guides
- Credits — how metered deduction, deposits, and the ledger work.
- Billing Overview — the subscription-plus-credits model and suspension rules.
- Plans & Pricing — what each plan includes and deposits.
- Running Backtests — where the minimum is shown before a run.
- Runners Overview — cloud runner versus your own infrastructure.