Usage and limits

5 min read

Use this section to understand and control what your agents consume, beyond billing.

Statistics

In Statistics, you see usage recorded for every model response. The top selector combines a date range, agent or transport filter, chart granularity, and grouping criterion. The chart shows changes over time and the table explains the total.

What it counts

Each turn stores the tokens reported by its model, and Usage adds them up: everything is in tokens, not in money. If your agents work on a subscription, what you pay does not depend on each turn.

Data	What it represents
Input	New tokens sent to the model: your message, instructions, and context that was not reused.
Output	Tokens generated by the model while responding or performing a task.
Cache read	Context reused by the provider from cache. It still counts as context, although it costs the provider much less than processing it again.
Cache write	Context prepared for later reuse.

If output is high, make replies more focused

Under the agent's Configuration > Behaviour, choose less Detail, a Scannable format, and One message. This can reduce output tokens but does not remove the reasoning or context needed for the work.

Total tokens adds all four categories. That is why a long conversation often has far more cache tokens than input or output: the agent can be reusing the same context without sending it again in full.

Group and narrow analysis

Choose a period first, then the dimension that answers your question: Agent, Channel, Transport, Scope, Conversation, Contact, Model, or Scheduled task. Agent and Transport filters reduce the data before grouping.

Granularity changes chart detail, not totals: use Hour for a recent spike, Day for routine tracking, Week for several months, and Month for a yearly view.

A practical way to investigate an increase

Start grouped by Agent. Filter the agent that grew, then try Channel, Conversation, and Model. The table shows whether the cause is more messages, longer replies, cache context, or a change of model.

Maximum usage rate

This is the emergency brake. If an agent consumes tokens faster than your set rate over the last hour, Kujira alerts administrators or pauses the agent, depending on your choice.

Set it by default in Settings › Cost control; every agent can inherit it, disable it, or use its own value. If you configure nothing, your plan's limit applies, and it still applies when you switch an agent's brake off: you can raise or lower it, not remove it. The maximum depends on the plan.

The notification about an agent going over its rate arrives at most once every four hours per agent and action, even if it stays over the whole time. This applies equally to email, phone and the bell in the panel. See How many notifications arrive.

On wide screens, each agent's page has a line under its tabs with what it has used in the last hour against the ceiling that applies to it: in the normal colour, amber past half — where the first warning arrives, which never brakes — and red past the ceiling, which is when it pauses if that is your choice. Hovering it says whether reaching it warns (Usage warning) or pauses (Usage limit), and the exact figure. With no ceiling to apply, it doesn't show. It is visible to whoever can see the organization's spend, and anyone can hide it in Account › Appearance › Show cost control; that is saved in that browser, not in the account.

Conversation compaction

When a conversation accumulates context, every reply costs more. At the threshold, the conversation compacts automatically: a summary replaces older material without losing the thread, reducing cost per reply again.

A new organization brings nothing forward: each conversation uses its model's full context window and compacts when it fills up. Compacting earlier saves money, but it costs a full turn and loses detail, so the timing is each organization's call.

If yours predates September 2026, it keeps the figure it already had as its cap — 300,000 tokens unless you changed it — so nothing moved overnight. To use the full window, clear that cap.

Settings › Cost control has two settings, and whichever comes first applies:

• Share of the window. It means the same across the organization even when agents run different models: 30% is about 300,000 tokens on a 1M model and about 60,000 on a 200k one. At 100% nothing is brought forward.
• Token cap, optional. Compacts at that figure even when the share would come later. This is the one to set to contain spend on very large windows.

Each agent can inherit that setting, never compact, or set its own threshold in tokens, and each session can do the same from the chat or from the conversations list. Changing compaction applies from the next message, without restarting the agent.

A threshold doesn't apply in two cases. If it reaches the model's window it brings nothing forward, since the conversation already compacts when it fills up. And if it falls below 20,000 tokens, the summary would replace what the agent loads at boot.

Two cases worth adjusting

MiniMax M3 on pay-as-you-go doubles its rates above 512,000 input tokens. With long conversations on that model, set the cap at 500,000.

Ollama keeps no context cache: it re-reads the whole conversation every turn, so replies slow down as it grows. Lowering the share fixes it.

In Statistics, group by agent and review the chart first when usage grows unexpectedly.