> For the complete documentation index, see [llms.txt](https://help.tellius.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.tellius.com/settings/kaiya-and-ai/kaiya-credits.md).
# Kaiya Credits
Every action Kaiya performs costs credits. Under **Settings → Intelligence → Kaiya & AI → Kaiya Credits,** admins can see where those credits are going, cap what individual users can spend, and set the price of each workflow.
The page has four tabs. **Overview** and **Drill-down** are read-only reporting. **Limits & Alerts** and **Configuration** change behavior.
{% hint style="warning" %}
The difference between this page and **My Kaiya Credits**, which sits at the top of the Settings sidebar. **My Kaiya Credits** shows an individual their own consumption. Kaiya Credits is the workspace-wide administrative view.
{% endhint %}
### Overview
Shows where credits are going across the workspace: usage, trends, the biggest spenders, and the workflows driving the most cost.
#### **Filtering**
Choose from three preset ranges - **This month**, **Last 30 days**, **Last 90 days,** or set **From** and **To** dates directly. An optional **User** dropdown narrows everything to one person. Click **Apply** to run the filter; **Refresh** re-pulls current data without changing the filter.
#### **Summary metrics**
Four cards sit below the filter, each showing a figure for the selected window and its change against the prior period:
| Card | What it counts |
| ------------------ | ------------------------------------------------------------------------------------------------------- |
| **Credits used** | Total credits consumed this period. |
| **Total runs** | Message events completed. |
| **Billable turns** | Question-to-deliverable cycles — the turns that actually produced something and were therefore charged. |
| **Active users** | Unique users with any activity. |
{% hint style="warning" %}
The distinction between **Total runs** and **Billable turns** is that not every run is billable; only turns that produced a deliverable are charged. A gap between the two figures is normal.
{% endhint %}
#### **By query type**
A donut chart breaking credit share across workflow types, with each type's credit count and percentage listed alongside. Toggle between **Chart** and **Table** views. This is the fastest way to see which workflow is driving spend — an expensive workflow used occasionally can outweigh a cheap one used constantly.
#### **Daily trend**
Credits per day as a stacked bar chart, colored by query type, so you can spot spikes and trace them to a specific workflow. Also toggles between **Chart** and **Table**.
#### **Top consumers**
A ranked table of users by credits spent in the window, showing **Credits**, **Turns**, **Events**, and **Last activity**. Sort by any column. Activity that has no user attached to it is excluded from this table, so the total here can be lower than the **Credits** **used** figure above.
### Drill-down
Audits a single conversation end to end — every billable event, every credit charged, and every turn that produced a deliverable.
Paste a **conversation\_id (UUID)** into the field and click **Load** to see that conversation's full metering history. Use this when a user disputes a charge or when a single conversation shows unexpectedly high consumption and you need to see exactly what was billed.
### Limits & Alerts
This page tracks who is approaching or has exceeded their credit ceiling, and this is where per-user caps and alert thresholds are set.
Three counters sit at the top, each a count of users:
* **Custom limits set:** How many users have an explicit monthly cap of their own, rather than falling back to the default per-user limit. Use it to check how much of your user base is individually managed.
* **At or over alert threshold:** How many users have consumed enough of their cap to reach the alert threshold percentage. These are the people to watch; they haven't been cut off, but they're on track to be. Their rows are highlighted in the table below.
* **Over their limit:** How many users have exceeded their cap outright. Their rows are flagged in the table below.
Read the three together as a funnel: how many users are individually capped, how many of those are close, and how many have gone past.
#### **Default per-user limit**
The monthly credit cap applied to any user without an explicit limit of their own. Enter a figure under **Monthly limit (credits)** and click **Save default**. Leave it unset for unlimited access.
#### **Add or update a user limit**
Pick a user from the dropdown, set their **Monthly limit**, and click **Save limit**. This overrides the default for that person. Saving a limit for a user who already has one replaces the existing cap rather than adding to it.
#### **Email Alerts**
Sends an email when workspace credit usage crosses a threshold.
* **Trigger threshold (%):** the usage percentage that fires the first alert.
* **Step (%):** the interval at which subsequent alerts fire after the first. With a threshold of 80 and a step of 5, alerts go out at 80%, 85%, 90%, and so on.
* **Recipient email:** where alerts are sent.
Click **Save** to apply, or **Disable alerts** to switch off email notifications entirely.
#### **Per-user credit limits table**
Lists every user with their **Used** total, **Limit**, **Usage**, and **Status**. Search by name or email to find someone quickly. Rows above the alert threshold are highlighted, and rows over the limit are flagged.
Click any user to open a detail modal showing their credits used, monthly limit, percentage of limit consumed, and a health status. The modal has two views:
* **By Workflow:** a donut chart breaking their spend down by workflow type, with credits and percentages listed. Hovering a segment shows its exact figures.
* **Chronological:** their daily usage over the period as a stacked bar chart, colored by workflow.
### **Configuration**
Sets the price of every billable Kaiya workflow. Edits go live the moment you save. This tab is restricted to superUsers.
#### **Workspace credit bundle**
The monthly cap shared across the whole workspace. Set **Total credits** and click **Save bundle**. New requests are paused once this cap is reached, so this is a hard ceiling on workspace spend, not a warning threshold. Treat it differently from the per-user limits on the **Limits & Alerts** tab, which only govern individuals.
#### **Multi-step workflows**
Some workflows involve several turns of iteration before producing a deliverable. These are priced in three parts:
* **Setup charge:** charged on the first turn that produces a deliverable.
* **Included follow-up:** the number of follow-up turns covered by that setup charge at no extra cost.
* **After included:** the per-turn rate for every turn beyond the included allowance.
The following are the defaults column as setup / included / after:
| Workflow | Setup | Included | After |
| ------------------------ | ----- | -------- | ----- |
| Kaiya Apps | 25 | 10 | 3 |
| Agentic Mission Creation | 60 | 7 | 5 |
| Data Architect | 50 | 15 | 5 |
#### **Single-action workflows**
These are charged a fixed amount each time the action completes successfully. A failed action isn't charged.
| Workflow | Credits per use |
| ------------------- | --------------- |
| Text-to-SQL | 1 |
| Complex Text-to-SQL | 3 |
| Deep Insight | 60 |
| Agentic Mission Run | 15 |
| PDF Export | 5 |
| PowerPoint Export | 5 |
| Word Export | 5 |
#### **Saving and resetting**
Each row has its own **Save** and **Reset** buttons and changes are applied per workflow, not for the whole table at once. A **Default** badge next to a workflow name indicates it's still at its shipped value, and the **Defaults** column always shows the original figures, so **Reset** returns that row to them.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://help.tellius.com/settings/kaiya-and-ai/kaiya-credits.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
