Overview

Usage & Spend is Ejento AI's mechanism for keeping the cost of AI usage inside your organization visible and under control. Rather than discovering what was spent at the end of the month, you set monthly budgets up front and decide what should happen when someone reaches one.

Core Concept

Every query your users run has a real model cost. When a query completes, that cost is attributed to two things at once: the user who ran it and the assistant it ran against. Costs are derived from the query's token counts and the model's pricing, which is why they are described as estimated.

On top of that record sit two things:

Limits: A monthly budget in USD, for the organization and for each person

Enforcement: What happens when someone reaches theirs: a warning, or a block

Everything is scoped to a calendar month (UTC). At the start of each month spend returns to zero and anyone who was blocked can work again, while the limits themselves carry over untouched until you change them.

Note: Out of the box nothing is capped and nothing is blocked. Spend is measured from day one, but until you set a limit there is nothing to reach.

What Is Measured

Because each query's cost is recorded against both the person and the assistant, a month's spend can be read from more than one angle:

Dimension	Question it answers
By user	Who is spending, and how close each person is to their own limit
By assistant	Which assistants the money is going to
By model	Which underlying models the spend is made of

The Three Limits

A limit is a monthly amount in USD. There are three of them, and between them they answer two questions: how much may the organization spend in total, and how much may any one person spend.

Limit	Applies to	Typical use
Organization limit	The organization's total spend for the month.	The overall budget.
Default user limit	Every user who has no limit of their own.	The baseline everybody starts on.
Per-user limit	One named user, overriding the default.	The exceptions: a power user who needs more, or a contractor who needs less.

Limit Resolution

For any given person, Ejento AI asks in order: does this person have a limit of their own? If so, that is the one that counts. If not, the default user limit applies.

Two things follow from that, and both are worth knowing before you start setting limits:

A per-user limit wins by existing, not by having a value. Setting someone to Unlimited creates a per-user limit that happens to be unlimited, and it still beats the default. That makes "set this user to Unlimited" and "remove this user's limit" two genuinely different actions: the first exempts them from the default, the second puts them back on it.

The organization limit is never replaced by a personal one. The two stack. A user set to Unlimited is still stopped once the organization reaches its own limit.

"The per-user limit decides this person's budget; the organization limit decides everyone's ceiling. A query has to clear both."

Enforcement

The enforcement mode decides how firmly a user's own limit is held.

Mode	A user who reaches their own limit
Warn only (default)	Is told they have reached it, and carries on working. Spend keeps counting.
Block until reset	Cannot run new queries until the month resets, you raise their limit, or you approve an increase request.

The mode governs a user's own limit only. The organization limit always blocks, in every configuration; once the organization reaches its total budget everyone stops, including users set to Unlimited.

States

Every user, and the organization itself, carries a state.

State	Meaning
Active	Nothing is restricting spend; under the limit, or Unlimited.
Warned	The user has reached their own limit while the mode is warn only. They are told, and they carry on spending.
Blocked	Spend has reached a limit that is being enforced.

What Users See

Below their limit, none of this is visible to them. After that:

Warned: they are told they have reached their limit, and can keep working.

Blocked: they cannot start new queries, and are told whether it was their own limit or the organization's that stopped them.

In case they are blocked by their own limit and organization limit is yet to be reached, they can request limit increase rather than wait for the month to reset, and write a short note explaining why.

Limit Increase Requests

A user who has reached their own limit can ask for more rather than waiting for the month to reset. A request carries the amount asked for and an optional note explaining why, which the admin deciding it can read.

Status	Meaning
Pending	Filed by the user, waiting for an admin decision.
Approved	Granted. The user's limit is raised for the rest of this month.
Denied	Turned down. The user's limit is left exactly as it was.

The rules that govern the flow:

One open request per user per month. A user with a pending request cannot file a second one.

A request must ask for a genuine raise. The requested amount has to be strictly above the user's current limit.

An approval replaces the ceiling, it does not add to it. If a user on a $50 limit is approved for $65, their limit for the month becomes $65 not $115.

And it lasts only for the month it was granted in. At the reset the grant stops applying and the user falls back to their standing limit. That is intended: an increase is relief for one month's overrun, not a permanent change. To make a raise permanent, edit that user's per-user limit instead.

Quick Reference

Rule	Detail
Period	Calendar month, UTC. Spend resets to zero automatically; limits persist.
Limit precedence	Per-user limit, else default user limit. A per-user limit wins by existing.
Organization limit	A hard cap in every configuration, on top of whatever the user's own limit is.
Enforcement mode	Governs a user's own limit only. Does not affect the organization limit.
Approved increase	Replaces the limit, for that month only. Reverts at the reset.

Core Concept#

What Is Measured#

The Three Limits#

Limit Resolution#

Enforcement#

States#

What Users See#

Limit Increase Requests#

Quick Reference#