> ## Documentation Index
> Fetch the complete documentation index at: https://notifizz.com/llms.txt
> Use this file to discover all available pages before exploring further.
# AI Credits
> The daily AI pool: what one credit buys, which actions consume it, what is free, when it refills, and exactly what stops when it runs out.
# AI credits
Everything the AI does for you — the orchestrator that turns an event into a working notification, the campaign copilot, the email agents — draws on a single **daily pool of AI credits** held by your organisation. This page says what one credit buys, what spends it, and what happens the moment it is empty.
Written for **Marketing and Product/Ops**, who spend most of them, and for **Dev**, because the same pool is what an IDE session over MCP draws on.
Pool sizes vary by plan and some plans are unlimited. Amounts live on [notifizz.com](https://notifizz.com); this page describes the mechanics.
## TL;DR
* **One credit = one AI turn.** Not one token, not one message — one run of the model on your behalf.
* **The pool is daily** and resets at **UTC midnight**. It does not roll over.
* **AI credits never touch your send volume**, and running out never stops a send.
* **A run that fails before producing anything is refunded.**
* Turns started from your IDE over **MCP draw on the same pool** as the dashboard.
* Empty pool: AI conversations are refused with the reset time; everything deterministic keeps working.
## What one credit buys
A credit is charged per **turn**: you say something, the AI thinks, uses its tools and answers. Length does not matter, and neither does how many tools it called along the way — a long turn and a short one cost the same one credit.
| Action | Cost |
| -------------------------------------------------------------------------------------------------------------- | ---------------------------- |
| A turn in a campaign's **orchestrator chat** | 1 credit |
| A turn with the **campaign copilot** | 1 credit |
| A turn with the **email agent** inside a notification's editor | 1 credit |
| An **AI edit of an email component** in the library | 1 credit |
| A **background orchestrator run** — the orchestrator picking up a message queued for it and running on its own | 1 credit |
| A **campaign creation or answer turn driven from your IDE over MCP** | 1 credit, from the same pool |
## What costs nothing
Plenty of the surface around the AI is deterministic, and deliberately free:
* **Reading a conversation.** Opening a campaign's chat history, paging back through it, and the little status badge on the panel.
* **Queueing a message for the AI** without running it. The credit is charged when the run actually happens, so navigating away before the panel resumes costs you nothing.
* **Approving a proposed flow.** Materialising what the copilot proposed is a deterministic action tied to your click, not a model decision — no turn, no credit. That holds for the dashboard and for the MCP approval tool.
* **Applying an action** the AI offered.
* **Escalating a failed review test run into the orchestrator chat.** The escalation itself is free; the diagnosis turn that follows is a normal chat turn and is charged.
* **Reading your balance.**
## Refunds
If a run errors out **before producing anything useful** — no text, no tool call — the credit is given back. A run that produced a partial answer before failing is not refunded: you got something.
Two details worth knowing:
* A refund is capped at your daily maximum, so it can never push the pool above its ceiling.
* If the UTC day rolled over between the charge and the refund, yesterday's pool is not resurrected — today's already reset.
## Renewal
The pool is **per organisation, per UTC day**, and resets at UTC midnight. The exact reset moment is shown next to the gauge and returned with the refusal when the pool is empty, so a client can display "back at …" rather than guessing.
Unused credits do **not** carry over — a daily pool is a rate, not a budget.
Two isolation properties are deliberate:
* **AI credits never draw on your send volume.** Burning the whole pool has no effect on how many notifications you can send.
* **Running out never stops a send.** Live campaigns keep firing, notifications keep going out.
## When the pool is empty
| Where | What happens |
| ---------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Dashboard chats (orchestrator, copilot, email agent, component editor) | The turn is refused before it runs, with the reset time. Integrators see HTTP `429` and `{ "code": "AI_CREDITS_EXHAUSTED", "resetAt": "…" }`. |
| MCP, from your IDE | The tool returns `ai_credits_exhausted` with a message telling the agent the turn did **not** run, when credits come back, and that deterministic tools still work. |
| A background orchestrator run | Skipped, quietly and safely. The message stays pending and runs the next time the panel is opened with credits available — nothing is lost. |
| Sends, live campaigns, deterministic tools | Unaffected. |
Nothing is half-done: a refused turn did not run at all, so there is no partial state to clean up before retrying.
## Where to read the balance
Two places:
* **The chat panel** shows a live counter — *credits left* — and refreshes it when a turn ends.
* **Billing & usage → *Usage* → Current period → AI credits**, which shows credits used today against the daily maximum, the reset time, and an all-time total.
The **all-time** figure counts from the day the platform started recording it. On an organisation older than that, a low number means "not counted yet", not "not consumed".
An organisation on an unlimited pool sees credits used today and the all-time total, with no denominator — consumption is still counted, there is simply nothing to run out of.
## FAQ
No. One turn is one credit, regardless of how long the answer is or how many tools the AI used to get there. What costs more is going back and forth — five clarifying exchanges are five credits.
Yes — the MCP campaign tools that actually run the copilot draw on the same daily pool as the dashboard, one credit per turn. The deterministic tools (reading a campaign's status, listing implementation tasks, approving a proposed flow) cost nothing, so a session that mostly reads is cheap.
If the pool was empty when the background run was due, the run is skipped and your message stays pending rather than being dropped. Open the campaign's chat panel once credits are back and it resumes from there.
No. The AI pool and your send volume are separate resources, and the AI pool never draws on the cross-channel total. An empty pool blocks AI conversations; live campaigns carry on sending.
Only if it produced something first. A run that fails before any output is refunded automatically — you do not have to ask, and the counter refreshes on its own.
Yes, and it can be raised for a single organisation without changing tier. The ceiling comes from your plan plus any bespoke adjustment — talk to your Notifizz contact.
Because a single, unambiguous reset instant is the only one a team spread over several time zones can agree on, and it is the same instant the interface displays next to the gauge. There is no per-organisation anchor to get wrong.
## See also
How AI credits sit alongside metered volume and stored resources.
The other limits — refused creations and dropped recipients.
What the credits are actually buying you.
The case for generating the orchestrator instead of writing it.