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

---
title: Set spend ceilings and approvals
description: >-
  Every quote states a maximum charge, and several ceilings sit above it. Approving spend is
  a separate act from approving a run, and neither one authorizes a payment.
route: /docs/compute/configure/spend-and-approvals
page_id: docs-compute-configure-spend-and-approvals
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Account owners and approvers controlling what Compute may spend
voice: D
reader_question: How do I control what Compute can spend, and who approves it?
primary_action: Authenticate a Compute client
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-configure-spend-and-approvals-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## Before you start

You need authority over the account's commercial terms, and a decision about who approves work. Set both before the first member submits anything.

Nothing on this page moves money. Spend control decides what work may be admitted; payment is a separate system with its own states.

## Read the maximum charge on a quote

Every quote states a maximum charge as a currency and an amount, in your request's `limits.maximum_price`. That is the ceiling for that specific work.

A quote is signed and carries an expiry. It also carries `non_authorizing = true`, because a quote never admits or runs anything.

If something changes between the quote and your submission, admission returns `REPLAN_REQUIRED`. Ask for a new quote rather than retrying the old one.

## Understand the ceilings above it

The quote's maximum charge is the innermost of several ceilings. Each is set separately, and the narrowest active rule wins.

- The organization or account ceiling, set once and changed through its own approval.
- The project ceiling, for work grouped under one budget owner.
- The member or identity ceiling, for one person or one automation.
- The key ceiling, carried by the credential the request was submitted with.
- The profile's limits, which may narrow a ceiling but can never widen one.
- The request's own `limits.maximum_price`.

Your usable spend is the lowest of these that applies. Raising one does nothing if a tighter one sits above it.

## Approve a run, or pre-approve a policy

There are two shapes of approval, and they are not interchangeable.

Per-run approval is a person reading one quote and deciding. Approval is always a separate act from requesting a quote, and it is what turns a priced plan into admissible work.

An explicitly pre-approved policy is a standing decision with its own ceiling and its own expiry. Routine work inside that ceiling admits without a person present; work outside it still needs a per-run decision.

Pre-approval is not automation of judgment. You are deciding in advance, once, for a bounded set of work, and that decision expires on schedule so it gets reviewed again. See [how to read a quote](/docs/compute/quotes) before you set the ceiling on one.

## Approving spend is never authorizing payment

This distinction matters more than any number on this page.

Approving spend permits work to be admitted and charged. It does not initiate, schedule or authorize a payment.

The billing surfaces can list, get, export, open a hosted payment action, read status and reconcile. They carry no debit operation at all. Nothing in Compute takes money from an account.

A payment is only settled when a current read-back from the payment provider says so. A label reading `Paid` in your finance system is an annotation from that system, never proof of settlement.

## Confirm success

The spend rule reads back as `VERIFIED`. Request one quote that sits inside the ceiling and one that exceeds it.

The first should quote normally. The second should refuse before admission, with a reason and a next action. If both are admitted, the ceiling is not doing what you think.

## When admission refuses on spend

Read the refusal class, because they are different problems with different fixes.

`CANONICAL_BUDGET_EXHAUSTED` means a spend or reservation ceiling is used up. Raise the applicable ceiling through its own approval, or wait for the period to reset.

`CANONICAL_ADMISSION_LIMITED` means the key or account is not authorized to make this request at all. That is a grant problem, not a budget one.

Never treat these as one rate limit and retry blindly. A retry against an exhausted budget refuses again for the same reason.

[Authenticate a Compute client](/docs/compute/access/authentication)
