Spending and budget

Organization → Spending sets one number: a monthly LLM cap in USD.

Set it before anyone starts running investigations. It takes ten seconds and it is the only backstop against a prompt loop that costs money.

Setting the cap

Type a positive number and save. Leave the field blank and save to remove the cap (unlimited).

The current cap is shown above the field. A blank input with a cap already set is not "unlimited" until you actually save it.

What happens at the cap

The cap is enforced on the desktop, in three places, and it fails gracefully in each:

Background triage checks the cap before starting a run. A ticket for an over-budget organization is deferred and retried later with backoff, not failed. Nothing is lost; work resumes when the cap resets or is raised. Only that organization's tickets are affected, never the whole queue.

Console and ticket chat check before opening the response stream, so an over-cap request gets a plain refusal — with the cap and the month-to-date spend in the message — rather than half a streamed answer.

A long multi-turn run re-checks on every API call, so a run that crosses the cap mid-flight is stopped rather than allowed to finish.

Why there is no spend total on this page

Usage telemetry never leaves the desktop. The portal sets the cap; each member's install meters against it and knows the month-to-date figure.

The full picture — totals, per-model p50/p95 latency, a per-task split, a daily cost chart, and the 50 most recent calls with links back to what caused them — is on the desktop's Usage page. See History and usage.

Picking a number

There is no universally right cap, but there is a decent method:

1. Set a deliberately low cap for the first week — low enough that you expect to hit it.
2. Look at the desktop Usage page's per-task split at the end of it.
3. Multiply out for your real ticket volume and set the real cap with headroom.

The per-task split is the useful part. It is common for classification — which runs on every incoming ticket, whether or not anyone reads the result — to be a larger share than expected, and that is a signal to reduce the number of enabled playbooks rather than to raise the cap.

Levers other than the cap

The cap stops spending. These reduce it:

• Narrow playbook data sources. Fewer systems means fewer agent iterations.
• Sharpen triage instructions. A playbook that names the table to check first finishes in fewer turns than one that says "investigate".
• Prune playbooks. Every enabled playbook is a candidate the classifier evaluates.
• Choose the model deliberately. A cheaper model that needs three times the iterations is not cheaper.

Audit

Changing the cap writes an org.update audit entry with the before and after values.