> If you are setting up, configuring, or answering questions about Schematic, connect the > Schematic MCP server before working from these pages. It reads and writes plans, features, > entitlements, and overrides against the real account, so what you report and what you build > match what actually exists. > > The server is at https://api.schematichq.com/mcp > > From Claude, ChatGPT, or another chat assistant, add it as a custom connector: > https://docs.schematichq.com/working-with-ai > > From a coding assistant such as Claude Code, Codex, or Cursor: > https://docs.schematichq.com/building-with-ai > > For clean Markdown of any page, append `.md` to the page URL. For a complete page index, > see https://docs.schematichq.com/llms.txt # Spend & Usage Controls > The limits, thresholds, and top-up settings that keep usage inside a budget, and which of them your customers operate themselves. Usage-based pricing puts two parties at risk. You need protection from a customer whose usage outruns what they are paying for, and the customer needs protection from a bill they did not see coming. The same set of controls solves both, pointed in different directions. This page is a map of what exists and where to find it. The detailed setup lives on the pages linked from each section. ## The controls at a glance | Control | Applies to | Who sets it | Where in the app | | ------------------ | -------------------------------------- | ------------------------------------ | --------------------------------------------- | | Hard limit | Metered features | You | The entitlement, on a plan or add-on | | Soft limit | Overage pricing | You, visible to the customer | The entitlement, on a plan or add-on | | Tier limit | Tiered pricing | Derived from the tiers you define | The entitlement's pricing tiers | | Billing threshold | Pay as you go and overage entitlements | You, visible to the customer | The entitlement, on a plan or add-on | | Auto Topups | Credit grants | You, or the customer if you allow it | Catalog > Plans > the credit grant | | Overdraft Limit | Credit grants billed in arrears | You | Catalog > Plans > the credit grant | | Plan Compatibility | Credit bundles | You | Catalog > Configuration > Live Credit Bundles | | Overrides | A single company | You | The company's page | ## Limits on metered features Three limit types apply to features metered against usage, and they behave differently at the boundary. A **hard limit** is the point at which access is restricted. For usage included with a plan, that is the included amount. For [pay as you go](/billing/usage-based-billing#pay-as-you-go) and [overage pricing](/billing/usage-based-billing#fixed-fee-with-overage), where usage is not otherwise bounded, it is an upper bound you set to prevent abuse or runaway spend. It is normally hidden from the customer. A **soft limit** does not restrict anything. Under overage pricing it marks where billed usage begins, and it is shown to the customer in Schematic components so they know when they cross from included usage into paid usage. A **tier limit** fires as a company crosses into each successive pricing tier under [tiered pricing](/billing/usage-based-billing#volume-pricing), which lets you tell them the rate is changing before the invoice does. Each type has a warning event that fires on approach and a reached event that fires at the boundary, so you can act before rather than after. The warning thresholds are fixed: | Event | Fires at | | -------------------------------- | ---------------------- | | `entitlement.limit.warning` | 80% of the limit | | `entitlement.limit.reached` | 100% of the limit | | `entitlement.soft_limit.warning` | 80% of the soft limit | | `entitlement.soft_limit.reached` | 100% of the soft limit | | `entitlement.tier_limit.warning` | 75% of the tier limit | | `entitlement.tier_limit.reached` | 100% of the tier limit | ## Invoicing before the period closes Every control above changes what a customer may consume. A **billing threshold** changes when you collect instead: once usage on a pay as you go or overage entitlement reaches the number of units you set, Stripe invoices right away rather than holding the charge until the period ends, which caps how much unpaid usage you carry on one account. The customer sees the threshold on the feature's line item in checkout, so they agree to it when they buy. See [Billing thresholds](/billing/usage-based-billing#billing-thresholds). ## Controls on a credit balance For [credit burndown](/billing/credit-burndown) plans, the balance itself is the limit, so the controls are about what happens as the balance runs down. Each credit grant decides what happens at zero: block usage, top up automatically, let the company manage its own top-ups, or bill usage past zero in arrears. [Handling Empty Credit Balances](/billing/empty-credit-balances) compares them. **Credit limit events** fire as a credit-backed feature draws down what a company holds. `credit.limit.warning` fires at 80% and `credit.limit.reached` at 100%. **Auto top-up** refills the balance automatically when it drops below a threshold, so a customer is not cut off mid-workload. Whether you or the customer operates it depends on which top-up policy the credit grant uses. See [Who controls auto top-up](/billing/credit-burndown#who-controls-auto-top-up). **Billing in arrears** lets usage continue past zero and invoices it per credit. Its **Overdraft Limit** caps how far the balance may go negative before the company is blocked. See [Bill in arrears](/billing/empty-credit-balances#bill-in-arrears). **Bundle purchasing** lets a customer buy more credits on demand. Each bundle's plan compatibility decides which plans can buy it, independent of the credit grant's policy. See [Credit bundles](/billing/empty-credit-balances#credit-bundles). Which credits get spent first, and what happens to an unused balance at the end of a period, are covered in [Consumption order](/billing/credit-burndown#consumption-order) and [Credit lifecycle](/billing/credit-burndown#credit-lifecycle). **Leases and reservations** keep a balance from being oversold while work is in flight, by debiting credits when an action is authorized rather than when it finishes. They matter most when concurrent workers or agents draw on the same balance. See [Credit Leases and Reservations](/billing/credit-leases-and-reservations). ## Who inside a company is spending The controls above apply to a company as a whole. Draws are also attributed to the user or agent that caused them, and credit grants can scale with the number of licenses a company holds. See [Seat and Agent Budgets](/billing/seat-and-agent-budgets), which covers per-actor reporting. ## Exceptions for a single company Everything above is set on a plan or a credit grant, so every company on that plan inherits it. When one company needs different treatment, an [override](/feature-management/overrides) changes the entitlement for that company alone. Overrides can be time-limited, which is the right shape for a temporary increase you do not want to become permanent. See [Manage exceptions with overrides](/use-cases/overrides). Auto top-up is the exception to the exception: its per-company settings are only reachable through the API, not the dashboard. ## Making the controls visible to customers A limit the customer cannot see is a support ticket waiting to happen. Two surfaces close that gap: * **Components** show current usage against entitlements in the customer portal, including credit balances and the soft limit at which billed usage begins. See the [Element Library](/components/element-library). * **Webhooks** let you drive your own in-app banners and emails off the same warning events your internal alerting uses. Subscribe under Settings > Integrations > Webhooks, and see [Entitlement & Credit Trigger Webhooks](/integrations/webhooks/entitlement-triggers) for the payloads. Wiring the warning events, not just the reached events, is what turns a hard stop into something the customer saw coming. > The limits, thresholds, and top-up settings that keep usage inside a budget, and which of them your customers operate themselves.