> ## Documentation Index > Fetch the complete documentation index at: https://docs.usenash.com/llms.txt > Use this file to discover all available pages before exploring further. # Usage & cost > See what Nash Agent is doing and what it costs, then cap spend with org-wide and per-agent limits. 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: | Measure | What it tells you | | ------------------ | -------------------------------------------------------------------------------------------------------------------- | | Token counts | How much the agent read and wrote, broken out by what the model took in and what it produced — plus a combined total | | Estimated cost | A dollar estimate for the period, derived from the tokens used and current model rates | | Requests | How many times the agent did a unit of work over the period | | Users and sessions | On 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](/nash-agent/custom-agents) 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 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. Open a [custom agent](/nash-agent/custom-agents) 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. 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. ## Related Set a per-agent spend or token ceiling that tightens your org-wide default. Background personalization your org can opt into — a separate, automatic source of agent activity.