# Billing

> How Gomry Cloud bills: postpaid per-unit metering, one monthly invoice, per-project budget caps, and why there is no free tier.

Source: https://cloud.gomry.com/docs/billing

Cloud is **postpaid and metered**. You are billed for the units you consume, invoiced monthly. There are no plans, no seats and no minimum.

## How it works

- Every billable request records the units it consumed, against the project that made it.
- Each service prices each of its operations separately, per unit — the current rates are on each [service page](https://cloud.gomry.com/services), read from the same table that generates the invoice.
- Usage accumulates over the calendar month and is invoiced to the organization's card at the end of it.
- Only work that produced a result is billed. Failures cost nothing.

Operations within one service are priced independently because they cost independently. Extracting structured data from a page costs several times what fetching that page costs, so they are separate prices, separate meters and separate scopes rather than a flag on one endpoint. That is what stops a caller who wanted the cheap operation from being billed for the expensive one.

## Why there is no free tier

Every Cloud request carries real upstream cost the moment it runs, whether or not we can invoice for it. So spending is opt-in and the opt-in is a card: an organization without an active payment method is refused with `billing_required` at the gateway, before any work happens.

Free usage, when we grant it, is a **credit on your account** rather than a free allowance written into a product. A credit covers any service you use, including ones that ship after it was granted, and it runs out — which is the honest version of the same offer.

## Budget caps

Each project can carry a monthly limit, evaluated **before** the work, against the calendar month in UTC. It is the control that bounds a runaway loop, and it is the one we recommend setting on day one.

| Setting | Effect |
| --- | --- |
| No limit | Uncapped. Your card is the only ceiling. |
| Limit, action **block** | Requests are refused with `402 insufficient_credit` once the month's spend reaches the cap. |
| Limit, action **notify** | Requests continue; the overage is flagged rather than refused. |

> **Important:** A budget is per project, not per organization. A limit on `production` does not constrain `staging`.

## When payment fails

If an invoice cannot be collected, the organization moves to past due and the data plane stops serving with `billing_past_due` until the card is fixed. There is no grace window on a postpaid metered API, and that is deliberate: usage accrued during a retry window would land on the same invoice that is already failing to collect.

Nothing is deleted. Keys, projects and usage history survive; only the ability to spend is paused, and it resumes on the next request once the payment method is valid.

## What development costs

There is no separate development tier: the calls you make while integrating are billed at the same per-unit rate as production. In practice that is cents, because only work that produced a result is metered — validation errors, auth failures, rate limits and upstream failures all cost nothing. Set a small monthly budget on a project you are experimenting with and the cap, not the credential, is what bounds the spend.