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

# Billing

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

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

<h2 id="how-it-works">
  How it works
</h2>

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

<h2 id="no-free-tier">
  Why there is no free tier
</h2>

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.

<h2 id="budgets">
  Budget caps
</h2>

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.                              |

<Warning>
  A budget is per project, not per organization. A limit on `production` does not constrain `staging`.
</Warning>

<h2 id="payment-problems">
  When payment fails
</h2>

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.

<h2 id="development-cost">
  What development costs
</h2>

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.