# Alchemist Budgets and Costs

How ticket cost estimates are produced, how the per-ticket budget and cost gate work, and where to see spend.

---

Every ticket on the Alchemist platform runs under a dollar budget, and you see a cost estimate before you even dispatch it. This guide covers where that estimate comes from, what happens if a ticket's plan needs more than its budget, and where to check spend. For the ticket lifecycle itself, see [Alchemist Tickets](/docs/guides/alchemist-tickets).

## The pre-dispatch estimate

When you fill out the ticket dialog, the dashboard fetches a cost estimate for that ticket before you click dispatch. It shows two numbers: a typical cost and a high-side cost, for example "~\$4.50 (up to \$9.00)".

- **Typical** is a central estimate built from recent, similar tickets that actually completed (historical ticket cost, once enough samples exist for your project or globally); it falls back to a calibrated static estimate when there is not enough history yet.
- **High** is a more conservative, higher percentile of that same distribution. It exists so the dashboard can also show your **projected balance**, that is, what your credit balance would look like after this ticket if it ran at the higher end, so you are not surprised mid-ticket.

Investigation tickets (read-only, no code changes) are priced far lower than build tickets (feature, fix, refactor, integration, verification, schema-evolution), since a build ticket's graph does substantially more work.

This is a preview, not a hard cap: the actual bill is metered from real usage as the ticket runs, shown live on the ticket detail page.

## The per-ticket budget

Every ticket also has a budget cap, a dollar ceiling for that ticket's whole graph. You see it as the **Budget** field next to **Cost** on the ticket detail page. Most tickets never come close to it.

## The cost gate: what happens if a ticket needs more

Occasionally, the plan for a ticket's graph genuinely needs more than the ticket's budget allows, for example a larger piece of work than expected once the agent has actually looked at your codebase. When that happens, the platform does not silently let the ticket overspend, and it does not silently fail it either. The ticket parks in an **awaiting budget approval** state and asks you to approve a specific, larger amount before anything more runs.

From the ticket detail page you get three options:

- **Approve**: requeues the ticket and re-plans it under the raised cap, resuming from where it left off.
- **Reject: re-plan within cap**: gives the ticket one bounded attempt at a smaller graph that fits the original budget instead.
- **Reject and fail**: terminally fails the ticket, with the decision recorded on it.

If you do not respond, the ticket does not stay parked forever: after a timeout it is treated the same as a decline and terminally fails, so a forgotten approval never quietly burns your credits by sitting open.

> **Note:** A budget exception is about the total size of the plan, not about something going wrong. It is your project's way of asking "this is bigger than expected, is that still worth it to you?" before spending the money.

## Seeing your spend

- **Per ticket**: the ticket detail page shows live running cost (the **Cost** field) right next to its budget, updating as the ticket's nodes run.
- **Per project**: your project's Usage view shows a spend-over-time chart you can split by model, node kind, or category, plus a breakdown of recent spend and your highest-cost tickets. It is read straight from the same billing ledger that produces your invoice, so it always reconciles with what you are actually charged.

## Querying costs programmatically

If you are wiring Alchemist into your own tooling or a Chipp agent, the platform exposes cost data over MCP: `get_credit_balance` for your current balance, and `get_project_cost` / `get_ticket_cost` for cost breakdowns by project or by ticket. See the [Alchemist Cloud Tickets MCP](/docs/guides/alchemist-mcp-server) guide for the full tool reference and how to connect.

## Next steps

From here: [Alchemist Ticket Dependencies](/docs/guides/alchemist-ticket-dependencies) for structuring multi-ticket work, or back to [Alchemist Tickets](/docs/guides/alchemist-tickets) for how a single ticket executes.