# AI Spend Controls: Limits and Payment Approvals

> AI spend controls in Elaichi Black: usage limits, payment caps and approvals above a set amount, and test runs that cost nothing.

**TL;DR** Elaichi Black gives finance two AI spend controls: usage limits that pause workflows at a hard limit you set, and payment controls. Payment controls cap what a payment tool may pay and ask one or two people to approve a payment above a set amount. Only people with spend:manage or billing:manage can change them, and every AI client and the Elaichi Agent can only read them. Your team's own AI can draft and test-run a workflow first, and a test run costs no run time.

A workflow that can pay a vendor is a workflow that can overpay one. AI spend controls in Elaichi Black let finance cap what workflows cost and pay, and send large payments to a person for approval.

Before agents call tools that move money, a finance team wants three answers:

- how much the agents can spend
- who signs off on a large payment
- who can raise the ceiling

Black's spend controls answer all three, and they sit with finance, not with the AI.

Elaichi is a governed MCP control plane. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps ([the protocol's introduction](https://modelcontextprotocol.io/docs/getting-started/intro)). Black adds workflows that call your connected tools on their own. Spend controls decide what those runs may cost and pay.

## What are AI spend controls in Elaichi?

Elaichi's AI spend controls are two things. Usage limits cap the run time workflows can use. Payment controls cap what a payment tool may pay, and send larger payments to people for approval.

Usage limits come in two sizes:

- **One workflow.** A single workflow takes its own run-time limit, set from the workflow with "Set a run-time limit".
- **The organization.** The usage budget is set in Settings > Billing, under "Usage budget", in the organization's billing currency.

Payment controls live in Governance > Payment approvals. Spend controls come with the Black plan, not Personal or Gold.

## What happens when a workflow reaches a hard limit?

That depends on the limit's setting. Pause holds runs at the hard limit, and continue only alerts. A new budget pauses unless set to continue.

When a limit pauses:

- A manual run or a retry is refused with HTTP 409 and the code usage_limit_reached.
- A scheduled run is skipped.
- A run started by an event is held in the queue.
- A run already going stops before its next step until the limit resets or is raised. If it is still held after 72 hours, it fails.

The events that hold a run are a webhook, a Slack message or reaction, a collection row change or another workflow's run. A webhook is a message another app sends to Elaichi when something happens.

Time held at a limit is not billed. Before the limit, alerts fire at up to five percentages, 50, 80 and 100 by default, once each per period.

Each alert is the audit event automation.usage_threshold_reached. The organization's Slack and email notification destinations forward it. When paid Black's monthly budget crosses one, everyone who holds billing:manage is emailed too.

## How do payment approvals work?

Payment approvals put a person between an agent and the money. The setup has three parts, all in Governance > Payment approvals:

1. **Payment tools.** The list names the tools that move money. A workflow step that calls one of them must declare the amount, the currency and the payee.
2. **Payment policy.** Per currency, it sets the amounts above which a payment needs one approval or two. With no policy, every payment needs one approval.
3. **Spend caps.** A cap limits what one payment tool may pay, for every workflow or for one. It applies per day, week or month, and optionally per payment.

The approval rules follow [separation of duties](https://en.wikipedia.org/wiki/Separation_of_duties), where no single person completes a sensitive task alone. A request goes to the people and teams the payment step names. If the step names none, it goes to the policy's default approvers. The person who started the run and the workflow's owner can never approve it. Two approvals come from two different people.

Requests arrive on the Approvals page at the top of the console's sidebar, and by Slack and email. The Slack message shows the amount, payee and tool, but no buttons: "Payments are approved in Elaichi, not from Slack."

The approver must be signed in and confirm it is them. An API token is refused, and no AI client or the Agent can answer. A rejection stops the run, and no money moves. With no answer after 72 hours, the step fails with approval_expired.

A payment that would go past a cap fails at once, with spend_cap_exceeded or amount_over_transaction_limit. Elaichi does not retry it.

## Who can see and change spend controls?

Two permissions cover spend controls: spend:view reads them, and spend:manage changes them. The usage budget needs billing:manage, held by Org Owner and Billing Admin. These are role permissions in Elaichi's [role-based access control](https://en.wikipedia.org/wiki/Role-based_access_control) (RBAC), where people get permissions through their role.

| Role | spend:view | spend:manage | billing:manage | Paid seat |
|---|---|---|---|---|
| Org Owner | Yes | Yes | Yes | Yes |
| Org Admin | Yes | Yes | No | Yes |
| Billing Admin | Yes | Yes | Yes | No |
| Auditor | Yes | No | No | No |
| Member | No | No | No | Yes |

Billing Admin holds exactly four permissions: billing:view, billing:manage, spend:view and spend:manage. It has no organization or product permission, and it is a free seat. An Auditor can read the settings and change nothing.

Spend controls are read-only for every AI client and for the Elaichi Agent. Over MCP, four `elaichi__spend__` operations read them: `usage__get`, `limit__list`, `payment_policy__get` and `payment_cap__list`. Each needs spend:view, and none of them writes.

Changing the payment policy, the payment tools list or a payment cap needs more than the permission. It needs a person's own signed-in session, never an API or agent token. It also needs a fresh step-up confirmation, "Confirm it's you", a second check that the person is really them. For anyone with a passkey or an authenticator app, an emailed code is not accepted. Usage limits and the budget need no step-up.

## Test a workflow with your own AI before it spends anything

A test run on Black costs no run time. So your team's own AI can write a workflow and try it on real data before it spends or pays anything.

The builder can be Claude, ChatGPT, Cursor or any MCP client, through the `elaichi__automation__` operations at https://api.elaichi.ai/mcp. The Elaichi Agent works beside them in the console. The loop runs in this order:

1. **Draft.** The AI creates the workflow as a draft with `elaichi__automation__draft__create`.
2. **Validate.** `elaichi__automation__draft__validate` checks the definition without saving it.
3. **Test run.** `elaichi__automation__dry_run` over MCP runs the latest draft against real data. In the console, it is "Test run (changes nothing)" in the Run now dialog.
4. **Publish.** Publishing turns the draft into a numbered version. It is refused while validation finds errors.
5. **Turn on.** A separate step. Until then, no trigger fires.

During a test run, nothing that writes is sent. Tool calls that write, collection writes, knowledge writes and state writes are recorded as what would have been called. A notify step sends nothing. Reads are real, though: tools that only read are called for real, as the person running the test.

A webhook trigger in a draft already has its address. Deliveries to it are kept as samples, up to five per trigger for seven days. A test run can replay one as the payload. If a published version misbehaves later, Details > Versions > "Restore this version" makes an earlier one live again.

## One bill and one set of rules for connectors, workflows and AI

Black puts 650+ connectors, workflows, collections, dashboards and the AI that drives them in one place. One set of rules and one bill cover all of it.

A workflow calls connectors and writes rows to a collection, a shared table. A dashboard reads it, and a knowledge base answers questions. Claude, ChatGPT, Cursor or any MCP client builds, tests and reads all of it at https://api.elaichi.ai/mcp.

The Elaichi Agent works beside them in the console and in Slack. It runs on the organization's own keys from the AI providers it sets up in Settings > AI models.

Every connected-tool call answers to the same roles and restrictions. Elaichi checks them at every place a member can reach a connector or tool, including listing, connecting, advertising, executing, the final outbound-request check and opening a stored tool file. A workflow runs as its owner, under the owner's restrictions. The audit log keeps one entry for each connected-tool call that reaches execution (a call refused earlier writes none). Spend controls then cap what all of it may cost or pay. It all lands on one bill: seats, plus usage pooled across the workspace.

## Walk-through: Jake Morgan caps what agents can pay

Jake Morgan runs finance. He wants the payables workflow capped, with a second pair of eyes on large payments. Emily Carter, a Member in operations, owns the workflow.

1. An Org Owner gives Jake the Billing Admin role. He takes no paid seat and holds spend:manage and billing:manage.
2. In Governance > Payment approvals, Jake adds the payables connector's send-money tool to the payment tools list.
3. For US dollars, he sets payments above $1,000 to need one approval, and above $5,000 to need two. He names himself as a default approver.
4. He caps the tool at $25,000 a month across every workflow, and $10,000 per payment.
5. In Settings > Billing, he sets the usage budget. Emily sets a run-time limit on her workflow.

Each change to the policy, tools or caps needs Jake to confirm it is him with his passkey. The budget does not.

Emily has Claude draft and test-run the workflow. Reads pull real open bills, and payment calls are recorded, not sent. She publishes and turns it on. Real runs act as Emily, with her connections and her restrictions. They are limited to the tools the published version declares.

Then two payments come through:

- **$3,200.** It waits for one approval. Emily owns the workflow, so she cannot approve. Jake approves on the Approvals page and confirms it is him.
- **$12,000.** It is over the $10,000 per-payment cap, so it fails at once with amount_over_transaction_limit. Elaichi does not retry it.

No AI client in this story can raise a cap or answer an approval.

## What does Black cost, and how is usage billed?

Black lists at $24 per user per month in US dollars, or $18 per user per month billed yearly ($216 a year). These are US-dollar list prices; see [pricing](/pricing/) for the price in your country. You pay per user, never for the AI apps working for them. Billing Admins, Auditors and Guests take no seat.

Usage is billed past a free monthly allowance of 1,000 run minutes and 1 GB-month of collection storage. A GB-month is 1 GB stored for a month. The allowance is pooled across the organization, not per seat. It resets on the 1st (UTC) and does not roll over.

Past the allowance, run time costs $0.02 a minute and storage $5 a GB-month in US dollars. A workspace billed in another currency pays a set rate in that currency.

Run time counts only the time a run is working: the tool calls it waits on and its agent steps. Time waiting for an approval, in a wait step, on a called workflow or held at a usage limit is free. Storage is sampled once a day (UTC).

Usage above the allowance is invoiced each time it reaches $20 in a month, and the rest at month end. The threshold counts usage only, never seats. When the card paying for seats was issued in India, usage is invoiced by email once a month instead, with no threshold. It is paid on [Stripe's hosted invoice page](https://docs.stripe.com/invoicing/hosted-invoice-page).

The 14-day free trial is the Black plan itself, with no card to start. Every Black feature is on, including workflows, collections, dashboards, knowledge bases, spend controls and the Elaichi Agent. Its one limit is the free monthly usage, 1,000 run minutes and 1 GB, a hard stop until you buy Black. An ended trial moves to the free Personal plan and deletes nothing. A paid Gold workspace upgrades in place from Settings with "Upgrade to Black", a prorated swap of the seat price.

## When you may not need Black's spend controls

You may not need them if your agents only read and write through Claude, ChatGPT or Cursor, and nothing runs on its own. Gold covers that, at $15 per user per month in USD, or $10 per user per month billed annually. Gold has no workflows, so it has nothing to meter and no payment tool to cap.

Black's workflows also stop short in two places. Elaichi fetches no web page for a workflow or the Agent. No trigger fires on an event inside a connected app without a webhook. If your process needs either, a general-purpose automation tool may fit better. The [Elaichi comparison posts](/blog/elaichi-vs-zapier/) show where each fits.

## Read more on Black, workflows and pricing

Spend controls make the most sense beside the rest of Black. The [Black plan overview](/blog/elaichi-black-plan/) covers the whole of it. The [workflows post](/blog/elaichi-workflows/) goes deeper on triggers, steps and versions. Browse payment tools in the [connector catalog](/connectors/).

To try every Black feature for 14 days with no card, [start the Black trial](https://app.elaichi.ai/signup). You can also compare plans on the [pricing page](/pricing/).

## FAQ

### Can an AI agent change its own spending limits in Elaichi?

No. Elaichi's spend controls are read-only for every AI client and for the Elaichi Agent. Changing them needs the spend:manage permission. Among the built-in roles, only Billing Admin, Org Admin and Org Owner hold it. The usage budget needs billing:manage. Over MCP, the four elaichi__spend__ operations are reads only. Changing the payment policy, the payment tools list or a payment cap also needs the person's own signed-in session. It needs a fresh step-up confirmation too.

### What happens when an Elaichi workflow reaches a usage limit?

At a hard limit, Elaichi refuses a manual run or a retry with 409 usage_limit_reached, and skips a scheduled run. A run started by a webhook, a Slack message or reaction, a collection row change or another workflow's run is held in the queue. A run already going stops before its next step until the limit resets or is raised. It fails if it is still held after 72 hours.

### How do payment approvals work on Elaichi Black?

An admin lists the tools that move money under Governance > Payment approvals. A workflow step that calls one must declare the amount, currency and payee. The payment policy sets, per currency, the amounts above which a payment needs one or two approvals. With no policy, every payment needs one. Neither the person who started the run nor the workflow's owner can approve, and two approvals come from two different people. Approvers answer on the console's Approvals page, never from Slack. A rejection stops the run with no money moved.

### Does testing an Elaichi workflow cost run time?

No. A test run on Elaichi Black costs no run time. It runs the latest draft against real data, as the person who starts it. Tools that only read are really called. Writes, collection writes, knowledge writes and notifications are recorded as what would have been sent, and never sent. Publishing and turning the workflow on are separate steps that come after.

### Does the Billing Admin role take a paid seat in Elaichi?

No. Billing Admin is a free seat in Elaichi, like Guest and Auditor. It holds exactly four permissions: billing:view, billing:manage, spend:view and spend:manage. It holds no organization or product permission, so a finance lead can own spend controls without a paid seat.

## Read next

- [Human approval for AI agent actions: the layers](/blog/human-approval-for-ai-agent-actions/) — Human approval for AI agent actions comes in layers: a prompt for the person asking, then the role rules, frozen values and requests an admin decides.
- [Lock AI agent tool arguments, like a wire's payee](/blog/frozen-parameters-wire-transfer-receiver/) — Lock AI agent tool arguments with frozen parameters: Elaichi removes the field from the model's schema and writes your value over whatever the call sends.
- [Read-only auditor role setup in Elaichi](/blog/auditor-seat-for-compliance-reviewers/) — The read-only auditor role setup in Elaichi: assign the free Auditor seat, see what its 12 view permissions open, and learn what the role cannot do.