> ## Documentation Index
> Fetch the complete documentation index at: https://docs.textql.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Usage
> How compute usage is attributed
## Overview
To better understand the content of this page, be sure to read [Pricing](/core/admin/pricing) first. To summarize,
a sandbox bills 500 ACUs per hour while warm. "Warm" means within the time-to-live of the last activity: 1 hour for chat and playbook sandboxes, 24 hours for dashboards.
The usage chart in the console provides context into ACU usage and ties each ACU to an initiating member and a label.
This doc discusses the **Cost Center** and **Member** segments of the usage chart in detail.
## Labels
Labels follow a two part format, for example: `playbook:message` or `dashboard:manual_refresh`.
The first part, the base, describes what consumed the compute. The second part, the action, describes what triggered or extended the usage of compute. A base with no action is a system level touch.
### Bases
| Base | Meaning | Usage type |
| --------------- | ----------------------------------------- | ------------------------- |
| `chat` | a standard Ana conversation | compute hours, LLM tokens |
| `playbook` | a playbook run and any follow up messages | compute hours, LLM tokens |
| `feed` | feed / agent-initiated work | compute hours, LLM tokens |
| `slack` | conversation started from Slack | compute hours, LLM tokens |
| `sms` | conversation started from SMS | compute hours, LLM tokens |
| `dashboard` | a published dashboard's sandbox | compute hours |
| `app` | data-app compute | compute hours |
| `summary` | background chat-summary generation | LLM tokens |
| `observability` | background topic/observability analysis | LLM tokens |
### Actions
| Action | Applies to | Meaning | Attributed to |
| --------------------- | -------------------------------- | -------------------------------------------------------- | --------------------------------------- |
| `message` | chat, playbook, feed, slack, sms | you sent Ana a message (keeps the sandbox warm 1h) | sender |
| `view` | dashboard | you opened a dashboard (keeps it warm 24h) | viewer |
| `preview` | dashboard | you previewed a dashboard draft | viewer |
| `manual_refresh` | dashboard | you hit refresh on a dashboard | member |
| `manual_schedule_run` | dashboard | you ran a scheduled refresh by hand | member |
| `request` | app | you used a data app | member |
| `member_completion` | LLM usage | Ana answering you | member |
| `data_refresh` | dashboard | a dashboard reloaded its data | member if triggered by one, else system |
| `code_refresh` | dashboard | a dashboard re-ran its code | member if triggered by one, else system |
| `config_refresh` | dashboard | a dashboard was rebuilt after its settings changed | member if triggered by one, else system |
| `schedule` | dashboard | a scheduled refresh ran on its own | system |
| `auto_respawn` | dashboard | the system restarted a dashboard's sandbox | system |
| `rotation` | any | sandboxes roll to a new window every 4h | system |
| `tool_completion` | LLM usage | Ana working on its own (tools, agents, background steps) | system |
## How Costs Work
Whenever a sandbox is provisioned, it is tied to a base. The amount of consumption
during the sandbox's lifetime (before release) is credited to that base.
Each action is credited for the marginal warm time that is added because of it. As a result, segments never overlap
and total the sandbox's total warm time regardless of concurrent users. For example, if a dashboard is created at
12:00 AM (`dashboard:preview`) and the very first action following is a view at 3:00AM (`dashboard:view`), `dashboard:preview`
is credited for 24hrs (the initial warm window) and `dashboard:view` is credited for 3hrs. A `dashboard:manual_refresh` at 5AM
would be credited for 2 hrs. The logic above also applies to members.
LLM token usage works differently as there are no segments. Each completion is billed directly to the member and label it ran under.
## Reading It in the Usage Chart
* **Grouped / Granular** toggle: collapse to bases or show full `base:action` labels.
* **Stack by member and cost center**: see who drove usage within each category.
## Additional notes
* `non-attributed` is usage with no recorded member or label
* This document was written with the current setup of 1hr lease and extension for chats and sandboxes, 24hr lease and extension for dashboards. Should the lease and extension ever be able to differ (e.g. you can set 1hr lease, 30 minute extension), the amount of warm time would be the latest of the current time + extension and the current expired time. For example, if the current time is 3AM and the sandbox is set to expire at 4AM, an extension of 30 minutes following a `chat:message` would not change the release time as 3:30AM is earlier than 4AM.