How usage is counted

Every AI request Tale makes for your organization is recorded once, against one person, and measured against the budget rules that apply to that person. This page explains who that person is for each kind of work, which limits the work counts against, and where you find it in Usage analytics. Members see their own share under Settings > Usage.

What counts as usage

Tale records a request whenever a model or a metered service runs for your organization: a chat reply, including a regenerated or edited one and both sides of a model comparison; the short model call that names a new chat; a rewrite with Improve with AI in the inbox; the model call of an automation's llm step; a turn of a managed agent working on a task or inside an automation; an image such an agent generates; voice output; the transcription of an uploaded recording or of a dictation; the embeddings that index knowledge and those every knowledge search asks for; and a call to the model endpoints with an API key. Each record carries the tokens or units used — for a transcription, the minutes of audio — and the cost estimated from the provider's list price at that moment; for a model endpoint call, it is the cost the model gateway measured.

Tale also counts every call it makes through a connector — the assistant's search and web tools, an agent's or an automation's connector step, an email sent from the inbox — as a connector call, at no cost. A connector call is never a request: request limits count model requests alone.

Who a request counts against

The rule is the same everywhere: a request counts against the person who asked for the work. The door the request came through, such as the app, the REST API, the MCP endpoint, or the model endpoints, changes nothing about who that is.

A retry of an agent run continues the run its starter kicked off, so its usage stays with that person and with the API key the run was started with. When a comment that mentions a working agent restarts its turn, the rest of that turn counts against the comment's writer, and against the API key the comment was written with. When an integration uses an API key to act for another member, the run counts against the member acted for, and the key's own limit counts it too.

Work in a project also counts toward that project, whoever asked for it: the project's chats, with their titles, the answers read aloud, the recordings transcribed in them, and the assistant's tool calls and searches; the files indexed for it; the runs of its agents and the agent and llm steps of automations run in it, with the images they generate; and the calls made with the project's own API keys. A run that names no project, of an automation installed in several projects, counts toward each of them; an automation installed in no project counts toward the organization alone.

Chat turns, voice attempts and automation model calls keep the projects recorded when admitted. Moving the chat or changing an automation’s project installations while work is running does not move its reservation or eventual booking. An attempt admitted without a project stays outside project budgets.

An API key an Admin made for a member counts against that member, like the member's own key. A key that belongs to a team, a project, or the organization (API keys) is not a person: what it asks for counts against the key itself. Usage analytics shows it as a row of its own under Per-user usage, under the key's name with its team, project, or organization beneath, and never counts it as an active user. A team's key also counts toward its team's usage.

Which limits apply

• Personal, team, and role limits bind the person a request counts against. A run a schedule, a webhook, or an event started has no such person and is not measured against any of them. Neither is a team's, a project's, or the organization's own key, except that a team's key is held to its team's limit.
• Organization limits bind every request, including trigger-started runs.
• API-key limits bind the requests authenticated with that key: the chat messages it sent, its model endpoint calls, and the runs it started.
• Project limits bind the work in that project, whoever asked for it, including runs a trigger started.

When a limit is reached, Tale refuses the next request before it runs and names the limit. A managed agent turn is refused at its start; a turn already running keeps the allowance it was given. A turn served by a provider subscription the organization pays for apart from Tale costs nothing per call: it counts as one request, with the tokens its agent reports, so a request or token limit refuses it at its start and a cost limit does not. An image the agent asks for during its turn is checked on its own before the image model is called, so a reached limit refuses the image while the turn continues. The image also draws on the allowance of the turn that asked for it. An automation's llm step is checked before each model call: a call a limit refuses fails the step with budget_exceeded, and its error names the limit; the run fails with it unless the step's onError is continue. The step reserves its estimated prompt and permitted output at the catalog price, plus one request, until settlement. Concurrent calls therefore see each other’s reservations. If the provider’s outcome is unknown, Tale books the saved estimate once instead of silently freeing it; a retry is a new admission. A chat's title, a rewrite with Improve with AI and a transcription are checked the same way before Tale calls the model, against an estimate of the most the call may cost — for a written reply, its prompt and the longest answer the call allows; for a transcription, the recording's length, its long silences cut, at the model's price per minute — and hold that amount while the call runs. A refused title is no error: the chat is named from its first message instead, without a model call. A transcription model the catalog has no per-minute price for — one billed by tokens, or an endpoint that publishes no price — counts toward request limits only, at no cost. A refused transcription reads Usage limit reached; choose Try again once the limit allows it. A refused dictation says the limit was reached, and a video link is refused before its download. Each embedding request is checked the same way. A knowledge search a limit refuses says so, and never answers "nothing found"; indexing waits instead: a document shows Waiting for a usage limit, a website keeps its pages without search by meaning, and both resume by themselves within the hour after the limit resets or is raised. A chat reply also holds each further round of its tool use as the round starts. How rules combine covers the case of several rules applying to one person.

Voice output holds its estimated cost and one request while pending. A reserved attempt that fails or has an unknown outcome records that estimate once, including failures before the provider call; this is conservative accounting, not confirmation of a charge. A retry includes the earlier estimate when checking the remaining budget.

Three situations worth knowing

A teammate mentions your agent in a task comment or a task description. Posting the comment or saving the description starts a run, and that run counts against the teammate who wrote it, not against you as the agent's creator.

A scheduled automation spends every night. Its runs appear on the Automations (triggers) row. They never raise anyone's personal usage or the active-user count, and only the organization's limits can stop them, or a project's limits when the automation runs in a project. Set an organization or project cost or request limit when you need a ceiling for them.

An integration uses an API key on behalf of a member. The member's personal and team limits see the run, and so does the key's limit. Two ceilings apply, and the stricter one refuses first.

What members see

Settings > Usage lists every limit that applies to the signed-in member with its current usage: the chats they sent, the voice output they requested, the model endpoint calls they made, and the agent and automation runs they started, whichever way they started them. Shared team and organization limits appear there too, because they can be reached before a personal one. A project's limit does not appear there: a banner in the project's chats warns about it once its threshold is passed, and a request it refuses names it.