Skip to main content
Every time the agent works — answering a question in chat, running a scheduled job, reaching out to a customer — it does some thinking, and that thinking has a cost. The usage view shows you what the agent has been doing and what it’s costing, broken down so you can see where the activity is coming from. Spend limits let you put a ceiling on a single run so nothing ever gets away from you. There are two things to understand here: usage analytics (looking back at what happened and what it cost) and spend limits (setting a cap so a single run can’t run away).

​
Usage analytics

The usage view reports your organization’s activity and estimated cost over a date range. It’s scoped to your organization, so you only ever see your own activity. You can look at it three ways:
  • A summary — totals for the period, plus how that compares to the previous period of the same length, so you can tell at a glance whether activity is trending up or down.
  • A trend over time — the same totals plotted across the date range, bucketed by day, week, or month depending on how wide a window you pick.
  • A breakdown — the top contributors to your activity, grouped by who (which user), which agent (which custom agent), or which model the work ran on.

​
What each view reports

Every view reports the same set of numbers, so you can move between them without re-learning what you’re looking at:
MeasureWhat it tells you
Token countsHow much the agent read and wrote, broken out across several categories — what it took in, what it produced, and other distinct kinds of processing — plus a combined total
Estimated costA dollar estimate for the period, derived from the tokens used and current model rates
RequestsHow many times the agent did a unit of work over the period
Users and sessionsOn the summary, how many distinct people and conversations were active
The cost shown is an estimate, not a bill. It’s calculated from the tokens used and the current per-model rates, so it’s a close guide to spend — but it isn’t an invoice, and the exact figure can shift if rates change.

​
Choosing a date range

By default the usage view looks at the last 30 days. You can pick any range you like, up to a maximum window of 400 days. If you set an end date in the future, it’s treated as “now.” The trend view automatically picks a sensible bucket size for the window you choose — daily for short ranges, weekly or monthly for longer ones — so the chart stays readable.

​
What counts toward the numbers

The usage view reflects the agent’s own thinking — the reading and writing it does to answer you and to run your jobs. Some specialized work the agent does (for example, certain analytics lookups against your data) is metered separately and isn’t folded into these figures. Think of the usage view as the best single-pane picture of agent activity over time, not a line-item reconciliation of every downstream service.

​
Spend limits

Usage analytics tell you what already happened. Spend limits stop a single run from going too far in the first place. A spend limit is a ceiling on one run — one conversation, or one scheduled execution. When a run hits its ceiling, the agent stops and tells you it reached the limit, rather than continuing to spend. There are two kinds of ceiling, and you can set either, both, or neither:
  • A spend ceiling — a dollar limit on what a single run may cost.
  • A token ceiling — a limit on how many tokens a single run may use.
Whichever ceiling is reached first stops the run.
Spend limits are a runaway guard, not a budget tracker — they protect against a single run that spirals, not your monthly total. To watch overall spend, use the usage analytics above.

​
Org-wide defaults and per-agent overrides

You set spend limits in two places, and they work together:
  • An org-wide default applies to every run across your organization — interactive chat and custom agents alike. Set it once in your organization’s agent settings.
  • A per-agent override lets a single custom agent run under a tighter ceiling than the org default. Set it on the agent itself.
The rule is the tighter limit wins. A custom agent’s override can only lower the effective ceiling, never raise it — so a per-agent limit is a way to keep a particular agent on a shorter leash, not a way to give it more room than the rest of the org. Leave a per-agent override unset and that agent simply inherits the org-wide default. This is the normal case: set a sensible org default, then tighten individual agents only where you want extra caution.
A limit of zero — or no limit at all — means “no cap,” not “block everything.” If you want a run to be constrained, set a positive number. Setting the value to 0 does not stop runs; it removes the ceiling.

​
When a limit is decided

A run’s effective limits are worked out when the run starts, from the org default and the agent’s override at that moment, and they’re locked in for the life of that run. Changing your org default or an agent’s override afterward doesn’t move the ceiling on a run that’s already underway — it applies to runs that start after the change.

​
Setting limits

1

Set the org-wide default

In your organization’s Nash Agent settings, set a per-run spend ceiling and/or token ceiling. These become the default for every run in your org. Editing org settings is an admin-level action.
2

Tighten an individual agent (optional)

Open a custom agent and set its own spend or token ceiling. Remember the tighter value wins, and the agent can only go lower than the org default — never higher.
3

Leave overrides unset to inherit

Any agent without its own override automatically uses the org-wide default. You only need to set per-agent limits where you want a tighter leash than the rest of your org.

​
FAQ

Anyone in your organization with the analytics permission can view usage — it isn’t restricted to admins. If you have access to your org’s analytics and reporting, you can see usage and cost over a date range. You’ll only ever see your own organization’s activity.
The org-wide default is an admin-level setting, edited in your organization’s agent settings. Per-agent overrides are set on a custom agent, which requires the permission to create and manage custom agents. Viewing the numbers is broadly available; changing the limits is not.
No. It’s an estimate calculated from the tokens used and the current per-model rates. It’s a reliable guide to spend and useful for spotting trends and outliers, but it isn’t an invoice and shouldn’t be treated as one.
A spend or token ceiling for that run was reached, so the agent stopped rather than keep spending. Check whether the run’s effective limit came from your org-wide default or a tighter per-agent override, and raise the appropriate one (or remove it) if the work legitimately needs more room. Limits are decided when a run starts, so the change takes effect on the next run.
No. The tighter limit always wins, so a per-agent value above the org default has no effect — the org default still caps the run. Per-agent overrides are only useful for setting a lower ceiling than the org-wide one.
It removes the cap. Zero (and “no value set”) both mean “no limit.” To actually constrain a run, set a positive dollar or token figure.

Custom agents

Set a per-agent spend or token ceiling that tightens your org-wide default.

Memory and learning

Background personalization your org can opt into — a separate, automatic source of agent activity.