> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hollerith.monarcha.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Usage and billing

> What counts as a billable row

```python theme={null}
clf.fit(train, target="churned")   # 200,000 training rows -> 200,000 billable rows
clf.predict(test)                  #  50,000 scored rows   -> 100,000 billable rows
```

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

| Job                      | Input rows                  | Output rows  | Billable rows                   |
| ------------------------ | --------------------------- | ------------ | ------------------------------- |
| `fit`                    | training rows               | 0            | training rows                   |
| Inline `predict`         | training rows + scored rows | scored rows  | training rows + 2 × scored rows |
| Context-backed `predict` | scored rows                 | scored rows  | 2 × scored rows                 |
| `evaluate`               | rows in the frame           | 0            | rows in the frame               |
| `forecast`               | context rows + horizon rows | horizon rows | context rows + 2 × horizon rows |

## 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:

```
fit        input 200,000   output      0    ->  200,000
predict    input  50,000   output 50,000    ->  100,000
                                     total      300,000
```

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](/concepts/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.

```python theme={null}
clf.fit(train, target="churned", evaluate=True)   # 2 jobs, 400,000 billable rows
```

## Plans

| Plan       | Base per month | Included billable rows |
| ---------- | -------------- | ---------------------- |
| Free       | \$0            | 100,000                |
| Cloud      | \$500          | 1,000,000              |
| Scale      | \$2,000        | 3,000,000              |
| Enterprise | \$8,000        | 10,000,000             |

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

| Rows above your allowance | Rate                |
| ------------------------- | ------------------- |
| First 10,000,000          | \$300 per 1,000,000 |
| Next 40,000,000           | \$150 per 1,000,000 |
| Above 50,000,000          | \$80 per 1,000,000  |

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:

```
fit               200,000 input +         0 output  =    200,000
20 x predict    1,000,000 input + 1,000,000 output  =  2,000,000
                                             total     2,200,000

included (Cloud)                                       1,000,000
overage                                                1,200,000

base                                                        $500
overage           1.2 x $300                                $360
                                             total          $860
```

Going over your allowance bills. It does not block.

## Daily quota

| Quota      | Value     |
| ---------- | --------- |
| Calls      | 10,000    |
| Input rows | 1,000,000 |
| Reset      | 00:00 UTC |

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

* [Limits and quotas](/reference/limits) — every ceiling and the error you get at it
* [The fitted context](/concepts/fitted-context) — fit once, predict many
* [Data handling and retention](/account/data-handling) — what we keep, and for how long