Skip to main content
Hollerith bills one unit: rows. Every job counts the rows you send it plus the rows it hands back.

​
What a billable row is

A billable row is one submitted input row plus one returned output row, from a job that succeeded. Metering happens once, on the first successful completion. A failed job never bills — a fit that reaches the GPU and then raises worker_oom costs nothing. Cells are recorded as telemetry and never billed. Row and column counts explain a duration in the console, not a charge.

​
Rows per job kind

​
Where the doubling comes from

A context-backed predict sets its input row count equal to its output row count. Your training table already sits on our side, so the only rows it counts are the ones you sent. You pay for each of those rows twice. The submit counts them, and the response counts them again. Worked, on 200,000 training rows and 50,000 rows to score:
The fit is paid once. Each predict against that context pays twice its own batch, every time.

​
fit and evaluate both bill

fit is a queued GPU job and it bills your training rows. “No training step” is a claim about gradients, not about cost — see How Hollerith works. evaluate=True submits a second job, separate from the fit and from any predict. It re-uploads the whole frame, label column included, and bills those rows again.

​
Plans

Free is an allowance, not a cap. A $0 account that passes 100,000 rows keeps running and accrues overage at the rates below, and nothing blocks the job. The allowance is pooled. One monthly total covers the whole organization, and every key, every member and every job kind draws on it. Plans are not self-serve. A Hollerith administrator provisions yours, and the only billing action in the console is the Stripe customer portal, which only an owner can open.

​
Overage

Bands are cumulative, not stepped. Crossing into the second band reprices only the rows inside it, never the ones below. A month on Cloud — one fit of 200,000 rows, then twenty context-backed predicts of 50,000 rows each:
Going over your allowance bills. It does not block.

​
Daily quota

The daily quota counts input rows only. Output rows bill but do not draw on it, so a context-backed predict of 50,000 rows spends 50,000 of quota and bills 100,000. Quota is reserved when a job is submitted and released when it completes. A burst of concurrent submits can hit quota_exceeded before any of them has run.

​
In the console

The Usage tab is where all of this is visible:
  • Calls today — against the 10,000 daily ceiling, with the reset time.
  • This period — plan, spend, base plus overage, and pooled rows used against included. This is the authoritative billable-row total.
  • Request history — created, request id, task, training rows, output rows, status, latency.
Request history does not carry a billable-row column, and for a context-backed predict its two row columns do not add up to what was billed. That job bills twice its output rows; the training rows shown belong to the context and were billed once, by the fit.

​
Next