# What Brain meters and which limits apply Brain measures five things and reports them for billing. This page names each meter, says which of your actions consumes it, and states what happens when your allowance runs out. It carries no prices — those belong to your organization's plan, which the platform documents. ## The five meters | Meter | Unit | How it adds up | |---|---|---| | `llm-tokens` | tokens | Summed over the period | | `llm-input-tokens` | tokens | Summed over the period | | `llm-output-tokens` | tokens | Summed over the period | | `embedding-tokens` | tokens | Summed over the period | | `memories-stored` | items | The latest reading, not a sum | ### Never add the three token meters together `llm-tokens` is the **total**. `llm-input-tokens` and `llm-output-tokens` are that same total split into its two halves: ```text llm-tokens = llm-input-tokens + llm-output-tokens ``` Every language-model call Brain makes writes all three: the total once, and the input and output parts separately. The split exists because input and output are priced differently, so both the whole and the parts have to be measurable. It is not extra usage. **Adding all three together double-counts every token Brain has ever used.** For one number, use `llm-tokens` alone. For the breakdown, use the input and output meters and ignore the total. Never mix the two. For the same reason, nothing Brain reports back to you ever sums across meters — the totals it gives you are always per meter. ### What each meter counts - **`llm-tokens`, `llm-input-tokens`, `llm-output-tokens`** — the language-model work Brain does on your behalf. Text sent to the model is input; text it returns is output. Brain uses a model when it has to understand or rewrite something rather than just store it: extracting facts and entities from what you add, ingesting a document a source brought in, and the two cognition mechanisms — the digest and the sweep. See [how memory maintains itself](/brain/cognition). - **`embedding-tokens`** — turning text into the vectors that make search work. Charged when a memory is written and when incoming material is indexed, so that it can be found later. Embedding and language-model work are separate: one operation can consume both. - **`memories-stored`** — how many memories your product holds. A level, not a running total, so a larger figure means more stored right now rather than more consumed since the start of the period. It is read once a day, at 04:00 UTC, and counts every active memory across every scope of the product. Deleting memories brings the next day's reading down. See [what a memory is](/brain/memory-model). ### Which actions consume what Token meters follow the work, not the request: whatever causes Brain to call a model or compute vectors consumes them. | What you do | What it typically consumes | |---|---| | Add a memory | Embedding tokens, and language-model tokens for extracting entities and relations | | Update a memory | The same as adding | | Delete a memory | Nothing | | Search memories or the knowledge graph | Embedding tokens for the query | | A daemon run | Embedding and language-model tokens, in proportion to how much new material the source produced | | A batch submission from a source | The same, proportional to the number of files | | The cognition digest | Language-model tokens | | The cognition sweep | Language-model tokens | | Create or restore a snapshot | Nothing. See [back up and restore memory](/brain/backup-and-restore) | Nothing here is charged twice: a daemon run that finds nothing new does no work and consumes nothing. ## Reading your usage Brain keeps its own daily ledger for your product and reports it back to you. This is separate from the platform's billing figures and answers a different question — what this product used, day by day. It is reported by Brain itself, not shown on a page; see [look up a Brain tool](/reference/mcp-tools). A usage report covers a whole number of past days: **30 by default, 90 at most**. Days are UTC. It returns: | Part | What it holds | |---|---| | Rows | One per day, per meter, broken down by the model that did the work, whether it ran immediately or as part of a batch, and what the work was for. Each row carries the number of tokens, how many separate pieces of work made it up, and how many of those failed to be delivered to billing. | | Totals | The same figures rolled up per meter over the whole window. Per meter, never across meters. | | Plan | Your organization's plan and, for each meter, the limit, how much has been used this month, how much remains, and whether the meter is unlimited. If those cannot be read at that moment, the report says so explicitly and still returns your own daily figures. | `memories-stored` is deliberately absent from the daily ledger. Because it is a level rather than a sum, adding up daily readings would produce a meaningless number. ### Two scopes, two answers Your own figures are **per product**. Your plan and its allowances are **per organization**. In an organization running several products the two will not match, and that is correct: the plan counts everything the organization used, your report counts what this one product used. Every report says so. ## Limits and what happens at the limit Allowances live on your organization's plan, not in Brain. Each meter has either a numeric monthly limit or no limit at all, and the platform tracks how much of it has been used this month. Only `llm-tokens` is enforced. Embedding tokens and stored memories are measured and billed but never block anything. Enforcement runs in one of three modes. Which one applies is set for the installation, not by you: | Mode | What it does | |---|---| | Off | The allowance is not checked at all. | | Advisory | The allowance is checked, going over it is recorded, and the work proceeds anyway. This is the default. | | Blocking | The allowance is checked before billable work starts, and work is refused once it is exhausted. | Under blocking enforcement, being over the limit is not a single uniform error — each kind of work stops in the way that is safe for it: | Work | What happens when the allowance is exhausted | |---|---| | Adding or updating a memory | Refused, with a payment-required error naming the limit | | Deleting a memory | Unaffected — deleting is never gated | | A daemon run | The run is skipped and finishes as done, having ingested nothing | | A batch submission | Finishes with nothing submitted, recording that billing blocked it | | The cognition digest and sweep | The scheduled pass is skipped silently and no run is recorded | Skipped daemon and cognition passes are not queued up for later. The next scheduled pass runs normally once there is allowance again, and it picks up whatever accumulated in the meantime. Checks fail open by design. If the allowance cannot be read — billing is slow to answer or unreachable — Brain proceeds rather than blocking your product, and records that it could not check. ## Delivery of usage records Each measurement is sent to billing as it happens rather than being batched up. If a record cannot be delivered it is retried for about eighty minutes before it is set aside. The count of records that failed to be delivered appears in your usage report, per day and per meter, so a persistent non-zero figure there is worth reporting. Work that cannot be attributed to a product is dropped rather than billed to the wrong one. ## Next steps - [Back up and restore memory](/brain/backup-and-restore): snapshots are not metered and consume none of these allowances. - [Ingest a source on a schedule](/brain/daemons): the load mode of a daemon is where volume turns into tokens. - [How memory maintains itself](/brain/cognition): what the digest and the sweep do with the language-model tokens they spend. - [Read what a memory is](/brain/memory-model): the scopes that `memories-stored` counts across. - [Look up a Brain tool](/reference/mcp-tools): the call that returns your usage report.